SSH Do’s and Don’ts

http://blog.hypergeometric.com/2012/02/22/ssh-dos-and-donts/

by gpapilion • 14 years ago

107 61 14 years ago

blog.hypergeometric.com

caf• 14 years ago

The article contains a mistake - where it says "Don’t Copy Your Public Key Around" it really means "Don’t Copy Your Private Key Around".

The advice to use ForwardAgent is also dubious, at least without fully describing the implications - which is that if you log into a compromised host, that host can use your credentials to access other hosts.

gpapilion2• 14 years ago

Thanks. Corrected

munin• 14 years ago

in the presence of compromised hosts using ForwardAgent is basically analogous to copying your private key around! (somewhat)

ninjin• 14 years ago

Agreed, I personally counter this by having different private keys for different networks and levels of security clearance. My work key gets me onto the work networks, once inside, I have a network specific key to use inside the network itself. This way I don't need to use ForwardAgent and my personal boxes will not be compromised if my work or any of my friends are.

there• 14 years ago

Using SSH agent forwarding should be used with caution, and with prompting enabled:

http://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_o...

mapgrep3• 14 years ago

This would seem contradictory:

"Don’t Use a Blank Passphrase on Your Key This is basic security, plus allows you to “safely” move your keys between hosts..."

Then:

"Don’t Copy Your Private Key Around Remember this is your identity... Its never a good idea to copy it from system to system."

So put a passphrase on your private key so you can move it between systems, but also don't ever move it between systems.

Side note: I get annoyed by advice about how one should always always put a passphrase on private keys. It makes unchecked assumptions. The private keys on my laptop are stored on a fully encrypted drive that locks every time the computer sleeps. This laptop has far more sensitive data on it than the remote hosts I access (github and a VPS), which serve virtually all their unique data to the public via the web. I'm fine with a naked private key on this machine.

ordinary• 14 years ago

I get annoyed by advice about how one should always always put a passphrase on private keys. It makes unchecked assumptions. The private keys on my laptop are stored on a fully encrypted drive that locks every time the computer sleeps.

You're probably not the target audience. If you're savvy enough to make full disk encryption work, then you should already know how to use ssh-agent.

rmc2• 14 years ago

If you're savvy enough to make full disk encryption work

Ubuntu Linux makes it work out of the box (on a per-user/home directory basis) very easily.

peteretep• 14 years ago

> If you're savvy enough to make full disk encryption work

The option's right there under File Vault in System Preferences... :-P

augustl• 14 years ago

Your setup sounds like something I could want for myself. I have a truecrypt "virtual disk" that I would like to unmount on suspend and mount on resume. Can you elaborate on the details of your encryption setup?

mapgrep3• 14 years ago

I should revise my phrasing: The computer locks behind an OS X password, the drive, while fully encrypted, remains available as far as the OS is concerned. Something like you describe would be much better.

(An attacker in possession of a sleeping machine could theoretically get the ram, cool it with liquid nitrogen or similar, and try and extract the PGP key. I do at least have FireWire DMA turned off.)

talaketu• 14 years ago

Do you recognize the threat of malware (such as a random script you download) just copying the private key and shipping it off?

A passphrase defeats that threat. And integrating the ssh agent with something like the gnome keyring means you never even have to remember your passphrase.

mapgrep3• 14 years ago

I confess, I hadn't thought of that threat. It's an interesting thing to think about.

My initial reaction is this: Couldn't malware on my laptop also monitor my keystrokes when I unlock the key? Or when I log in to my VPS web interface? I mean, if the goal is to have a malware infested computer that is no threat to external systems, it seems like there are tons of other files/apps/system you'd also want to password protect, to the point of making the computer almost impossible to use.

Still, it's an interesting point. SSH keys are more sensitive. I do keep an extra password on my password manager.

ashconnor2• 14 years ago

The same malware could run VNC or log a password too.

cmsj2• 14 years ago

Since I can't comment on the site itself:

* don't use agent forwarding ever. If you know better, be damn sure you are right

* don't back up your private key. If you lose it, generate a new one and have someone add it

* do use passwordless keys, but only if they are command (and preferably IP) locked to trigger specific jobs

* use RSA keys, not DSA keys (see Debian random number fiasco for why)

I covered some of this in http://www.tenshu.net/2012/02/sysadmin-talks-openssh-tips-an...

alexchamberlain8• 14 years ago

A voice of reason. This article was terrible.

abhaga4• 14 years ago

> don't use agent forwarding ever. If you know better, be damn sure you are right

I am curious. Why do you say this? My use case for agent forwarding is during automated deployment. Without agent forwarding, when pulling from SVN, I either need to enter password every time or have my private keys uploaded to the server where I want to deploy.

alexchamberlain8• 14 years ago

Public keys, surely?

ryan-c• 14 years ago

Anyone with access to your account (this would include root) on a machine which you have forwarded your agent to can use it to authenticate as you. For your use case, the least evil option would be to set up an SSH key that is restricted on the SVN server to only be able to do an svn export.

ajross3• 14 years ago

You probably need to rethink the security characteristics of your deployment architecture. You shouldn't be authenticating from a production host (which is presumably internet-facing, and thus more likely to be compromised), you should be pushing to it from a more protected source like a build machine behind a firewall.

Using agent forwarding in this case is precisely the problem being discussed. If someone roots your web server (or whatever it is), they can authenticate as your ssh account to any host that accepts it. So at a minimum your subversion server will be compromised if any of the production hosts are. Bad.

tptacek3• 14 years ago

There have been horrible implementation flaws in RSA too. For all we know, we're a survey away from finding tens of thousands of factor collisions in RSA keys. I really don't think it matters much whether you use RSA or DSA.

ajross3• 14 years ago

I think the intuition was more that RSA is a simpler algorithm to understand and implement, so the "goof surface" is lower. But yeah, someone somewhere will screw up everything.

emmelaich2• 14 years ago

I (symmetrically) encrypt my private key and store it in all sorts of places. (I'd rather not lose it)

Off Topic: I was so distracted by the apostrophe in "Do's" I spent 5 minutes researching it. Conclusion: I think it's ok.

alexchamberlain8• 14 years ago

Ahhhhhhhhhhhh! Use multiple public keys. For each accessing device generate a separate private key and upload your new public keys. I don't know anywhere you can't have multiple public keys.

PS Do's should be Dos, but it's quite hard to read.

dredmorbius3• 14 years ago

Your private key isn't that valuable. It's not like, say, a GPG key which you've had widely signed (there's no SSH "web of trust"). Such a key can be useful as it ages (though there are trade-offs in security -- risk of it being compromised also rises with time). You also don't lose access to previously encrypted data by losing an old SSH key, as you would with a GPG key.

So long as you can get new public keys loaded onto the systems you need to access, you're just fine generating a new keypair.

StavrosK• 14 years ago

The problem is that I have 20-30 servers (I don't even know how many or which) that I have access to, and many times I'm the only one who can log in to them. If I lose my SSH key, I have to go around all these boxes changing keys, and many times there's nobody to let me in.

emmelaich2• 14 years ago

Ah yes, that should have read 'keys', plural. I do this with my GPG key too, mainly.

emillon• 14 years ago

> I (symmetrically) encrypt my private key

That's basically what a passphrase does already.

mappu• 14 years ago

- Don't use the default port

- Disallow root login

mooism2• 14 years ago

Why disallow root login? What's wrong with allowing root login via public key only? Or via a public key limited by command="..."?

alexchamberlain8• 14 years ago

Do you ever need root login?

ichilton2• 14 years ago

It's good practise first login as another user and then gain root priv's. This is auditable and if your sshd won't allow root login's, the can't be brute forced directly.

alexchamberlain8• 14 years ago

I'm not using the default port on one machine, but I do on the other. With key based login, is it really necessary?

Florin_Andrei2• 14 years ago

If there's ever a TCP-based attack against the server, the non-standard port reduces the risk a little bit.

ichilton2• 14 years ago

If you don't run ssh on port 22, it's been proved that it receives a lot less outside login attempts and stops the logs filling up with login failures apart from anything else.

jwn• 14 years ago

On top of that, I disable all password logins on every server I run.

If for some reason I must get in and don't have access to my private key, I use a virtual console from my VPS provider to temporarily allow password logins and then immediately disable them when done.

I had a server compromised once because of a default password on the mysql account.

ashconnor2• 14 years ago

Changing ports is useless, easily defeated by a ports scan.

gpapilion2• 14 years ago

I wanted to stay away from server side settings. But I will say I have mixed feelings about both of these.

If you're using a firewall, the default port matters less. My practice is to restrict SSH to VPN connections only, or from a single bastion host. Finding networks that block odd ports starts loosing its charm after you've changed the port, and several years ago it was a pain to get some mobile ssh clients to use alternate ports.

Root login I generally believe should be turned off, and it certainly should not be allowed with passwords. I tend to think a well configured set of keys(one for each user who needs root) poses the same risk as users with sudo *, or the root password in su. As much as I hate to admit it there are some occasions where remote root access has saved the day.

jackalope• 14 years ago

Don’t Leave You Agents Running After You Log Out

You can list and remove keys with ssh-add:

  ssh-add -l
  ssh-add -D

See the ssh-add man page for more options.

dredmorbius3• 14 years ago

There are a few additional dimensions to this:

You're running ssh-agent on a desktop (or laptop) system which you leave either suspended or locked (you hope) via a screensaver (see the recent xscreensaver hotkey exploit/bug).

You're running ssh-agent directly via a shell on remote hosts (bad idea).

You can set a timeout for ssh-agent keys with the '-t life' option (default: seconds). Or when adding an identity. However there's no way to specify this in a config file (for sane defaults), and most mechanisms for launching ssh-agent don't allow the user to interact with the initiation in any sane way (e.g.: /etc/X11/Xsession*).

Specifying, say, 43200 - 86400 seconds (for a desktop), or some low multiple of 3600 seconds (for remote sessions) might be reasonably sane.

I'd pick agent forwarding over remote agents myself.

gioele• 14 years ago

A nice and tidy way to generate a ssh key for a single service: http://retrieve.tumblr.com/post/228790418/create-ssh-key-for...

I have one for github, one for gitorious, one for each of my remote servers, one for for my university lab boxen, etc. You should as well.

alexchamberlain8• 14 years ago

That is a fantastic website!

orbitingpluto• 14 years ago

Extra Don't:

Don't blindly accept key fingerprints, especially when the public key should already be in your known hosts file already and then type the password! ssh-keygen -l -f file is your friend.

Extra Dos:

1) Lie to your PHB that telnet is no longer included and that everyone must now use SSH and that there is absolutely no option to not have account passwords anymore. (This is a true story.)

2) Use it! Tunnel through port 53 and redirect to port 22 down the line when you are at a coffee shop instead of clicking on the "I Agree" button on the web portal and having everything you do being data mined. (In a TOS I saw one that granted perpetual rights to access your FB account - until you change your password of course. You had the option of using a CC to purchase access or by logging into FB.) Most of these coffee shop/airport portals don't block traffic on port 53 because of DNS. Most Starbucks block TCP on 53 now.

Nick_C• 14 years ago

> Do use ssh-agent

> exec ssh-agent bash

Or, if you are already in bash, "eval `ssh-agent -s`" which exports the necessary environment variables.

SSH Do’s and Don’ts

Related Stories