OpenSSH Server Best Practices (security related)(cyberciti.biz)
cyberciti.biz
OpenSSH Server Best Practices (security related)
http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
8 comments
Can anyone comment on why password-less ssh-keys are bad? ("#11: Never ever use passphrase free key (passphrase key less) login.")
I usually figure that it just generates some random number based on the time + salt and that is more secure (brute-force attack-wise) than any silly password I could come up with myself.
I usually figure that it just generates some random number based on the time + salt and that is more secure (brute-force attack-wise) than any silly password I could come up with myself.
The password is not what is used to authenticate to the ssh remote. The ssh private key is still used, it's just locked on the client side. You unlock the private key with the passphrase, and then use the unlocked (unencrypted) key to authenticate to the remote.
By using a password-free key, your private key is sitting in plain text on your local machine, which is a potential security risk.
(Apologies is your question is more nuanced than my understanding.)
By using a password-free key, your private key is sitting in plain text on your local machine, which is a potential security risk.
(Apologies is your question is more nuanced than my understanding.)
So, the private key is encrypted on the client side, which requires that the user type their key-password in, so that the client can send the private key in order to authenticate?
I generally use ssh keys so that I dont have to type my password in 50 times a day. Can this be done with a key-password, or does this defeat the entire purpose of having a key-password?
I generally use ssh keys so that I dont have to type my password in 50 times a day. Can this be done with a key-password, or does this defeat the entire purpose of having a key-password?
You can add it to ssh-agent, and it will be kept open for new connections to use.( and, even allow you to extend the keyed login to the next hop) Some desktops will do this automatically, Some are setup to ask for the password each time.
Something I've considered doing is creating a truecrypt volume and somehow sticking all of my pre-shared keys and stored credentials in there, for SSH keys , wifi keys , lastpass & dropbox credentials etc.
So I can mount the volume and be logged automatically into everything then dismount when I'm done.
It's just the pain of rounding all of the various files up.
So I can mount the volume and be logged automatically into everything then dismount when I'm done.
It's just the pain of rounding all of the various files up.
Or just use ssh-agent, encrypt your key, and store everything per-file encrypted in Dropbox like everyone else does.
OSX Keychain stores wifi keys encrypted on disk with a key derived from your user account password.
The only passwords I need to remember are my for my GPG key, my ssh key, Dropbox, and 1Password. Oh, and my user account.
OSX Keychain stores wifi keys encrypted on disk with a key derived from your user account password.
The only passwords I need to remember are my for my GPG key, my ssh key, Dropbox, and 1Password. Oh, and my user account.
I'd rather not use per file encryption with dropbox because that could break syncing in big files.
The idea would be to have everything auto-login when the drive is mounted and nothing auto-login when it is not.
The idea would be to have everything auto-login when the drive is mounted and nothing auto-login when it is not.
Besides the reference made by "wiredfool" about ssh-agent further down (which remembers the decrypted keys once you've entered the corresponding password so that other ssh sessions can use them without bothering you again, and: this connection can also be forwarded through consecutive ssh-sessions!)...
- You can mitigate the danger arising from unencrypted ssh-keys laying around by either generating special-purpose users for a certain task, or...
- you can set restrictions on what a certain ssh-key is allowed on the target host. This is described in the sshd(8) manual page, section "AUTHORIZED_KEYS FILE FORMAT".
Of course the other remedy against having to type passwords repeatedly is to use the pretty "ControlMaster" feature: The 2nd and following ssh-session re-uses the already authenticated channel of the first ssh connection. (ssh_config(5) manual page, section on ControlMaster).
- You can mitigate the danger arising from unencrypted ssh-keys laying around by either generating special-purpose users for a certain task, or...
- you can set restrictions on what a certain ssh-key is allowed on the target host. This is described in the sshd(8) manual page, section "AUTHORIZED_KEYS FILE FORMAT".
Of course the other remedy against having to type passwords repeatedly is to use the pretty "ControlMaster" feature: The 2nd and following ssh-session re-uses the already authenticated channel of the first ssh connection. (ssh_config(5) manual page, section on ControlMaster).
That key by itself becomes a valid access token.
If someone snarfs your key from local storage, they are you. They don't need a 2nd secret (the passphrase) to unlock the key.
If you use methods such as ssh-agent, you get all the convenience of a passwordless key (save the entering the passphrase into the agent) without the security risks.
You may find it necessary to use passwordless keys for some server processes, say, Nagios authentication or running remote jobs between servers. So long as you isolate these keys, restrict access to known hosts / IP ranges, etc., you're fairly well covered. Forced commands are another option to reduce the risk of such keys, though these aren't always appropriate.
If someone snarfs your key from local storage, they are you. They don't need a 2nd secret (the passphrase) to unlock the key.
If you use methods such as ssh-agent, you get all the convenience of a passwordless key (save the entering the passphrase into the agent) without the security risks.
You may find it necessary to use passwordless keys for some server processes, say, Nagios authentication or running remote jobs between servers. So long as you isolate these keys, restrict access to known hosts / IP ranges, etc., you're fairly well covered. Forced commands are another option to reduce the risk of such keys, though these aren't always appropriate.
If you don't use passwords on your keys, then any one who can access the key files on your local system, could access the remote server. Not using passwords removes an important layer of security.
That said, often you need to have password-less keys in order for systems to automatically communicate. For example, I setup backup servers without passwords.
That said, often you need to have password-less keys in order for systems to automatically communicate. For example, I setup backup servers without passwords.
Another thing is using Google's free authentication services to add two-factor authentication. It's very simple to set up via PAM.
fail2ban is pretty great. when so many (partly very obvious) advices are included. fail2ban should as well.
(edit: a method for this is already in the story, but this is slightly more flexible/secure) Rate limit incoming SSH connections:
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH --rsource -j DROP
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT[deleted]
There is some good information here (e.g., the fairly comprehensive list of methods to deter brute-force attacks in #16). However, it looks like the majority of the options mentioned here are the default settings for current versions of OpenSSH.
Setting ClientAliveInterval and ClientAliveCountMax does not disconnect idle users. It's for detecting failed network connections. Your ssh client will still reply to protocol level alive checks even if you are sitting idle at a prompt.
What he's looking for instead is:
What he's looking for instead is:
echo "TMOUT=300 >> /etc/bashrc
It's prudent to do this as many people just leave ssh sessions hanging open forever, and their desktops don't auto-lock the screensaver.
It's still easily thwarted if the user keeps "top" running in it, or something.
It's still easily thwarted if the user keeps "top" running in it, or something.
> many people just leave ssh sessions hanging open forever, and their desktops don't auto-lock the screensaver
Not "many people" use ssh to begin with.
Not "many people" use ssh to begin with.
I'm talking about engineering staff, like me, my co-workers, and (very likely) you.
Who would hire someone to use ssh who doesn't know enough to encrypt their disk and lock their screen on a timeout?
I've used timeoutd to disconnect idle users.
Additional configuration complexity is pretty much a non-issue. One extra "Port" line in ~/.ssh/config or the equivalent UI textfield box in putty.