TransWikia.com

Security risks from exposing ssh to a home server

Information Security Asked by Nutle on December 8, 2020

I’m not sure if this is the right place to ask.

My goal is to establish an external connection to my home server through ssh and tunnel some ports to the laptop. For this reason, I’ve exposed the SSH port through my router (random 5-digit port instead of 22), and set the following config:

  • Private key connections only (password connections turned off)
  • Allowing only one specific user in (with sudo rights) from known IP addresses. (Ideally I would love to somehow allow access from my mobile phone’s hotspot, but it seems to change IP very often..)
  • Additionally, I’m thinking about creating a guest user with no sudo rights, which would be allowed from any IP. (This is in case I was trying to use the mobile hotspot). The guest would be enough for tunneling the ports, but would have no rights to files or anything otherwise.

Are these restrictions enough, or am I missing something important?

From what I’ve gathered, a better alternative would be to setup a VPN and connect to it instead, however, I’m not sure if it isn’t a large overhead for just one user. Additionally, as I’m not an expert in this field, I feel that it would be much easier to leave something ill-configured by mistake due to the larger complexity of openvpn setup. While with sshd it seems straightforward.

EDIT:
Additional idea regarding the 22 port: from what I understand, after changing the port to some random other, they can still be discovered by a thorough nmap scan – if that’s the case, is it possible to spoof them? E.g., spawn some "honeypot" ssh ports that lead nowhere (or to some empty docker container?), essentially hiding the correct port that leads to the machine? If anything, one can open thousands of empty ports, that would respond to nmap scans.

2 Answers

Changing your port number is not considered a security counter measurement, we call this security by obscurity.

If one would scan your IP address they will find out an SSH daemon is running on an alternative TCP port regardless.

Based on your edited question it appears you are concerned anyone finding the SSH daemon TCP listening port. If this is the case, I would recommend to implement port knocking.

Port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of predefined ports. It could be configured in a way where you have to execute a script that will connect to X amount of ports.

If the right sequence is received by the port knock daemon, it will open up your SSH port in the firewall for X amount of time. A regular port scan will not be able to detect the SSH daemon at this point.

Hardening your SSH daemon is always recommended as the 'default out of the box' configuration is still using weak key exchange algorithms and ciphers.

By using strong key exchange algorithms and ciphers, most automated attempts will (currently) fail because the client (attacker) can not negotiate on either one of the algorithms or ciphers.

You could consider using my hardened configuration located at: https://github.com/ITNerdbox/hardening-configurations/blob/master/sshd_config

It might require some tweaking on your part in order to meet your requirement(s).

Correct answer by Jeroen on December 8, 2020

Opening any port on your router is very risky, and you should make sure that your router has no known issues that allow exploitation of such an open port. This would be my concern no. 1 before even thinking about the SSH and its configuration.

Additional security risk is actually the implementation of the SSH that you are running on your server and server itself.

As for the VPN, this is much better solution and it is not too difficult, requires some reading, but is 100% worth considering the added security and its support for things like the two factor authentication.

Answered by Kamil Kurzynowski on December 8, 2020

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP