I've heard multiple multiple times to never leave SSH with a password open over the internet. Why is this so bad?

I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack?

Are there more things to consider than just bruteforce or am I missing anything else?

  • 1
    From personal experience, the attackers will keep trying until they get in or you close the port (I eventually closed the port). Keeping the port open and using a strong password leaves the possibility of a brute-force attack guessing the password.
    – ztk
    Commented Feb 2, 2016 at 15:23
  • 1
    Have a look security.stackexchange.com/questions/110706/… Commented Feb 2, 2016 at 15:43
  • 2
    Ok, But an answer says that if he uses Fail2Ban.. He will not have to worry about brute forcing of this sort.
    – Ethereal
    Commented Feb 2, 2016 at 15:49
  • 5
    @ztk: Or until you and they and all their descendants are dead of old age and the universe has decayed into a featureless blob. With a decently strong password, that last one is the one that will happen first. Commented Feb 2, 2016 at 18:23
  • 7
    Another relevant post: Did I just get hacked. Even if you're sure that you would never use an insecure password, you're still at risk if a package owner does something stupid like creates a service user with a weak password (or no password at all).
    – Johnny
    Commented Feb 2, 2016 at 23:04

6 Answers 6


Why is this so bad?

Because there are tons of bots just scanning the web for open ports and trying to log in, once a scanner bot finds an open SSH port it may be queued for another bot (or botnet) to try to brute force the password. One of the risks here is that eventually, they may succeed in figuring out the password and take control of the server.

I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack?

Having a long password is a mitigation technique, however the resources (bandwidth, disk space used for logs and CPU for example) consumption of a brute-force attack can also be damaging.


Some techniques to mitigate a brute-force attack on SSH:

  • 28
    I would add to your list: disable root login via ssh. Most bots are just trying to hit root. I do not see an issue with leaving ssh open as long as it has a secure password and you're not logging in remotely as root. Commented Feb 2, 2016 at 17:06
  • 6
    @paulburkeland: There's no reason to disable root via ssh if you use pubkey, and many good reasons to leave it open. On a hardened/locked-down system, having ssh accept root login means you can remove all suid binaries (su, etc.) from the system and thereby completely eliminate a big attack surface (the dynamic linker) for local attacks. Commented Feb 2, 2016 at 20:02
  • 6
    using knockd for "Port Knocking" to hide your SSH server, will also do a lot to hide you from the scripts. Commented Feb 2, 2016 at 20:03
  • 5
    @R.. You're trading one attack surface (su) for another (login as root). I would rather that if they make an initial breach, then there is some threat that they might attack me and become root, instead of a worse situation where the attacker is just instantly giving a root prompt with no further work required. Instead of using the known username of root, they have to guess which user accounts can escalate to root, and those efforts may be more prone to being logged in greater detail by my equipment. Plus, I can reverse some progress of anyone getting close (by taking away the remote access)
    – TOOGAM
    Commented Feb 2, 2016 at 23:11
  • 5
    I found that merely hardening sshd a bit killed the vast majority of the bots out there, making them unable to communicate with the server. There is no longer enough brute force traffic to trigger fail2ban! Commented Feb 3, 2016 at 1:24

The main risk is that the initial connection can be intercepted by a Man-In-The-Middle, so an attacker can retrieve the password.

The first time a user connects to an SSH server, something similar to the following is displayed:

$ ssh scanme.nmap.org
The authenticity of host 'scanme.nmap.org (' can't be established.
ECDSA key fingerprint is SHA256:8iz5L6iZxKJ6YONmad4oMbC+m/+vI9vx5C5f+qTTGDc.
Are you sure you want to continue connecting (yes/no)?

Now, unless every user is going to verify that fingerprint to ensure that it's your server, then there is a risk that their connection has been intercepted (e.g. MITM on their network directly intercepting traffic, or some type of DNS hijack).

This is because SSH is "Trust on First Use". If you've connected to that host before and the key suddenly changes then the following message is displayed instead, warning the user.

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
RSA host key for ras.mydomain.com has changed and you have requested strict checking.
Host key verification failed.

The warning will mitigate this attack for users that have already connected from that particular client.

Other, less critical risks of having SSH open on the internet is that there are many bots out there finding and attempting logins against such servers. If you have a strong password on all accounts, then the risk of compromise is very low (by strong I mean one that definitely won't be in a word list the attacker may use or create). Usual rules apply - eg no password reuse, password stored securely, etc. The downside is that log files will quickly build up with all the authentication attempts received.

Regarding SSH itself in any authentication mode, as this is another service there is a chance of vulnerabilities being discovered that could automatically be exploited by such bots. However, the risk of this is no greater to that of a web server or web application of being exploited. Like any server with public services, a good vulnerability management strategy is recommended.

Also see this answer, the part related to SSH warning messages and the risk of continuing, even with public key authentication.


I've heard multiple multiple times to never leave SSH with a password open over the internet. Why is this so bad?

I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack?

The very strong benefit of disabling password SSH logins is really in preventing default accounts with weak passwords or users who choose weak passwords from being brute-forced. Right now you might have only a few accounts with no weak passwords, but something might be installed in the future where that isn't the case. The more systems or more complexity you have over time, the higher that risk becomes.

Anecdotal case: an acquaintance of mine lost his server and everything on it because he gave a friend an account with the password of changeme that wasn't changed. No remote backups were created either, so he lost everything.

SSH keys are dramatically more secure by default. Unless key generation is broken, the lowest level of compromise requires getting the users key. Whereas with passwords the level is just guessing when somebody exposes a weak password. It's about making sure that future human failures are guarded against.

  • 1
    Unless P = NP... Commented Feb 3, 2016 at 19:42

Another thing to consider is the possibility of vulnerabilities (albeit known for some time or zero-day) in the sshd daemon itself, which could be exploited by an attacker. To mitigate this, it's best to open sshd only to users working from known IPs that you trust, or through a VPN, if possible.

  • I second the VPN; it is also cuts down drastically in log size Commented Feb 2, 2016 at 15:34

There are a few different reasons why it is safer to use public key authentication rather than password authentication:

  • The secret key never leaves the client machine, thus it is harder to intercept the secret key than the password. This is important in case an attacker perform a mitm-attack against your first connection where the host key is not previously known. It is also imporant in case the server has been compromised by an attacker.
  • Using public key authentication protects you against full mitm-attacks. If an attacker were to perform a mitm-attack against your first connection, you might not verify the host key. However if you use public key authentication to authenticate, then the authentication is tied to the ssh session ID, which prevents the attacker from using the same authentication to pass the connection on to the legitimate server. This reduces the attack from a full mitm-attack to only intercepting the connection, which will often be easier for the user to notice. (For example when the user looks for a file known to be on the real server, but not known to the attacker, then the user will notice something is not right.)

Given that I recommend against using password authentication, I will also advice against leaving it enabled on your ssh server for the following reasons:

  • Attackers will attempt password brute force attacks. If you have any user on the system with a weak password, there is a possibility that such an attack succeeds.
  • Even if all users on the system have strong passwords, attackers will still try to brute force the passwords. This will consume resources on the server. Occasionally I have seen such brute force attacks be so aggressive that legitimate logins were failing due to the server being overloaded.
  • If you get used to ssh servers never accepting passwords, you are more likely to notice in case an attacker some day try to pull a mitm-attack on you and present you with a password prompt.

As I understand it, a key is not that different from a password; it is just much, much longer and therefore harder to crack. Plus you need a password on top.

But I would also second that it makes sense to only allow certain IP addresses to even connect to your SSH port. It decreases the log files, and it is generally good practice to only allow access (not login) to a service if needed. So for example to an IP address range of your company's VPN. But never just rely on that.

Moving the SSH port is sometimes suggested, but I see little benefit in that.

Also (off-topic): Never allow SSH login for root.

  • Most modern Unix/Linux already come with root disable in sshd...you have to allow it expressly (which is a very bad practice) Commented Feb 2, 2016 at 15:57
  • 1
    Some people still do it out of lazyness. It is also important to keep the list of sudo users tight. Commented Feb 2, 2016 at 15:58
  • 1
    SSH allows key with no password authentication Commented Feb 2, 2016 at 16:25
  • 1
    True. But it's better to use key with passwords. Commented Feb 2, 2016 at 16:27
  • 5
    "As I understand it, a key is not that different from a password; it is just much, much longer and therefore harder to crack."... no, you are confusing authentication tokens with public/private keys. The entire point of a private key is that, unlike a password, it is never communicated when authenticating. There is a very fundamental difference here.
    – user541686
    Commented Feb 3, 2016 at 0:44

You must log in to answer this question.

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