Extra Pepperoni

To content | To menu | To search

Saturday, February 24 2007

Props to the Network Guys

We have a bunch of 48-port terminal servers (they're Linux/ssh based, and quite good). Unfortunately, one of ours has a bad Ethernet port (intermittent connections -- no good for lights out management!)

Today (Friday), I spent from 4:15 to 5:30 labelling 48 Cat5 cables, replacing the old terminal server (a tight fit!), reconnecting the cables, and testing. It increased my respect for our Network group, as they do this type of thing all the time (although usually with less ports), and scheduling network downtime is much tougher than scheduling console downtime. Lots more people notice. Fortunately, the terminal servers are for our group, and used almost entirely by 4 particular people, so notification and scheduling was easy.

Still, it wasn't fun. At the end I had a label maker with dead batteries, a whole bunch of garbage from the labels, and grimy fingers, but we regained remote access for the weekend, which was my goal.

Next time I'll ask a hardware guy to do the cable swapping!

Monday, February 12 2007

Sensitive Data: Things to Delete

I'm sending my 3-year-old PowerBook off to Apple for repair before AppleCare runs out, and here's my checklist of confidential things to remove (after SuperDuper! finishes backing up) for security reasons. This would also be a good idea whenever a sensitive computer is going beyond personal control for a while. On a machine that travels a lot, most of this data would be on an encrypted filesystem or not present at all, but this PowerBook mostly moves around within our home.


Hopefully this list will help someone else remember what to delete/protect.

  • All personal Keychains (~/Library/Keychains/); if you have multiple accounts, don't forget the others; if your System keychains are sensitive (AirPort password, mostly) don't forget /Library/Keychains
  • All my ssh files, except authorized_keys, in ~/.ssh/
  • Any sensitive email (in my case email is on an iPod, but backed up to the PB)
  • Password wallets (Web Confidential, etc.)

Also, I create an admin user apple, with a one-time password, and set it to enable auto-login (System Preferences:Accounts:Login Options).

When the PB returns, I'll restore the sensitive files and delete the apple account.

What am I forgetting? Leave a comment!

Update: Someone asked about deleting their account and all their files before sending a PowerBook in for service. This is more paranoid than I am, but here's my answer:

First, don't delete the account -- you'll get a different UID when you recreate it after service, and this complicates things. If you are concerned that Apple will somehow snarf your password, change the password temporarily (System Preferences:Accounts); don't forget any other accounts (if you have a root password to protect, "sudo passwd root").

Don't delete any files without having a tested backup first. Disk Utility can handle this nicely -- just make a compressed disk image of your home directory.

To delete your home directory:

  1. Enable root ("sudo passwd root", if you haven't already).
  2. Set System Preferences:Accounts:Login Options to "Display login window as:" "Name and password" (by default, you must pick the name of a non-root account from the login window).
  3. Log out and log back in as root.
  4. Go to /Users, and delete any home directories you want to get rid of (and have already backed up & verified).

When you get the computer back, restore your password(s), delete the apple account, and restore your home directory.

Thursday, February 8 2007

Remote Control and Reminders

Frequently, I need to leave myself a reminder or send myself a note on another Mac. I used to do this via email, but now mostly use ssh, with the open and bbedit commands. Since I use ssh private keys for authentication, this is very convenient -- I can issue commands to remote machines without having to enter a password each time.

Since I ssh so often, I've set up several convenience aliases, including ss for "ssh salt" and sc for "ssh cayenne".

For several years I wished for remote clipboard support; I believe Peter Lewis even wrote a tool to implement it, and there are remote control tools such as VNC, but this is simpler and quicker.

Here are some examples of useful remote commands:

Open a BBEdit window on salt, showing the entered serial number:

echo "Serial Number for Some Super Software" | ss bbedit

Open an article in Safari, on cayenne:

sc open http://db.tidbits.com/article/8835

Open a couple pages in Safari on cayenne, including one with punctuation in the URL that would normally trip up the shell:

sc 'open http://blogs.zdnet.com/threatchaos/?p=311 http://daringfireball.net/2007/02/more_crap_from_enderle'

I keep most of my systems on all the time, so it's extremely handy to be able to toss text and URLs around this way.

Serious UNIX nerds can use cat to send a block of text over (Control-D at the end terminates text entry and bundles off the text):

cat - | ss bbedit
This is a test.
This is only a test.
If this was a real emergency, you'd be dead already.

Alternatively, create a text file via a normal ssh session, and open it for later -- this is not as fast, but conceptually closer to normal usage:

pepper@www:~$ ss
Last login: Thu Feb  8 18:13:36 2007 from www.reppep.com
Welcome to Darwin!
pepper@salt:~$ vi Desktop/note.txt
[Type, paste, whatever, here; then save and exit vi]
pepper@salt:~$ bbedit Desktop/note.txt
pepper@salt:~$ logout
Connection to salt.rockefeller.edu closed.

Additionally, I do something similar to remind myself to edit or update documents when I get home, which looks something like this:

sc bbedit www/pepper/public_html/index.html

Monday, January 29 2007

"MacFUSE Explodes Options for Mac File Systems" in TidBITS Today

MacFUSE is great. I wrote a short bit on it for TidBITS. The elevator pitch is: MacFUSE allows mounting SFTP servers just like AFP/SMB/NFS shares, read-write access to NTFS filesystems (Tiger's built-in NTFS access is read-only), and a whole passel of other filesystem options.

The article, "MacFUSE Explodes Options for Mac File Systems" is at: http://db.tidbits.com/article/8835.

There is a binary installer for the NTFS-3g module (ideal for Boot Camp users), but it doesn't yet have a stable home. Currently, you must visit the macfuse-devel mailing list http://groups.google.com/group/macfuse-devel and look for a posting with the latest URL (as of today, see http://groups.google.com/group/macfuse-devel/browse_thread/thread/ee1c4555d3c90f4f).

Monday, January 8 2007

Remote 'man' with BBEdit

I frequently need to read manual pages from Suns and Linux systems, but prefer to read in BBEdit. Today's trick facilitates this, by grabbing the manual page from a remote machine via ssh, unformatting it with col, and dumping it into a BBEdit window (which doesn't ask to be saved).

function manb () { ssh $1 man $2 | col -b | bbedit -t "$2@$1" --clean --view-top }

Usage is "manb host command", so "manb www up2date" opens a window titled "up2date@www" with www's up2date manual page.

Friday, December 29 2006

BBEdit and Subversion: the Fruit Roll-up Post

I use vi daily, but much prefer BBEdit. The way I integrate them has evolved over time (see previous posts here, Useful subversion shell aliases, and BBEdit Gems (which appears to be down right now). In particular, I no longer configure BBEdit directly in ~/.subversion/config.

The new improved integration uses BBEdit whenever it's available (I'm in front of the Mac), and falls back to the default (vi) when I'm connected via ssh.

First, I created ~/bin/edit.sh to hand off to BBEdit. I use edit.sh whenever BBEdit is appropriate:

# Edit in BBEdit, for programs that don't support arguments in $EDITOR.
bbedit --wait --resume "$@"

Next, I configured my bash profile to prefer edit.sh when I'm not connected via ssh (which means when I am in front of the Mac or using ARD/VNC), as my EDITOR and PAGER. My profile doesn't automatically determine whether to use bbdiff for Subversion, because I sometimes find it necessary to use non-BBEdit diff for Subversion (there are cases where the svn-to-bbedit handoff doesn't work well, and I have ended up editing scratch files instead of the real files, for instance). Here's the snippet that does this, from my profile:

if [[ ! $SSH_TTY ]]
  if [ -x ~/bin/edit.sh ]
      export EDITOR=~/bin/edit.sh
    else export EDITOR=vi
  if [ -x /usr/bin/bbedit ]
    then export PAGER="col -b | bbedit --clean --view-top"
else export EDITOR=vi
fi # [[ ! $SSH_TTY ]]

In addition, I set up aliases for reviewing output from the svn command, based on Bob's suggestions. I just copy and paste one or more lines from svn output to review changes in BBEdit:

alias  A='bbedit --wait'
alias AM='bbedit --wait'
alias  C='bbedit --wait'
alias  D='true'
alias  G='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  I='true'
alias  M='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  R='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  U='bbedit --wait'

I update and then review status so often that I built my own TLA:

alias sus='svn update

Friday, August 25 2006

bash: Clearing History

The excellent bash shell keeps a history of recently executed command lines and lets users cycle through them with up/down arrow, edit commands, and re-execute past commands.

Every once in a while, I make a mistake and type a password at a bash prompt -- today it happened because I had a remote session waiting for a password, which timed out, so I typed my password at the "Password:" prompt, but my workstation noticed the connection was down and dropped me into bash, which failed to execute my password (because it's of course not a valid command), and helpfully cached it on disk for future shells to take advantage of.

The quick fix is "history -c", to flush the whole history (and Command-K in Terminal or whatever's necessary in a different terminal program to clear the screen and scroll-back buffer).

A less drastic step is to use "history | tail" to find the line number of the bad command, and "history -d 503" (or whatever the appropriate line number is) to clear just the bad line, preserving the rest of the history. Further details are available with "man bash".

Tuesday, August 22 2006

Apple Keychain: Problems with Intrusiveness & Encrypted Disk Images

I find the Apple Keychain very useful, but need to protect my keys -- apparently more than Apple anticipated. On all my machines, I used to have my login keychain set to close after a couple hours of "inactivity". This was very intrusive, as it also locked SSHKeychain, even if I was actively using ssh keys (since Keychain didn't know SSHKeychain was actively being used). I recently discovered the security command. Now I have a cron job which flushes my login keychain when I'm done working for the day/night on all my machines, and it's enabled me to crank up login's inactivity timer. Twice a day, cron runs "security lock-keychain ~/Library/Keychains/login.keychain".

Locking the Keychain has revealed several problems (which I have reported to Apple). First, .Mac syncing assumes the Keychain is always unlocked. This makes a certain amount of sense, but means .Mac syncing doesn't really work unless you leave your .Mac password always available in a keychain. To address this, I use a separate keychain (lowsec) for the relatively low-security .Mac password -- lowsec never locks itself (until I reboot). I'm not happy about this, but it's the best I could do without giving up the one really useful .Mac service.

This leads to the second problem (a straight bug): extra password prompts. If I use my account password for my login keychain, it should be automatically unlocked whenever I unlock the screensaver (just as it's unlocked when I log in after a reboot). But it isn't. I still get prompted to unlock my login keychain after unlocking the screensaver. What's worse, I often get a couple prompts for my login keychain, and on an untrusted laptop I typically get a couple more for lowsec (for a stalled .Mac sync, and to set my iChat status). On the laptop, SSHKeychain is set to lock my keychains when it sleeps, and SSHKeychain is not selective -- it locks all keychains (also reported to Bart).

The untrusted laptop found another serious problem. I don't trust FileVault, so I created a 2gb AES-encrypted disk image with Disk Utility. I moved ~/.ssh and ~/Library/Keychains (yes, I know about ~/Library/Caches/) onto the disk image, and created symlinks from the original locations. The bug I found is that, if the Keychain can't be used (perhaps, say, because ~/Library/Keychains is a dangling symlink, and it's configured to use one or more keychains there), Disk Utility is unable to present the password dialog for an encrypted disk image. This meant because I'd "broken" the Keychain by dismounting the disk image containing my keys, I was unable to remount the disk image to "fix" the keychain, because the broken keychain was preventing disk mounting! I escaped the vicious circle by moving aside the symlink and creating a new ~/Libraries/Keychain directory, which un-broke the Keychain enough that I could get the disk image back online. Now I leave ~/Library/Keychains/lowsec in the normal place, so the Keychain is functional, and manually specified the locations of my (normally unavailable and mostly empty) keychains on the disk image, so they're available when it's mounted.

Friday, August 18 2006

ssh sessions hang when adding a higher-priority network connection

I have an MBP which is always connected via AirPort. When I come back to my desk, I typically plug it into an Ethernet cable, on a different (more trusted) subnet.

If I have any ssh sessions open when I bring up the Ethernet connection (which is of course faster and prioritized above AirPort in SP:Network), the ssh sessions hang. If I notice quickly, I can disconnect Ethernet, finish my work (if possible), and disconnect before plugging back into the Ethernet, but this shouldn't happen. The ssh connections are established on the AirPort interface, which is not disturbed, and should remain usable even when an additional connection is introduced.

I have reproduced this behavior on a PBG4 and an MBP, both using the latest

Friday, August 11 2006

Security Flaws: AFP-over-SSH Broken

After a discussion with Rich Mogull, where we both agreed that AFP is a threat (note that Apple fixed 4 different AFP threats in Security Update 2006-004), I decided to require ssh tunneling for AFP connections to www.reppep.com. Apple provides a neat feature for automatically tunneling AFP through ssh, but unfortunately it's broken in half a dozen ways...

My initial report:

It is impossible to connect to an AFP server without access to port 548 -- this should work if ssh is available, and AFP-over-SSH is enabled. Instead, with 548 blocked by a firewall, the AFP connection times out -- even using an alias created when connected via AFP-over-SSH.

Connect To Server should accept afps://host as a scheme that specifies AFP-over-SSH. Instead it gets converted to afp://afps/host, which is wrong and nonfunctional.

It's impossible to require ssh for AFP from the server.

It's impossible to support AFP on the server without leaving port 548 open, even though with ssh tunnelling 548 shouldn't be needed.

Note: These are not exploits, but they are real problems with the security of Mac OS X (Server

Sunday, June 4 2006

USENIX 2006, Boston

I just got back from USENIX in Boston, which was interesting. You know you're at a good technical conference when all the rooms have open wireless, and each table has a power strip...

But why wasn't there a session on advanced SSH???

This year's social event was (watching the penguins at) the Aquarium. The poor BSDers didn't get to visit with Beastie, though. I got a bunch of pics and a little video (snake

Thursday, May 4 2006

ssh keychain vs. ssh Forwarding

I use Gentoo keychain heavily, to cache ssh private keys. If you use it on a few workstations, and make it a point of clearing keys or stopping keychain, you will find yourself in a situation where you ssh from a machine with keys into a machine without keys. For a while I was picking up the (useless) keychain on the remote machine I sshed into, instead of the loaded keychain on the local machine I sshed from. This .profile refinement doesn't load keychain if it can find an active agent:

  if [[ `which keychain` ]]
    if [[ ! ${SSH_CLIENT} ]]
      keychain -q --noask; . ~/.keychain/`uname -n`-sh
    fi # [[ ! ${SSH_CLIENT} ]]

    alias  kc="keychain --timeout 540 ~/.ssh/id_dsa; . ~/.keychain/`uname -n`-sh"
  fi # [[ `which keychain` ]]

Update 2006/05: I recently switched from Gentoo keychain to SSHKeychain. It optionally integrates with the Apple Keychain (including automatic locking and loading of keys), and configures global environment variables for BBEdit and other co-operating tools.


Saturday, February 4 2006

VNC & ssh through NAT

I periodically need to help my father with his computer. Since he's on DHCP behind an AirPort Extreme (which is getting its own IP via DHCP), this has been tricky. I recently found the solution.

Here's what I sent to Dad:

  • Please go to System Preferences:Sharing:Services.
  • Make sure Apple Remote Desktop is checked.
  • Select Apple Remote Desktop.
  • Check Show status in menu bar.
  • Click on Access Privileges, and make sure VNC viewers may control screen with password: is checked.
  • Type your password into the text box.
  • Hit OK.
  • Repeat this on all your Macs.

Next time I need to access one of your Macs, paste the following into a Terminal window: "ssh -R 6900: -R 6922: www.reppep.com".

After this, I should be able to connect to your computer without any more futzing on your end.

Thanks to RimuHosting for the idea.

page 2 of 2 -