1

I have a desktop computer in my home network with SSH server running on it. Using another computer in my private and local network (class C IP addresses: e.g., 192.168.0.2, etc) I sometimes use SSH to enter into the desktop PC with command ssh <user_name>@192.168.0.2 and work remotely.

I am wondering if someone from the internet (thus from outside my local network) may gather access to my desktop computer via SSH (i.e., by guessing the user_name and password). Is this SSH server/service accessible from the outside if the username and password are known? Or is impossible to gather access without knowing other details such as the IP of the network gateway and others.

My goal is to keep using SSH internally in my local network but at the same time block any possibility to gain access to any device in the network from the outside. So securely use SSH.

3 Answers 3

4

SSH is a professional-grade protocol, and most server and client SSH software have been intensively scrutinized for possible flaws, so if you use it in a conformant way it is secure.

Simply best practices recommend having more than one defensive line. If you want professional-grade security, you must behave as a professional admin:

  • if it is an option, prefer ssh keys to passwords, because they are deemed impossible to guess
  • add an additional defense line at the router level by ensuring that no input connection to a SSH port is allowed - for a private network, ensure that no incoming connection at all is allowed
  • add a last defense line at the server level by only allowing local addresses

It implies a bit of configuration but security only comes at that price.

3

Connections from the Internet to a private address aren't possible per se, but there are some more indirect attack vectors to consider:

  1. Vulnerabilities in the router or in its configuration. There could e.g. be a port forwarding from the external IP address to the private network address, enabling connectivity from the outside. A vulnerability in the firmware of the router or using weak or even default passwords on it may allow adding such configurations.

  2. Lateral movement from a compromised computer on the same LAN.

  3. Lateral movement from a compromised or backdoored IoT device on the same LAN.

1

To complement @Serge Ballista's excellent answer:

Regarding if it is an option, prefer ssh keys to passwords

ALWAYS USE pubkey-based authentication. Please see the comments below for situations where this is not an option though.

A couple of other useful settings in /etc/ssh/sshd_config:

# obviously disallow password-based auth
PasswordAuthentication no
# ... and enable public key auth
PubkeyAuthentication yes

# it's a good idea never let 'root' log in via SSH
# only non-privileged users.
# Let them `sudo` only once they're in.
PermitRootLogin no

# "ChallengeResponseAuthentication controls support for the
# 'keyboard-interactive' authentication scheme defined in RFC-4256."
# It may ask for passwords, so let's disallow it.
# See https://superuser.com/a/374234
ChallengeResponseAuthentication no

# if possible, limit the users who may log in
# but that's very much organisation-dependent
AllowUsers joe mary ann

Most of these settings should be reasonably self-explanatory. Regarding ChallengeResponseAuthentication, please read Izzy's answer on SuperUser for a more detailed explanation. To me the main argument from that answer is

The 'keyboard-interactive' authentication scheme could, in theory, ask a user any number of multi-facited questions. In practice it often asks only for the user's password.

Finally, consider installing Fail2Ban to detect and block possible intruders. It is quite easy to set up.

6
  • Keys are not always possible...
    – schroeder
    Nov 19, 2023 at 10:34
  • @schroeder: Thank you for your comments. Ad "keys are not always possible..." -- could you please give a good example? From my limited understanding, technically it should be possible. Maybe company policy reasons? Ad "comment my code": see my edits. I thought e.g. PasswordAuthentication no is pretty much self-explanatory :-) Nov 20, 2023 at 15:00
  • 1
    Policy, not all devices support all keys, intermediate hops... take your pick. and while your edit is a step in the right direction, you do not explain why you set each value to that state. and you complete ignore how Challenge Response works... or that it is used by PAM (the only way you could get a password btw)... or that you could set it up to require 2 authentication mechanisms...
    – LvB
    Nov 20, 2023 at 15:27
  • The first example that comes to mind is a shared computer and accounts. In OT environments, this can become a frustrating reality. Secondly, when client-side key management is a challenge for the end user. Thirdly, PAM.
    – schroeder
    Nov 20, 2023 at 15:27
  • @LvB Your comment is much appreciated, I added some extra explanations to further clarify the settings. However, when you say "you do not explain why you set each value to that state" -- well, the majority of these settings are really self-explanatory. At least I don't see any added value from explaining that PermitRootLogin no was set to no in order to disallow a user to log in as root :-) Nov 20, 2023 at 15:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .