How to harden an SSH server?
What measures can/should I take to make sure that security around my SSH server is absolutely impermeable?
This will be community wiki from the start, so lets see what people do to secure their servers.
The problem would be the LAN part... Wake-on-LAN packages are not routed, so you would have to have access to a machine inside the LAN to send the WOL package...
For key authentication you might limit the Ciphers to the ciphers you really need.
Make the sshd block client IP's that have failed to supply correct login information "DenyHØsts" can do this job quite effectively. I have this installed on all my Linux boxes that are in some way reachable from the great outside.
This will make sure that force-attacks on the SSHD won't be effective, but remember (!) this way you can end up locking yourself out if you forget you password. This can be a problem on a remote server that you don't have access to.
Use public/private key pairs for authentication instead of passwords.
Generate a passphrase-protected SSH key for every computer that needs to access the server:
Permit public-key SSH access from the allowed computers:
Copy the contents of
~/.ssh/id_rsa.pubfrom each computer into individual lines of
~/.ssh/authorized_keyson the server, or run
ssh-copy-id [server IP address]on every computer to which you are granting access (you'll have to enter the server password at the prompt).
Disable password SSH access:
/etc/ssh/sshd_config, find the line that says
#PasswordAuthentication yes, and change it to
PasswordAuthentication no. Restart the SSH server daemon to apply the change (
sudo service ssh restart).
Now, the only possible way to SSH into the server is to use a key that matches a line in
~/.ssh/authorized_keys. Using this method, I don't care about brute force attacks because even if they guess my password, it will be rejected. Brute-forcing a public/private key pair is impossible with today's technology.
-1: Generally access is granted to individual not computers, creating a key for each potential client computer connecting to the server is unreasonable. Your last statement is not correct, per your sugestion and because you didn't suggest to set a passphrase for the private keys having access/compromising of any of the client systems would automatically grant access to the SSH server. SSH key authentication is recommended but the private keys must properly protected and it should be used on an individual basis, not in a distributed fashion as described.
"Generally access is granted to individual not computers, creating a key for each potential client computer connecting to the server is unreasonable" There are many options and I think describing how to securely transfer a private key to every client seems outside the scope of this question. I'm not presenting all options, just a simple one that I think people can understand. "... should be used on an individual basis, not in a distributed fashion as described" This seems to contradict your previous statement and I did not describe anything as distributed.
This is why I say "impossible". No one has computers this fast this small this many or that much time. "Imagine a computer that is the size of a grain of sand that can test keys against some encrypted data. Also imagine that it can test a key in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 meter. The cluster of computers would crack a 128-bit key on average in 1,000 years."
@ThorbjørnRavnAndersen "Impossible" is not really overstating it, as long as you use a strong key. I can't find a quote right now, but with current key lengths, brute force attacks are infeasible "until computers are made up of something other than matter and occupy something other than space".
I would suggest:
Using fail2ban to prevent brute force login attempts.
Disabling logging in as root via SSH. This means an attacker had to figure out both the username and the password making an attack more difficult.
PermitRootLogin noto your
Limiting the users that can SSH to the server. Either by group or just specific users.
AllowGroups group1 group2or
AllowUsers user1 user2to limit who can SSH to the server.
The **AllowUsers** and **AllowGroups** doesn't accept a comma **,** as a delimiter. Make sure you don't try this remotely. I keep getting locked out of my NAS by doing this incorrectly.
**Always validate** your `sshd` config is correct before you restart sshd, to avoid locking yourself out of the machine. See this blog for details - just run `sshd -T` after a config change before restarting the main `sshd`. Also, **have an SSH session open** on the machine when you make the config change, and don't close this until you've validated the config as mentioned and maybe have done a test SSH login.
Other answers provide security, but there is one thing you can do which will make your logs quieter, and make it less likely that you'll be locked out of your account:
Move the server from port 22 to another one. Either at your gateway, or on the server.
It doesn't increase the security, but does mean all the random internet scanners won't clutter up you log files.
For those who belive in security by obscurity (http://en.wikipedia.org/wiki/Security_through_obscurity) it makes a lot of sense to use another port. I don't though..
It's not about Security Through Obscurity (although the obscurity can have a marginal positive effect). It's about reducing the background noise of endless brute force attempts. You can't usefully audit your access failure logs if they're full of automated attacks; fail2ban doesn't reduce the volume enough given the number of attackers and the prevalence of distributed (botnet) and throttled attacks. With ssh on an unusual port, you *know* attacks you see in the logs come from a real attacker interested in your box. I strongly recommend it.
Since you can query internet services like shodan for web-facing ssh servers, or using nmap and banner capture makes changing the default port pretty much pointless. i would advise against this.
Shodan doesn't grab all 65k ports so changing to a high port will likely remove it from their scans. Also if you move to a random high port the attacker will likely need to do 65K TCP scans (very noisy) to find your service to start attacking it. Both of these are wins from a security perspective, so moving to a high port is generally a good plan. Another one is that by moving to a high port you can have a better idea that someone who is attacking you is targeting your systems specifically as opposed to just general background Internet noise
This includes using public key authentication over password authentication as in another answer here, but also requires the user prove he holds his second-factor-device in addition to his private key.
sudo apt-get install libpam-google-authenticator
Have each user run the
google-authenticatorcommand, which generates
~/.google-authenticatorand helps them configure their two factor devices (eg. the Google Authenticator Android app).
ChallengeResponseAuthentication yes PasswordAuthentication no AuthenticationMethods publickey,keyboard-interactive
sudo service ssh reloadto pick up your changes to
/etc/pam.d/sshdand replace the line:
auth required pam_google_authenticator.so
More details on different configuration options are my blog post from last year: Better two factor ssh authentication on Ubuntu.
Here's one easy thing to do: install ufw (the "uncomplicated firewall") and use it to rate limit incoming connections.
From a command prompt, type:
$ sudo ufw limit OpenSSH
If ufw is not installed, do this and try again:
$ sudo aptitude install ufw
Many attackers will try to use your SSH server to brute-force passwords. This will only allow 6 connections every 30 seconds from the same IP address.
+1 Using limit can be good. However should point out I have encountered issues when using the built in sftp server as it limits the connections for this as well.
- Install Tor and setup the SSH server itself.
- Make sure sshd only listens at
HiddenServicePort 22 127.0.0.1:22.
- Look at
var/lib/tor/ssh/hostname. There is a name like
d6frsudqtx123vxf.onion. This is the address of the hidden service.
$HOME/.ssh/configand add some lines:
Host myhost HostName d6frsudqtx123vxf.onion ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
Furthermore I need Tor on my local host. If it is installed I can enter
ssh myhostand SSH opens a connection via Tor. The SSH server on the other side opens its port only on localhost. So nobody can connect it via "normal internet".
There is a Debian Administration article on this topic. It covers basic SSH server configuration and also firewall rules. This could be of interest also to hardened an SSH server.
See there article: Keeping SSH access secure.
Bit late, but please, when answering questions, copy the important parts from a link so that if the link decays the information is still here.
My approach to SSH hardening is... complex. The following items are in terms of how I do it, from the edge-most border of my network(s) to the servers themselves.
Border-level filtering of traffic through IDS/IPS with known service scanners and signatures in the blocklist. I achieve this with Snort via my border firewall (this is my approach, a pfSense appliance). Sometimes, I can't do this though, such as with my VPSes.
Firewall/Network filtering of the SSH port(s). I explicitly only allow certain systems to reach into my SSH servers. This is either done via a pfSense firewall at the border of my network, or the firewalls on each server explicitly being configured. There are cases where I can't do this, though (which is almost never the case, except in private pen-testing or security testing lab environments where firewalls won't help test things).
In conjunction with my pfSense, or a border firewall NAT-ing the internal network and separating from the Internet and the systems, VPN-Only Access to Servers. Gotta VPN into my networks to get to the servers, because there's no Internet-facing ports as such. This definitely doesn't work for all my VPSes, but in conjunction with #2, I can have one VPS be the 'gateway' by VPNing into that server, and then permit it's IPs to the other boxes. That way, I know exactly what can or cannot SSH in - my one box that is the VPN. (Or, in my home network behind pfSense, my VPN connection, and I'm the only one with VPN access).
Where #3 is not doable, fail2ban, configured to block after 4 failed attempts and block the IPs for an hour or more is a decent protection against people constantly attacking with bruteforcing - just block em at the firewall automatically with fail2ban, and meh. Configuring fail2ban is a pain though...
Port obfuscation by changing the SSH port. However, this is NOT a good idea to do without any additional security measures as well - the mantra of "Security through Obscurity" has already been refuted and disputed in many many cases. I have done this in conjunction with IDS/IPS and network filtering, but it's still a VERY poor thing to do on its own.
MANDATORY Two-Factor Authentication, via Duo Security's Two-Factor Authentication solutions. Every single one of my SSH servers has Duo configured on it, such that in order to even get in, 2FA prompts happen, and I have to confirm each access. (This is the ultimate helpful feature - because even if someone has my passphrase or breaks in, they can't get past the Duo PAM plugins). This is one of the biggest protections on my SSH servers from unauthorized access - each user login MUST tie back to a configured user in Duo, and since I have a restrictive set, no new users can be registered in the system.
My two-cents to securing SSH. Or, at least, my thoughts on approach.
You might want to checkout the FreeOTP app from RedHat instead of using Google Authenticator. Sometimes when updating the app, they lock you out! ;-)
If you want to use other hardware tokens like a Yubikey or an eToken PASS or NG or if you have many users or many servers, you might want to use an opensource two factor authentication backend.
Lately I wrote a howto about this.