4 ms·

> When we start SSH on port 22, we know for a fact that this is done by root. But what happens when we move SSH to port 2222? This port can be opened without a

> When we start SSH on port 22, we know for a fact that this is done by root. But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords. Well OP is assuming that I trust the root user of the machine I am SSH'ing to. If I do, then what's the concern? The root user probably told me what the SSH port is. If I don't, then well what's to say the SSH daemon on port 22 is secure? In any case, there are many other ports that are not 22 and are < 1024. You don't have to pick 2222. Changing the port is not the ultimate defense against attack, but in my experience it does reduce random drive-by type attacks. Same reason you raise your windows when you lock your car - as easy as it is to break a car window, a thief would rather steal from a car with an open window than smash your windows and steal from yours.

theboss 13y ago
If you don't trust the other side, you aren't administering the server, in which case this article isn't written for you. If you are, then the author is 100% correct that it is not a good idea to run a SSH server above port 1024, or any port other than 22. There are much better solutions to dealing with drive-by attempted logins, and some of them are built into ssh.
- vacri 13y ago
  There are plenty of unassigned ports below 1024 that you could happily use without theoretically stepping on toes, why not use one of them? Further down the page there are several people stating tangible benefits for moving off port 22.
  - theboss 13y ago
    I said above 1024 and picking on other than 22 is just Security Through Obscurity. I can banner grab you in less than a second and figure out which port is running an ssh server. If you really want to then go for it. But above 1024 is a no go.
- jaequery 13y ago
  What OP points out is good for starters but If you were really serious about security, you'd be locking your servers behind VPN and 2 factor auths. Cloudpassage.com does a pretty good job for locking down your servers for truly serious.
- nairteashop 13y ago
  > If you are, then the author is 100% correct that it is not a good idea to run a SSH server above port 1024, or any port other than 22. Ok, but you haven't explained why. The author's stated claim is that running an SSH server over 1024 means the connecting party cannot trust the server, but that of course doesn't apply if you are running the server. If you want to truly secure your server, then yeah, changing the port doesn't really do much but there are some minor benefits (see other responses in this thread, and on the internet). I'm still not seeing the harm.
  - theboss 13y ago
    If you are running the server and your server is compromised than the attacker can remove the ssh server you are running and put up his own malicious program to collect your password if and only if they port is above 1024, and they don't need root privileges, they can have www-data privileges or whatever
    - Volundr 13y ago
      Again if he can remove ssh running as root on port 1xxxx, he can run his ssh-alike on port 22.
      - theboss 13y ago
        but he can do 1xxx from an unprivileged NOT ROOT and he requires root to do that with port 22, again
        Volundr 13y ago
        So basically, he's gained root once to kill ssh running as root, but you think that gaining root again in order to run something on port 22 is what's going to stop him?
  - Volundr 13y ago
    Put another way, if someone has gained access to run a script as a non-root user on my server, and somehow managed to kill SSH which is running as root to bind to that port, gained access to my host key (which should only be readable by root), so that my ssh client won't warn me when I connect, and is now running an ssh-alike on that port, I'm pretty well owned already. It's hard to see how someone with this much access doesn't have enough to go ahead an run their ssh-alike on port 22. That said, I run ssh on a non-standard port for one reason only, it's a crap-load easier to check the log files for suspicious activity that way. I still run use the same protections I do for servers with ssh on 22.
AnthonyMouse 13y ago
>Well OP is assuming that I trust the root user of the machine I am SSH'ing to. If I do, then what's the concern? Trusting the root user is different from trusting everyone with shell access to that machine. Only root (or a process with the appropriate capability) can bind to port 22 because it's below port 1024. Normal users can bind to port 2222. So now $EVIL_USER puts "@reboot /home/$EVIL_USER/bind_port_2222" in his crontab, or some such other method of getting to port 2222 before the ssh daemon. This is mostly mitigated by the fact that $EVIL_USER can't read the host private keys which means that the impersonation will be detected by anyone who has the host in the known_hosts file, but that only counts for ssh, and assumes you've connected to the host previously. If you're running something like DNS or FTP on a multi-user machine, using a non-privileged port is a Bad Idea.
- nairteashop 13y ago
  > So now $EVIL_USER puts "@reboot /home/$EVIL_USER/bind_port_2222" in his crontab, or some such other method of getting to port 2222 before the ssh daemon. I hadn't thought of this. Setting up the malicious executable to somehow bind to the SSH port before the SSH daemon is able to and then rebooting the computer - assuming the user has reboot privileges - seems to be the only way to do this correct? (Once the SSH daemon has bound to its assigned port, then I don't think the port matters - if the user is able to kill a root-owned SSH daemon, he's likely able to start his service on whatever port he wants).
  - AnthonyMouse 13y ago
    > Setting up the malicious executable to somehow bind to the SSH port before the SSH daemon is able to and then rebooting the computer - assuming the user has reboot privileges - seems to be the only way to do this correct? Not necessarily. You wouldn't necessarily need reboot privileges, you could just wait until root reboots the machine for whatever unrelated reason (e.g. kernel update). And you could do the same thing with the daemon: Wait until some updated version of the daemon is released and when root is installing it there will be a race starting when the old version exits before the new version starts and binds the port. You're also just causing trouble for yourself because then you have to worry about a bunch of arcana like whether the daemon is using SO_REUSEADDR, IPV6_V6ONLY, only binding to the IPv4 address when the machine is dual stack, etc.

theboss 13y ago

If you don't trust the other side, you aren't administering the server, in which case this article isn't written for you. If you are, then the author is 100% correct that it is not a good idea to run a SSH server above port 1024, or any port other than 22. There are much better solutions to dealing with drive-by attempted logins, and some of them are built into ssh.

vacri 13y ago
There are plenty of unassigned ports below 1024 that you could happily use without theoretically stepping on toes, why not use one of them? Further down the page there are several people stating tangible benefits for moving off port 22.
- theboss 13y ago
  I said above 1024 and picking on other than 22 is just Security Through Obscurity. I can banner grab you in less than a second and figure out which port is running an ssh server. If you really want to then go for it. But above 1024 is a no go.
jaequery 13y ago
What OP points out is good for starters but If you were really serious about security, you'd be locking your servers behind VPN and 2 factor auths. Cloudpassage.com does a pretty good job for locking down your servers for truly serious.
nairteashop 13y ago
> If you are, then the author is 100% correct that it is not a good idea to run a SSH server above port 1024, or any port other than 22. Ok, but you haven't explained why. The author's stated claim is that running an SSH server over 1024 means the connecting party cannot trust the server, but that of course doesn't apply if you are running the server. If you want to truly secure your server, then yeah, changing the port doesn't really do much but there are some minor benefits (see other responses in this thread, and on the internet). I'm still not seeing the harm.
- theboss 13y ago
  If you are running the server and your server is compromised than the attacker can remove the ssh server you are running and put up his own malicious program to collect your password if and only if they port is above 1024, and they don't need root privileges, they can have www-data privileges or whatever
  - Volundr 13y ago
    Again if he can remove ssh running as root on port 1xxxx, he can run his ssh-alike on port 22.
    - theboss 13y ago
      but he can do 1xxx from an unprivileged NOT ROOT and he requires root to do that with port 22, again
      - Volundr 13y ago
        So basically, he's gained root once to kill ssh running as root, but you think that gaining root again in order to run something on port 22 is what's going to stop him?
- Volundr 13y ago
  Put another way, if someone has gained access to run a script as a non-root user on my server, and somehow managed to kill SSH which is running as root to bind to that port, gained access to my host key (which should only be readable by root), so that my ssh client won't warn me when I connect, and is now running an ssh-alike on that port, I'm pretty well owned already. It's hard to see how someone with this much access doesn't have enough to go ahead an run their ssh-alike on port 22. That said, I run ssh on a non-standard port for one reason only, it's a crap-load easier to check the log files for suspicious activity that way. I still run use the same protections I do for servers with ssh on 22.

AnthonyMouse 13y ago

>Well OP is assuming that I trust the root user of the machine I am SSH'ing to. If I do, then what's the concern? Trusting the root user is different from trusting everyone with shell access to that machine. Only root (or a process with the appropriate capability) can bind to port 22 because it's below port 1024. Normal users can bind to port 2222. So now $EVIL_USER puts "@reboot /home/$EVIL_USER/bind_port_2222" in his crontab, or some such other method of getting to port 2222 before the ssh daemon. This is mostly mitigated by the fact that $EVIL_USER can't read the host private keys which means that the impersonation will be detected by anyone who has the host in the known_hosts file, but that only counts for ssh, and assumes you've connected to the host previously. If you're running something like DNS or FTP on a multi-user machine, using a non-privileged port is a Bad Idea.

nairteashop 13y ago
> So now $EVIL_USER puts "@reboot /home/$EVIL_USER/bind_port_2222" in his crontab, or some such other method of getting to port 2222 before the ssh daemon. I hadn't thought of this. Setting up the malicious executable to somehow bind to the SSH port before the SSH daemon is able to and then rebooting the computer - assuming the user has reboot privileges - seems to be the only way to do this correct? (Once the SSH daemon has bound to its assigned port, then I don't think the port matters - if the user is able to kill a root-owned SSH daemon, he's likely able to start his service on whatever port he wants).
- AnthonyMouse 13y ago
  > Setting up the malicious executable to somehow bind to the SSH port before the SSH daemon is able to and then rebooting the computer - assuming the user has reboot privileges - seems to be the only way to do this correct? Not necessarily. You wouldn't necessarily need reboot privileges, you could just wait until root reboots the machine for whatever unrelated reason (e.g. kernel update). And you could do the same thing with the daemon: Wait until some updated version of the daemon is released and when root is installing it there will be a race starting when the old version exits before the new version starts and binds the port. You're also just causing trouble for yourself because then you have to worry about a bunch of arcana like whether the daemon is using SO_REUSEADDR, IPV6_V6ONLY, only binding to the IPv4 address when the machine is dual stack, etc.