Why is leaving a passworded SSH over the internet so bad?

Question

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?

Answer 1

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.

Mitigation

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

• Use a different port, don't get a false sense of security with this, but many bots do search for 22 exclusively. (Related question)
• Disable SSH passwords
• Require a private key for logging in
• Throttle connections
• Implement an IPS (Fail2ban and Snort come to mind)
• Restrict login per IP address
• Restrict which users can log in (different than checking the IP address)

Answer 2

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 (45.33.32.156)' 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.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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
5c:9b:16:56:a6:cd:11:10:3a:cd:1b:a2:91:cd:e5:1c.
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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.