16 ms·
SSH Do’s and Don’ts
- caf 15y agoThe 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.
- gpapilion 15y agoThanks. Corrected
- munin 15y agoin the presence of compromised hosts using ForwardAgent is basically analogous to copying your private key around! (somewhat)
- ninjin 15y agoAgreed, 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 15y agoUsing SSH agent forwarding should be used with caution, and with prompting enabled: http://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_os_x_more_secure/ http://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_o...
- mapgrep 15y agoThis 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 15y agoI 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.
- rmc 15y agoIf 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 15y 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 15y agoYour 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?
- mapgrep 15y agoI 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.)
- cmsj 15y agoSince 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-and-tricks.html http://www.tenshu.net/2012/02/sysadmin-talks-openssh-tips-an...
- alexchamberlain 15y agoA voice of reason. This article was terrible.
- abhaga 15y 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.
- alexchamberlain 15y agoPublic keys, surely?
- abhaga 15y agoSorry if I am missing out the sarcasm here :) but I did mean private keys since I am trying to authenticate from the prod machine to the source control server.
- alexchamberlain 15y agoThen you're a fool! Generate new private keys on the PROD server and upload them. I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.
- ColdAsIce 15y agoWhat the hell is it with these "SSH" this and that blog posts? Its a tool. Does it actually need blog posts? Hey, guys, you know cat, use it like this, but dont use it like that, Ill write a blog post on it. Hey guys, netcat, this is how you use it. Hey guys, I just found out about the man command, look this is how you use it. Bunch of hipsters...
- emmelaich 15y agoI (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.
- alexchamberlain 15y agoAhhhhhhhhhhhh! 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.
- dredmorbius 15y agoYour 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 15y agoThe 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.
- jpitz 15y agoThats a problem you have a lot better chance of solving before you lose an SSH key than after.
- dredmorbius 15y agoThat's a case where having multiple keys (for multiple point-of-origin systems) which can access those hosts would be a Really Good Thing. Distributed shell (dsh) and git can be helpful in keeping at least portions of things synched up. You can also mimic dsh with your own hostlist(s) and iterated tasks (for host in $( cat hostlist ); do echo "$host"; ssh $host 'do stuff'; done) ... or the like. If you're managing these boxes as part of a team, having a secondary/tertiary persons with access (or more) can also help. There's the use of password safes to keep track of access credentials as well (another hassle to keep synchronized, of course).
- mappu 15y ago- Don't use the default port - Disallow root login
- mooism2 15y agoWhy disallow root login? What's wrong with allowing root login via public key only? Or via a public key limited by command="..."?
- alexchamberlain 15y agoDo you ever need root login?
- ichilton 15y agoIt'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.
- alexchamberlain 15y agoI'm not using the default port on one machine, but I do on the other. With key based login, is it really necessary?
- Florin_Andrei 15y agoIf there's ever a TCP-based attack against the server, the non-standard port reduces the risk a little bit.
- sespindola 15y agoThe risk reduction is negligible if someone is doing a portscan on your host. Connection attempts to non standard ports will eventually occur. The better solution is to use single packet authorization.[1] 1. http://cipherdyne.org/fwknop/ http://cipherdyne.org/fwknop/
- 15y ago
- jackalope 15y agoDon’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.
- dredmorbius 15y agoThere 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 15y agoA nice and tidy way to generate a ssh key for a single service: http://retrieve.tumblr.com/post/228790418/create-ssh-key-for-a-single-purpose 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.
- alexchamberlain 15y agoThat is a fantastic website!
- orbitingpluto 15y agoExtra 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 15y 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.