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.
> 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.
"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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
[+] [-] cmsj|14 years ago|reply
* 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...
[+] [-] tptacek|14 years ago|reply
[+] [-] abhaga|14 years ago|reply
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.
[+] [-] alexchamberlain|14 years ago|reply
[+] [-] mapgrep|14 years ago|reply
"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.
[+] [-] talaketu|14 years ago|reply
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.
[+] [-] ordinary|14 years ago|reply
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.
[+] [-] augustl|14 years ago|reply
[+] [-] orbitingpluto|14 years ago|reply
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.
[+] [-] caf|14 years ago|reply
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.
[+] [-] munin|14 years ago|reply
[+] [-] gpapilion|14 years ago|reply
[+] [-] there|14 years ago|reply
http://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_o...
[+] [-] mappu|14 years ago|reply
- Disallow root login
[+] [-] alexchamberlain|14 years ago|reply
[+] [-] gpapilion|14 years ago|reply
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.
[+] [-] jwn|14 years ago|reply
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.
[+] [-] mooism2|14 years ago|reply
[+] [-] ashconnor|14 years ago|reply
[+] [-] gioele|14 years ago|reply
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.
[+] [-] alexchamberlain|14 years ago|reply
[+] [-] emmelaich|14 years ago|reply
Off Topic: I was so distracted by the apostrophe in "Do's" I spent 5 minutes researching it. Conclusion: I think it's ok.
[+] [-] dredmorbius|14 years ago|reply
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.
[+] [-] emillon|14 years ago|reply
That's basically what a passphrase does already.
[+] [-] alexchamberlain|14 years ago|reply
PS Do's should be Dos, but it's quite hard to read.
[+] [-] Nick_C|14 years ago|reply
> exec ssh-agent bash
Or, if you are already in bash, "eval `ssh-agent -s`" which exports the necessary environment variables.
[+] [-] jackalope|14 years ago|reply
You can list and remove keys with ssh-add:
See the ssh-add man page for more options.[+] [-] dredmorbius|14 years ago|reply
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.
[+] [-] ColdAsIce|14 years ago|reply
[deleted]