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. Services running on ports = 1024 could be run by an untrusted (possibly rogue) user on the server. ![]() 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. 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. Therefore, in summary there is no extra risk introduced using a non-privileged port for SSH when public key authentication is in place. 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. 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. If key based authentication is in use, little can be gained fromĪgreed. 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. However this depends on whether your users are likely to notice this or not. ![]() The rogue process cannot access the host keys, so would present aĭifferent fingerprint to the user when connecting, alerting them to an 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.
0 Comments
Leave a Reply. |