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.

  • 45
    Absolute impermeability requires turning the box off. Commented Aug 16, 2010 at 15:44
  • What if you have Wake-on-LAN?
    – rebus
    Commented Oct 20, 2010 at 23:11
  • 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... Commented Oct 22, 2010 at 7:56
  • For key authentication you might limit the Ciphers to the ciphers you really need.
    – user115639
    Commented Sep 4, 2016 at 4:41

13 Answers 13


Use public/private key pairs for authentication instead of passwords.

  1. Generate a passphrase-protected SSH key for every computer that needs to access the server:


  2. Permit public-key SSH access from the allowed computers:

    Copy the contents of ~/.ssh/id_rsa.pub from each computer into individual lines of ~/.ssh/authorized_keys on 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).

  3. Disable password SSH access:

    Open /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.

  • 5
    -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. Commented Aug 14, 2010 at 18:41
  • 7
    "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.
    – Asa Ayers
    Commented Aug 15, 2010 at 3:17
  • 5
    "impossible" is perhaps overdoing it a bit. Commented Aug 16, 2010 at 15:46
  • 9
    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."
    – Asa Ayers
    Commented Aug 16, 2010 at 16:22
  • @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". Commented Dec 6, 2018 at 19:37

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.

    Add PermitRootLogin no to your /etc/ssh/sshd_config.

  • Limiting the users that can SSH to the server. Either by group or just specific users.

    Add AllowGroups group1 group2 or AllowUsers user1 user2 to limit who can SSH to the server.

  • 2
    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. Commented Apr 21, 2015 at 19:42
  • 5
    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.
    – RichVel
    Commented Aug 10, 2017 at 5:47

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.

  • 1
    For those who belive in security by obscurity (en.wikipedia.org/wiki/Security_through_obscurity) it makes a lot of sense to use another port. I don't though.. Commented Aug 15, 2010 at 10:19
  • 36
    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.
    – bobince
    Commented Oct 12, 2010 at 0:19
  • 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.
    – Andrei C
    Commented Aug 2, 2017 at 13:38
  • 1
    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 Commented Dec 23, 2017 at 8:51

Enable two factor authentication with HOTP or TOTP. This is available from 13.10 onwards.

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.


  1. sudo apt-get install libpam-google-authenticator

  2. Have each user run the google-authenticator command, which generates ~/.google-authenticator and helps them configure their two factor devices (eg. the Google Authenticator Android app).

  3. Edit /etc/ssh/sshd_config and set:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
  4. Run sudo service ssh reload to pick up your changes to /etc/ssh/sshd_config.

  5. Edit /etc/pam.d/sshd and replace the line:

    @include common-auth


    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. Commented Aug 15, 2010 at 9:40
  • 2
    @Mark - good point, but doesn't that sound like a poorly written SFTP client? Why would they keep reconnecting to the SSH port when they could just open more SSH channels?
    – mpontillo
    Commented Aug 24, 2010 at 4:32

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.

  • 2
    Is there some option like 10 failed login attempts before banning the ip address? Commented Feb 26, 2014 at 14:48

If I want to have some additional security or need to access SSH servers deep inside some corporate network I setup a hidden service by using the anonymisation software Tor.

  1. Install Tor and setup the SSH server itself.
  2. Make sure sshd only listens at localhost.
  3. Open /etc/tor/torrc. Set HiddenServiceDir /var/lib/tor/ssh and HiddenServicePort 22
  4. Look at var/lib/tor/ssh/hostname. There is a name like d6frsudqtx123vxf.onion. This is the address of the hidden service.
  5. Open $HOME/.ssh/config and add some lines:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:,socksport=9050

Furthermore I need Tor on my local host. If it is installed I can enter ssh myhost and 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".

  • 10
    Security by advanced obscurity, but very interesting. Commented Aug 29, 2013 at 9:25

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.

  • 3
    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. Commented Aug 28, 2012 at 4:54
  • 1
    Good idea. Although I am through a period with much less time to participate. My answer is a "community wiki" so feel free to add the link information if you have the time.
    – Huygens
    Commented Sep 11, 2012 at 19:42

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.

  1. 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.

  2. 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).

  3. 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).

  4. 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...

  5. 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.

  6. 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.


For large numbers of users/certificates consider LDAP integration. Large organizations use LDAP as a repository for user credentials and certificates stored on badges or fobs, whether the certificates are used for authentication or signing emails. Examples include openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks...

Computers and groups can also be managed in LDAP giving central credential management. That way help desks can have a one stop shop to deal with large populations.

Here's a link to centOS integration: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html


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.


I wrote a small tutorial on doing this recently. Basically, you need to be using PKI and my tutorial also shows how to use Two-Factor Authentication for even more security. Even if you use none of those things, there's also some tidbits about securing the server by removing weak cipher suites and other basics. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/


You can also block based on country of origin using the geoIP database.

Basically if you live in the US then there is no reason for somebody in Russia to connect to your SSH so they will be automatically blocked.

The script can be found here: https://www.axllent.org/docs/view/ssh-geoip/

You can also add iptables commands to it (I did for my droplets) to auto drop all traffic to/from those IPs.

  • 1
    Occasionally the GeoIP databases can be wrong - I was asked was I in Moscow yesterday... eh no! :)
    – Sean
    Commented Oct 24, 2017 at 12:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .