Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Modify Remote Login server to block scripted attacks' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Modify Remote Login server to block scripted attacks
Authored by: rhowell on Feb 11, '05 11:08:01AM

Where I work, we have 5 Macs which I ssh between all the time. Thanks Rob for some great pointers. However, the real security experts here at work (they've got PhDs in this stuff, I don't) warned me a few weeks ago:

Since I've got public/private key pairs between all of my machines, and never have to supply a password to get in via ssh, this opens a huge security hole. If one machine gets compromised, they all get compromised with no additional effort. Once an attacker is into one machine posing as you, all of the other machines are immediately available to him.

I know, I know, how is he going to get into my machine without a key? I don't know, he'll wait until I go to the bathroom, or lift my laptop on the subway.

Anyway, the security "experts" here at work highly recommend unique secure passwords only in lab-like environments for this reason.

Can anyone refute their claims (again, I'm no expert)? This, of course, is a real pain. scp-ing files back and forth without the need for a password is almost as easy as cp-ing files locally. I'd love to convince them that key pairs are the way to go.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: robg on Feb 11, '05 11:20:16AM

One of the linked hints above explains how to add a passphrase, then use the keychain so you don't have to enter it all the time...

-rob.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: Don Faulkner on Feb 11, '05 12:41:02PM

Your PhD's are right, of course. ;) However, I'd guess that there are very few (feasible) processes you could envision that they couldn't find a flaw in; it's their (and my) job to find the chink in the armor. Take their comments as a warning: safeguard your private keys like you would the keys to your house (or similar--it of course depends on how important those systems/data are).

First, PUT A PASSPHRASE ON YOUR KEY! I can't stress that enough. Yes, you'll have to type that in until you get an agent set up (keep reading), but it's just the one passphrase.

That said, you probably don't need 5 sets of keys to ssh between 5 systems. You only need one set, with the public key on all systems. The private key should be on the one system you work at. If you sit in front of a different keyboard each day, put the private key on a USB flash drive or something. I suggest a cheap, small device used only for this and other very sensitive stuff--otherwise I'd have said iPod. (You don't want your private key on something that you stick into "untrusted" systems.)

SSH supports "credential forwarding." In other words, you can use your private key to authenticate to the first host. After that, each host you connect to forwards authentication requests through the host(s) you're already connected to. Your single private key stays in one place, which is good because you're more likely to know if you've lost it--and that's what your PhD's are really after.

To get full mileage out of this technique, you'll probably want an SSH Key Agent. These work a lot like Apple's Keychain, but they're for SSH keys. Your SSH client (in terminal, an SFTP client, etc.) hands off the authentication request to your agent, which services it with your private key. If you set things up right, you rarely have to enter any pass-phrases at all, but you retain most or all of the security protections. I use SSHKeychain, and am very satisfied with it because of it's simple integration with Apple's Keychain and its built-in support for SSH tunnels.



[ Reply to This | # ]