8

In a Reddit thread on securing SSH access to a Raspberry Pi, one commenter recommended running SSH on a non-standard port of 8123.

Another commenter had this to say on the matter:

Don't change your SSH listening port to anything >1024. An unprivileged rogue process can wait for the SSH daemon to terminate and establish a listening socket on that port. Ports <1024 are reserved to processes running as root.

I personally do not feel this is a significant risk with SSH as:

  1. The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.
  2. If key based authentication is in use, little can be gained from intercepting communications.

However, not all protocols have this functionality. For example, web proxies running on port 8080 or 3128 generally have no authentication.

How significant is the risk of running on a port number > 1024?

  • If you're trying to prevent brute force attacks I would recommend something like sshguard or fail2ban instead of changing your port. As changing ssh away from port 22 could make it much harder to access from external networks who sometimes limit higher ## ports. – John Jan 28 '16 at 23:41
  • One possible risk is that if someone with non-root access to your server knows a way to bring down (crash) your ssh daemon it can replace it with their evil ssh version (which could be designed to steal your credentials). In that case, I would recommend to use "monit" or alike, which will monitor / restart your sshd daemon and report you in case its pid change. John recommendations are also good, however I recommend to change your default port if you have few experienced clients. – lepe Jan 29 '16 at 1:13
1

If there's a rogue process running on your Raspberry Pi then you have already been compromised, although the attacker or automated malicious process obviously hasn't managed to elevate to root yet.

The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.

That is true. However this depends on whether your users are likely to notice this or not. On an average system, many users will click through warnings, however with a Linux based system using SSH this bar is usually raised high enough that only semi-expert users will be connecting, increasing the possibility that they will realise something is wrong.

If key based authentication is in use, little can be gained from intercepting communications.

Agreed. Even though the public key could be retrieved from the SSH client, there would be no way of the rogue service intercepting the private key as this is never sent.

There may be a risk if password authentication was used instead, although as noted the user would have to had ignored any host key warning messages.

Therefore, in summary there is no extra risk introduced using a non-privileged port for SSH when public key authentication is in place. The only attack I could think of is where the rogue SSH daemon will let a user connect in the hope that the user immediately issues a sudo/su and then enters a password which is then captured. If this was not done immediately then because the rogue process will not have the same permissions as those of the real user, the user will likely notice that something is amiss.

3

Services running on ports < 1024 (at least on *nix servers) are generally considered to be more secure, because they require root (or a trusted user that has root privileges) to start them - whereas services running on ports >= 1024 could be run by an untrusted (possibly rogue) user on the server.

So, it is plausible that an attack like the one described in the reddit post that you copied could be pulled off by a malicious user on the server, without root privileges.

With regard to "1.The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.": This is true - if a user had logged into the server previously, and his SSH client pinned the server's public key. In this case, the user's SSH client would (presumably) warn him that the server's public key has changed, and the user would (presumably) know that something's up. But, the user would only be warned if he had logged into the server previously and his client pinned the server's public key.

With regard to "2.If key based authentication is in use, little can be gained from intercepting communications.": I'm skeptical about this. The user's SSH client would send its public key, as usual during the start of an SSH session, then the rogue SSH server could simply authenticate the client (as is normally the case when the client's public key is present in the server's authorized_keys file) and proceed with the session using the public key that the client sent.

  • +1 for raising concern about hijacking first-time SSH users. – Neil Smithline Jan 29 '16 at 3:27
  • With respect to 2, yes, the server could do that, but only if the client ignored the server fingerprint. It's the same risk that you have connecting to any server you don't trust and are seeing a new fingerprint. – Cybergibbons Jan 29 '16 at 12:12
  • Agreed. But, if the client is connecting to the server for the first time, or the client did not pin the server's public key from a previous connection, then how would the client know that anything has changed? To summarize, I think there is some level of increased risk in running an SSH server on port 1024 or higher, if there are untrusted users on the server (or there is risk of an attacker gaining access as an untrusted user). – mti2935 Jan 29 '16 at 12:23
0

Some SE threads are discussing the pros & cons of this from a security perspective. Does changing default port number actually increase security? and Should I change the SSH port to < 1024?.

However, there is also a risk involved, that the rogue process you mentioned actually locks you out of your server. The chances that this happens may be low, but what if? You will be lucky if you can reboot the server without SSH access. And hopefully at startup the SSH daemon is claiming the port before the rogue process.

  • 1
    What would be the scenario where this happened? Aren't you locked out once the real SSH daemon? There'd be no need to run a new server to block the port. – Neil Smithline Jan 29 '16 at 3:29
  • @NeilSmithline if I know you have ssh on port 1111 and have an unprivileged account on the server, I can just run a program that tries to attach itself to port 1111 several times per second until it succeeds. If you then restart your SSH server for any reason, my program will take port 1111 and the SSH server won't start. Usually, you would restart the server manually and still have a session open. You could then find the rouge program, kill it and restart ssh. But if you restart sshd automatically, you are locked out. – Josef Jan 29 '16 at 10:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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