59

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?

Mmmh mmh
  • 103
  • 5
Ethereal
  • 703
  • 1
  • 6
  • 6
  • 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 Feb 02 '16 at 15:23
  • So the only real downside is the annoyance and the thought of it being constantly bruteforced? I mean, I wouldn't do this in the first place.. But I wanted to know what exactly is the reasoning. So technically a person with a strong PW has nothing to worry about... Right? – Ethereal Feb 02 '16 at 15:31
  • wrong. Better use RSA certs and even then you will see an huge volume of logs – Rui F Ribeiro Feb 02 '16 at 15:35
  • 1
    Have a look http://security.stackexchange.com/questions/110706/am-i-experiencing-a-brute-force-attack/110708 – Rui F Ribeiro Feb 02 '16 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 Feb 02 '16 at 15:49
  • Strangely I am not being notified of your messages... The first answer is mine on that URL. Fail2ban does provide some degree of protection, but it is not a silver bullet, and much less nowadays with coordinated network of zombie machines brute-forcing your SSH service. I think I mention something about it there. – Rui F Ribeiro Feb 02 '16 at 15:55
  • I installed fail2ban, a fake sshd daemon on port 22, and now armies of Chinese bots try and fail, get angry and UDP DDoS my servers every other week... – ThoriumBR Feb 02 '16 at 17:36
  • 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. – Nate Eldredge Feb 02 '16 at 18:23
  • Thorium, what do they do with UDP? – Rui F Ribeiro Feb 02 '16 at 19:20
  • 7
    Another relevant post: [Did I just get hacked](https://superuser.com/questions/1034137/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 Feb 02 '16 at 23:04
  • @RuiFRibeiro Why do you think it is strange that you weren't notified of Ethereal's message? Except for comments that show an at sign followed by your name, you're notified if someone posts to your question, or your answer, but not someone else's that you comment on. (AFAIK) – TOOGAM Feb 02 '16 at 23:13
  • Hmm had no idea about that, now I understand. Thank you @TOOGAM – Rui F Ribeiro Feb 03 '16 at 05:15
  • 1
    @RuiFRibeiro: What TOOGAM said is not 100% correct – you will _also_ be notified when a post author comments on the post after you have left a comment, **if** you are the only one to have done so (because then it is likely the new comment was directed at you). Taking this comment thread as an example, ztk should have got a notification about the second comment; but then you, as another person, commented, and from that point on only the OP received further notifications. – chirlu Feb 03 '16 at 07:37

6 Answers6

69

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:

Community
  • 1
Purefan
  • 3,570
  • 19
  • 26
  • 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. – nyxgeek Feb 02 '16 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. – R.. GitHub STOP HELPING ICE Feb 02 '16 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. – Scott Carlson Feb 02 '16 at 20:03
  • @R.. Touché salesman, touché. – nyxgeek Feb 02 '16 at 20:07
  • 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 Feb 02 '16 at 23:11
  • 1
    @TOOGAM: What is your threat model? Brute-forcing RSA? Regardless of whether sshd allows root login, it has to *run as root* itself so that it can setuid to the target user on login, so I'm failing to see the increase in attack surface that comes from enabling root login via ssh (assuming you don't also enable passwords). – R.. GitHub STOP HELPING ICE Feb 02 '16 at 23:31
  • 5
    I found that [merely hardening sshd a bit](https://stribika.github.io/2015/01/04/secure-secure-shell.html) 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! – Michael Hampton Feb 03 '16 at 01:24
  • That conversation might be better suited in http://chat.stackexchange.com/rooms/151/the-dmz. – Purefan Feb 03 '16 at 09:03
  • @TOOGAM It sounds like you are unaware that [OpenSSH already uses privilege separation](http://www.citi.umich.edu/u/provos/ssh/privsep.html) and has done so for over a decade. – Michael Hampton Feb 03 '16 at 18:10
  • @MichaelHampton Inapplicable to my position, because my statements were not based on concerns about OpenSSH bugginess. By only allowing SSH to log into a non-root account, doing root-things requires: A) figure out what usernames can escalate. B) get a prompt for that user. C) Figure out how to escalate (which may have additional authentication challenges). In contrast, if they can log in as the "root" account, they've basically already accomplished steps A and C, and only need to need to do the equivalent of step B. – TOOGAM Feb 03 '16 at 22:40
  • 4
    +1 for damaging resources: i.e. my time. After having to delete logs of millions of failed SSH logins a couple times after they filled up my tiny VPS' disk and caused other strange errors I learned my lesson. – Nick T Feb 03 '16 at 22:56
  • The last two items on your list are not only fairly trivial to implement, but also a HUGE leap forward in terms of "benefits" to the admin in both peace-of-mind and amount-of-work checking logs.... – Kevin_Kinsey Feb 04 '16 at 18:37
28

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.

Community
  • 1
SilverlightFox
  • 33,698
  • 6
  • 69
  • 185
12

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.

Community
  • 1
Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172
3

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.

mti2935
  • 21,098
  • 2
  • 47
  • 66
2

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.
kasperd
  • 5,442
  • 1
  • 19
  • 38
0

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.

Peter Mortensen
  • 885
  • 5
  • 10
Øle Bjarnstroem
  • 213
  • 1
  • 2
  • 5