OpenSSH Server Best Practices (security related)
cyberciti.biz
cyberciti.biz
Additional configuration complexity is pretty much a non-issue. One extra "Port" line in ~/.ssh/config or the equivalent UI textfield box in putty.
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 ACCEPTWhat he's looking for instead is:
echo "TMOUT=300 >> /etc/bashrc
It's still easily thwarted if the user keeps "top" running in it, or something.
Not "many people" use ssh to begin with.
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.
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.)
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?
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.
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.
The idea would be to have everything auto-login when the drive is mounted and nothing auto-login when it is not.
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.
- 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).
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.