33
Have I successfully blocked ssh logins to root? (lemmy.ml)
submitted 2 years ago by to c/linux@lemmy.ml
22 comments fedilink hide all child comments
 

I have a server where I believe I have disabled root login via ssh. I think it is done correctly, as I cannot login with root myself via ssh, but I would've thought that it would be reflected in /var/log/auth.log. Instead, it shows up as failed password entry. Is this intended?

What I've done is to uncomment the PermitRootLogin no line in /etc/ssh/sshd_config. Rest of the config file is left at default.

Bonus question: All login attempts by ssh seems to go over some random port (even my own successful logins). Why is this?

all 22 comments

sorted by: hot top controversial new old
[–] 13 points 2 years ago (1 child)

That all sounds correct to me. The random port you're seeing in the logs is a high port, often referred to as an ephemeral port, and it is common for source ports. All good there.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] [S] 3 points 2 years ago (2 children)

    Ok, thanks - so if I understand correctly then, it is listening on port 22 as a default, and not accepting traffic on any port.

    That brings of the question: wouldn't I be better off changing the SSH-port? And is that so easy as to uncomment the #Port 22 line in the config file and changing the port number to something random, and saving that somewhere? Would I then be able to connect by running ssh myuser@mydomain.com:, or would I need to do anything else to successfully connect?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 11 points 2 years ago (2 children)

    You would need to specify the new port when using ssh (using the -p$PORT option). Just keep in mind that security through obscurity is not considered secure in itself. You could instead consider a service like fail2ban that automatically blocks connections from certain sources depending on your set parameters.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 3 points 2 years ago (1 child)

    Just keep in mind that security through obscurity is not considered secure in itself.

    Do you consider it to not be a helpful measure to take at all?

    I have fail2ban configured - since it is reading from the auth.log, I guess I would not have to make any changes to the configuration there to have it work with a new port?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago* (1 child)

    It's a mixed bag. Personally I wouldn't use a non-standard port.

    Consider that port numbers under 1024 are Privileged Ports. You would either have to make sure that no other privileged service is running on the port you want to use for SSH when using another privileged port or you need to make sure that no unprivileged program tries to use the same port as your SSH service when using a non-privileged. Overall it adds a bit of overhead and possible headaches for barely any gain.

    Fail2ban should work with a different port without any further configuration but it might not.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    It’s recommended you keep the default port because as soon as your IP is known it takes less than 5 minutes to scan every port for an ssh port

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 2 years ago

    It’s recommended you keep the default port because as soon as your IP is known it takes less than 5 minutes to scan every port for an ssh port

    Fair point! I first thought that would be good, as it would discourage all those random connections. My guess is that they won't bother spending 5 minutes on each server, and instead just move on to the next when they fail. But then I realized that I don't really care about those anyway as they're not getting anywhere with their root:mypassword login attempts.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 13 points 2 years ago

    Let us see, shall we?

    ssh root@cyberwolfie.com

❯ cowsay Uh-oh
 _______ 
< Uh-oh >
 ------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

    ;)

  • permalink
  • fedilink
  • source
    •
    [–] 6 points 2 years ago (1 child)

    Did you restart the server after you made the config change?

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
    • [–] 5 points 2 years ago* (last edited 2 years ago) (3 children)

    Yes that's the right way to block root login. An added filter you can use the 'match' config expression to filter logins even further.

    If you're on the open network, your connection will be heavily hit with login attempts. That is normal. But using another service like Fail2Ban will stop repeated hits to your host.

    Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections. Btw: I wasn't thinking clearly here. Out going connections won't be using port 22, but the listening incoming port is always 22.

  • permalink
  • fedilink
  • source
  • hideshow 6 child comments
    •
  • [–] 5 points 2 years ago* (1 child)

    Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections.

    There's no limit on the number of concurrent connections on a single port, and SSH runs completely on the one port it is configured to use. Otherwise allowing just the port 22 in firewall wouldn't be enough to have a functional SSH connection with default settings.

    You can verify that quite easily for example by spinning up three barebone Debian VMs connected to a single virtual network, configuring the firewall on the "server" VM to drop everything other than port 22 and then connecting from both client VMs - it will work just fine.

    Maybe you're confusing it with the fact that only one process can listen on a given port at a time? But that's only for establishing new connections. Existing connections can be passed off to another running process or a child process just fine, and that's how SSH handles separation between connections.

    Edit: oh, you're talking about the high port OP is wondering about. That's just the source port, which is chosen randomly by the client OS when making a connection. Using port 22 (or any other port below 1025) as a source port would require root privileges on the client and would also conflict with the SSH server that could be running there. Still, it has nothing to do with SSH "moving connections over"

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 2 points 2 years ago*

    Edit: oh, you’re talking about the high port OP is wondering about. That’s just the source port, which is chosen randomly by the client OS when making a connection. Using port 22 (or any other port below 1025) as a source port would require root privileges on the client and would also conflict with the SSH server that could be running there. Still, it has nothing to do with SSH “moving connections over”

    Ah, I see, so the port numbers shown in auth.log are all client side ports. I guess I thought that the listening port would be in the log and assumed that the port listed there would be it, but when I read the lines again, it clearly says "from ip.ad.dr.ess port 12345"

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 3 points 2 years ago (2 children)

    Yes that’s the right way to block root login. An added filter you can use the ‘match’ config expression to filter logins even further.

    Not sure what you meant about the 'match' config expressions here. Could you elaborate a bit further?

    If you’re on the open network, your connection will be heavily hit with login attempts. That is normal. But using another service like Fail2Ban will stop repeated hits to your host.

    Hehe, yeah, I've noticed... The reason I get a little anxious whether I did this correctly, is that 95% of the login attempts are to root, so I want to make sure it is disabled. I have set up Fail2Ban, but I am using default settings, which may be a bit laxer than they need?

    I've also been advised and considered moving to ssh keys, but I have not gotten to that yet.

    Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections.

    Makes sense. One question that comes from this is: is it possible to disable that? I would never need two ssh-logins at the same time on my server. And the second question is what I asked above regarding whether I should change the port ssh listens to in order to reduce unwanted malicious login attempts?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 6 points 2 years ago

    Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections.

    Makes sense

    No, it's nonsense. Nothing like that happens.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 2 years ago (1 child)

    Match blocks allow you to restrict who/what is allowed or not allowed to connect to the server. There is a large number of options to utilize. Put this near the bottom of sshd_config. There should be an example there.

    Here are some more examples: https://stackoverflow.com/questions/10829712/sshd-with-multiple-match-sections-override-settings

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • [–] 2 points 2 years ago (1 child)

    What @StarkZarn said is correct. Just one more thing: Did you reload/restart the sshd service after changing the configuration? If so you should be good.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •