14

I'm freaking out a little bit at the moment. I am SSHing into a remote server that I have recently commissioned. I'm doing this as root. I have installed fail2ban and had a massive amount of banned IPs in the log.

The last time I logged in i noticed my terminal being really laggy then my internet connection went down. When I bought it back up after about 5 min i logged back into the server and did a 'who' and realised there were two root users logged in. I would have thought that if my connection terminated the process from the last session would have been stopped on the server?

The connection ended with a 'Write failed: Broken pipe' when i first got disconnected. I killed the bash session with the other root. I don't know much about ssh security however could sessions be hijacked? is there a way of checking this? I need to continue logging in via ssh what precautions should I take? If I was somehow going through a proxy to reach my server (like a man in the middle attack) could they hijack my ssh session?

40

The root logins are probably dangling shell sessions that once were you. Your server is also probably getting dDOS'd with all the attempted logins hammering it.

Lock down SSH. Don't allow root login, and those requests that are trying to brute force this machine will fail immediately (taking far fewer resources). Log in as a normal user and elevate permissions via sudo, a practice you should be doing anyways. Also restrict SSH login to a list of client IPs so that the unsavory machines can't even try to log in.

Use SSH keys instead of passwords for user login. They're easier to deal with, and can be password protected themselves in case you accidentally give a private key out to the wrong place (giving you time to replace them and invalidate the old one). As @EEAA mentioned in the comments, you must also disable password based authentication if you wish to restrict clients to using only keys instead of both passwords and keys.

If the mongol clans continue to batter your city wall, maybe move SSH to a different high port (under 1024, as @AustinBurke pointed out - so as to use a privileged port) instead of 22. This will reduce traffic on that port if this is a problem for you (and most bots aren't very graceful, so they'll only attempt on 22). It won't stop things from trying port 22 or even scanning your machine to see what port is listening on SSH, and in most cases is a needless inconvenience. But it may help.

Others might be able to provide more tips, but these are pretty generic security measures for a publicly facing SSH server.

  • 22
    Using keys isn't enough. One must disable password authentication as well. – EEAA Apr 3 '17 at 0:42
  • 4
    @marcelm Does "massive amount of banned IPs in the log" not hint that this may be happening? – TripeHound Apr 3 '17 at 9:00
  • 4
    @tripehound No it doesn't. It says nothing about the relative resources consumed. – marcelm Apr 3 '17 at 11:42
  • 3
    It is a hint to that effect though, @marcelm. – Lightness Races in Orbit Apr 3 '17 at 11:50
  • 4
    While that is feasible in this universe, ssh is pretty damn secure. You can of course grab that traffic in-flight and store it in its encrypted state, but a Diffie–Hellman key exchange is used to establish an encrypted channel. Cracking this ain't even possible if you have both the private and public ssh key that was used for authentication, since the stream key was never communicated during the session. By the time someone has cracked that stream, we'll all be dead. – Spooler Apr 3 '17 at 16:13

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.