15

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?

Improve this question

1 Answer 1

Reset to default
42

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.

Improve this answer
12
  • 23
    Using keys isn't enough. One must disable password authentication as well.
    – EEAA
    Apr 3, 2017 at 0:42
  • 4
    @marcelm Does "massive amount of banned IPs in the log" not hint that this may be happening?
    – TripeHound
    Apr 3, 2017 at 9:00
  • 4
    @tripehound No it doesn't. It says nothing about the relative resources consumed.
    – marcelm
    Apr 3, 2017 at 11:42
  • 3
    It is a hint to that effect though, @marcelm.
    – Lightness Races in Orbit
    Apr 3, 2017 at 11:50
  • 5
    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, 2017 at 16:13

You must log in to answer this question.

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