*nix Tip of the Day: SSH Agent Forwarding

Today's *nix tip of the day involves SSH and the magic that is Agent Forwarding.

SSH, as some of you know, is a handy way to connect to *nix systems in an untrusted environment. Its primary use is to allow one to remotely access a remote system and get a shell, securely. Basically, encrypted telnet. Of course, SSH has tons of other useful features (like tunneling, proxying, and multiplexing), some of which might come up in future Tips of the Day.

One of SSH's greatest features is its public/private key system. Basically, using private keys, you can allow much more secure access to a remote machine. If you trust your local machine, you can even allow passwordless access to remote machines if you have an unencrypted private key. Of course, this is a bad idea if you think people might be able to compromise your local private key, which is why SSH private keys can also be encrypted with a symmetric cipher (basically, a password). Using this gives you all of the in-transit security and power of private keys, but all of the local security of password authentication (something you have + something you know sort of deal). They're covered a great deal more in a retroactively-posted tip of the day — read back a bit.

This is all well and good, but there are times when typing your SSH key's passphrase is annoying. For example, the Z Shell allows for tab-completion of remote filenames over ssh (when using scp, for example). It is an awesomely useful feature that makes remote filesystems feel local without any of the muss of sshfs. However, if you have an encrypted private key (or password authentication), typing your password every <TAB> can be a pain. Hence, ssh-agent.

ssh-agent is a program that you will generally run as a wrapper around your session (this is done automagically on linux if you're running gdm). If you want to test this stuff, you can just run exec ssh-agent $SHELL from a terminal and then execute all of the commands from this tip in that shell. Now, let's say that you've put your private key in the standard ~/.ssh/id_rsa, and it's encrypted. At your newly-ssh-agent'ed shell, type in ssh-add ~/.ssh/id_rsa and type in your private key's encryption passphrase when prompted. Congrats — you can now ssh from this shell to any machine containing your public key without any password at all. Isn't that awesome? Try it out. I'll wait.

...

Now, this is well and good. But let's say that you just ssh'd to example.com using your super-duper ssh-agent, and you want to ssh from there to your other server at example.net. Do you need to copy your private key onto example.net and then type the passphrase there? That might be a bit risky, especially if you don't really trust the admins of example.com. I mean, the key is encrypted, so you're probably okay, but what if they're running a keylogger? Well, as long as you're using OpenSSH (which you most likely are), you're fine, thanks to the magic of agent forwarding. Log out of example.com, and then run ssh -A username@example.com. Note the -A. This turns on agent forwarding, and means that your login at example.com temporarily has the same access permissions as your local machine. So you can happily ssh user@example.net and get the happy password-free access without anything else. You can even agent-forward from example.com to example.net and build up a chain of secure authentication credential forwarding all the way back to your local machine. It's awesome.

Well, that's my tip for the day. Check back again in the future for more exciting things that other people have said and done before.

*nix Tip of the Day: SSH Private/Public Keys

Hello kind readers, and welcome to by *nix Tip of the Day. It's finals week, and I'm sort of slacking, so I thought I'd post some of my accumulated folk wisdom on the Internet, so that it might help others.

Today's topic is SSH Private/Public Keys. If any of you are CS majors, or go to a tech-heavy school, or generally interact with Linux/OS X/Solaris/HP-UX/AIX/any other *nix, you've probably used SSH. SSH, at its most basic, is a replacement for telnet and rlogin; it allows you to get a shell at a remote machine. However, it does so securely (hence, Secure SHell) using strong encryption. SSH, particularly modern implementations like OpenSSH also has other subsystems like scp (a replacement for rcp, which is in turn a remote version of cp), sftp (a secure replacement for FTP), and such.

Most people, when using SSH, use password authentication. They type ssh user@host and, when prompted, type in their login password to host. This isn't necessarily a bad thing — it's braindead-easy to set up, generally secure, and works the same way as remote logins have since the beginning of time.

There are some problems with this setup. One of the most obvious is that if you offer password authentication, your system's security is only as good as its worst password. Every user that picks "god" or "password" as his password paints a giant target on your machine.

Enabling password authentication, even if all of your users have strong passwords, still makes you a target. There are plenty of botnets out there that connect to servers and try sshing in with random usernames (and root, of course, but I assume you have root login disabled/restricted in SSH. You do, right? If not, go do so.). It's unlikely that they'll ever break a good password, but that's still traffic hitting your box. Disable password authentication, though, and they go away. Botnets (thankfully) never try to connect using anything else.

So, password authentication isn't great. What should you do instead? Well, it turns out that SSH supports something called public key authentication. The basic idea here is that the remote user has a small file called a private key that they keep with them (on their laptop, or on a flash drive). This key allows them to access the remote server (optionally without any password at all, although this is discouraged on a flash key or laptop) more securely. The authentication is done using either a DSA or RSA with a key-length of between 768 and 2048 bits, which is all technical stuff that you don't care about. Let's talk about setup.

The first thing to do is to prepare the client system and generate the key. The following commands should take care of that:

if [ ! -d ~/.ssh ]  then
    mkdir ~/.ssh
    chmod 700 ~/.ssh
    ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa
    chmod 600 ~/.ssh/*
fi

When you are prompted for a password by ssh-keygen, you should enter something long that you will not forget. It should not be your account password. If you really trust the client system (for example, if it's a desktop machine with no remote login sitting inside a bank vault that nobody could ever break into), you can leave this field empty. But I do not recommend it.

But how do you go about using this key? Note that the keygen will have created a file called ~/.ssh/id_rsa.pub. This is your public key, and needs to be uploaded to every machine that you need access to. Let's call the remote machine remote and the local machine local. The following code should do what you need:

scp ~/.ssh/id_rsa.pub user@remote:~/local.pub
ssh user@remote
if [ ! -d ~/.ssh ] then
    mkdir ~/.ssh
    chmod 700 ~/.ssh
fi
cat local.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm local.pub
exit

If all went well, you should now be able to log into remote using your public key. If you attempt to ssh user@remote, you should be prompted "Enter passphrase for key '/home/user/.ssh/id_rsa'". Type in the passphrase you entered during the key creation step and you're all set.

If typing in this passphrase all of the time seems like a pain in the rear to you, you're not alone. Check back later for the next article in the series, on the use of ssh-agent. It's awesome, I tell you.

Note: I am not responsible for any borkage that these commands might cause. As far as I know, they're correct, but I still disclaim any and all liability. Yadda yadda yadda.

Updated 2008-05-13 00:55 to use correct permissions for the contents of ~/.ssh

New Bike

My new bike

So, yesterday I went to Jax Bicycle Center in downtown Claremont and I bought a new bike. Yep, I'm completely crazy. But it's such an awesome bike. Thin, barely treaded tires like a road bike, upright seating position, and nice hardware. It cost a mint, but hopefully I'll put it to good use. With PLs on Pomona next semester, I'll need it to get to class. So, yeah, that's what I've been up to...

Not much else interesting to report. School is school. Meh. But, hey, at least I got a new bike.

So, apparently this is a meme

Everybody in my RSS feed list is doing it. So why shouldn't I?

(no, it's not the exact same line. close enough)

% history 1 |awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head -n 20
140 cd
67 sudo
59 vim
52 mplayer
51 svn
47 rm
43 ls
33 eix
29 xsnap
29 wmiir
24 mv
22 cp
15 ps
15 killall
14 ssh
12 xset
12 history
11 man
11 evince
10 sed

Headphones

Sennheiser HD 280 Pro

Since this summer, I've been using a pair of Sennheiser HD280 Pros. Let me just say that they're excellent headphones, and they provide better attenuation than most noise cancellation headphones without murdering the sound quality the way active noise canceling headphones do. This is a great feature when North is having a party, or just when my roommate is listening to music on his speakers. However, like all closed-back headphones, they're a bit constricting, and there are some minor audio artifacts caused by the hard backing.

Grado SR60

So, last week, I picked up a pair of Grado SR60's. They are also excellent 'phones, especially for the price. The sensation of having fresh air on my ears is worth it alone. Of course, they're fully open-backed, so they don't provide any protection from external noise at all. But, when it's quiet enough, they're awesome.

I thought it might be useful to give some basic impressions of the two pairs of headphones in a typical usage situation. I'm in my room right now with some not-too-loud noise, and I've got both headphones plugged into my computer via my HeadRoom Total Bithead. The first source material is my FLAC rip of the Brian Wilson SMiLE album — if you haven't heard it, you should. If this had come out when it was supposed to (i.e., 40 years ago), the Beach Boys would have been a bigger name than the Beatles. After that, I've got another FLAC rip, this time of Pearl Jam's Ten, which is considerably heavier, and should provide a nice contrast. Anyhow, here's my thoughts:

  • "Wonderful", Sennheiser: Great immersion. It is much easier to focus on, and thus hear, fine details in the music with these cans, since they block out so much of that pesky external noise.
  • "Wonderful", Grado: These seem a bit clearer than the Sennheisers. It's a little harder to focus on the music over the background noise, since there is background noise. However, both the highs and the lows seem more defined using the Grados (note: this is with the stock "soft" foam caps. I haven't tried the "doughnut" caps yet)
  • "Surf's Up", S Everything seems much stronger with the Sennheisers. It seems like they're a bit easier to drive. The background instruments really pop out, particularly the plucked instrument around 1:20 (guitar?)
  • "Surf's Up", G Voices are much clearer and vibrant, more "there". I have to turn up the volume a bit to get the same amount of sound out, but I can live with that.
  • "Even Flow", S Very engaging, but slightly murky at the edges — the guitar fuzz seems slightly deadened. Still groovable.
  • "Even Flow", G Still noisy outside, but every note seems as raw here as it does on decent loudspeakers. Even though I'm less isolated while wearing the Grados, they seem to have more presence than the Sennheisers

I could continue all day, but I've actually got homework to do (I know, crazy). So if I were to take a bottom line, I'd say that I prefer the Grados, and if you've got a quiet enough environment to sustain open-backed headphones for much of the time, they're a great investment. However, in a college dorm, particularly on weekends, the insulation in the Sennheisers is much handier. If you have to choose, consider your environment. Or, you know, get both. :-)

Oh, and if you do end up getting either of these, I highly recommend purchasing from HeadRoom. They're not always the cheapest on the Internet, but they're honest, quick, and have the best support department in the industry. Oh, and they make great amps.

Ciao.

A brief thought on the new Microsoft "Interoperability" documents

If you haven't seen the recent Microsoft Interoperability announcement, I suggest you read it. It's been Slashdotted, so I figure there's a decent chance that everybody on the Internet has seen it already. This is, of course, an extension of the Microsoft Office Binary Formats release of a few days ago, and I'm equally leery about it. There are some interesting comments on the Office Binary formats on the web, including these by Jeff Licquia, and those he links to by Joel Spolsky.

On the one hand, this is an amazing opportunity for F/OSS developers and pretty much everybody interested in cross-platform interoperability. There are probably quite a few OpenOffice.org developers that would have killed to get free access to the specs for MS Word and Excel files over the past few years, considering how close to impossible it must have been to reverse-engineer everything. And, if it pans out, I'm sure that this will lead to better Microsoft format compatibility in the future years. If it pans out. For one thing, the specifications are immense and ridiculously complex, and I don't know if anybody's going to bother including Lotus 1-2-3-compatible Excel format importers in OOo. The somewhat more serious concern is whether the "Microsoft Open Specification Promise" is acceptable. IANAL, but it seems that this prohibits implementers from ever filing a patent infringement suit against Microsoft for related technologies, which might be a stifler, particularly for commercial competition like Corel WordPerfect. But, hey, maybe I'm reading it wrong and it's all good. Maybe we'll see a better Wine, OOo, AbiWord, and everything else tomorrow. I just don't know.

In Claremont, Again: Musings

Today marks my first week back in sunny California. Actually, scratch the "sunny" part — it's rained here almost every day since I arrived. It's still nice to be somewhere where the average daily temperature has more than one digit, though.

Class is exactly as I remembered it. Hours drag by, but days seem to end almost without beginning in the first place. I'm staying on top of my homework, which is a good thing. We'll see how well I can keep that up, particularly when biology and STEMS (signals and systems engineering) start to load it on.

I've also started a new job here at HMC. I've joined the Computer Science department staff, which is awesome. I've always enjoyed systems administration, and now I get to do it for a large and sophisticated network. So far I've identified and provided a solution for a misbehaving compiler problem on the CS105 machine, and helped Yaniv rewrite the kiosk to be valid (and working) HTML/CSS/JavaScript. Not a huge list of a achievements, I'll admit, but I've only been doing stuff for a few days.

Speaking of computers, I've got a new face returning to my stable of productive machines: an Apple Newton MessagePad 2100. I just purchased one off of eBay to replace the one that got broken at Durfee, and so far it's working out great. I never will cease to be amazed at how incredible the handwriting recognition is, or how perfect the form-factor is for good handwriting recognition. I've got a LAN card coming in next week, so maybe I'll even be able to bring it into the 21st Century. Cool, no?

Not everything is sunny in the world of computing. A recent Gentoo change (unwisely pushed out to ~x86 and ~amd64, in my opinion) caused keyboard mappings to come from HAL, which had the end effect of completely breaking my keyboard under X. Yes, it's possible to fix with a clever combination of .fdi files and a corrected Xmodmap, but the problem should not have happened in the first place. Silly devs. If you're afflicted, this bugzilla thread should help.

Okay, enough procrastination. I suppose I'm going to go do some more work. Good bye, reader.

PS: Feel free to add a Comment, if you exist. I have strong suspicions that you do not...