Terminal-Based SSH Portfolio

Comments

• oloke Member, Host Rep

  May 12

  @cemalgnlts said: But what are the security implications? Could a user potentially escape the script execution and gain shell access to the system?

  Hi

  I think you are on good track with your current sshd configuration, however there are couple more things that you could consider:

  Match User guest
      ForceCommand /home/guest/welcome.sh
      PermitEmptyPasswords yes
      PasswordAuthentication yes
      PermitTTY no
      Subsystem sftp /bin/false
      DisableForwarding yes
  

  First of all, you need to disable TTY. Running client with ssh -t would allow an attacker to get shell access if your script did not exit properly or attacker found some way to escape it. The risk could've been worse if the script was interactive, taking user input.

  I think you should also disable SFTP subsystem as it could be used to transfer files to your system and potentially overwrite the script. The welcome.sh should ideally also be writable only by root to prevent this (or other methods of overwriting it).

  I didn't include this here, but using the chroot directory (ChrootDirectory) should restrict the potential filesystem access even further. Here's a guide on how you could set this up.

  Disabling X11 and TCP forwarding is a good practice, however there are some more stuff SSH can forward. That includes TUN devices (-w), StreamLocal (Unix-domain) and ssh agent (-A). To disable any forwarding, you may use DisableForwarding yes

  Here's full explanation of all SSH options (man page):
  https://man.openbsd.org/sshd_config

  And finally, just to be extra sure, I would run something like this on a server that doesn't have any important data or services running. Discovering a critical vulnerability in SSH is highly unlikely, but seeing recent events, you never really know...

  Thanked by 6BasToTheMax xvps cemalgnlts plumberg Murv Frameworks
• xvps Member

  May 12

  @oloke said:

  @cemalgnlts said: But what are the security implications? Could a user potentially escape the script execution and gain shell access to the system?

  Hi

  I think you are on good track with your current sshd configuration, however there are couple more things that you could consider:

  Match User guest
      ForceCommand /home/guest/welcome.sh
      PermitEmptyPasswords yes
      PasswordAuthentication yes
      PermitTTY no
      Subsystem sftp /bin/false
      DisableForwarding yes
  

  First of all, you need to disable TTY. Running client with ssh -t would allow an attacker to get shell access if your script did not exit properly or attacker found some way to escape it. The risk could've been worse if the script was interactive, taking user input.

  I think you should also disable SFTP subsystem as it could be used to transfer files to your system and potentially overwrite the script. The welcome.sh should ideally also be writable only by root to prevent this (or other methods of overwriting it).

  Many, including hosting providers, use an outdated version of OpenSSH that has a scp command injection vulnerability.

  Most of them ignore it, because it can't be used for privilege escalation in itself, and requires a valid login.

  In this case, it is important to keep your ssh up-to-date.

  Googled this simple exploit, so @cemalgnlts can test it:
  https://github.com/cpandya2909/CVE-2020-15778

  Thanked by 2oloke cemalgnlts
• cemalgnlts Member

  May 12

  @oloke Awesome, this is exactly what I was looking for, thanks!
  @xvps I'll keep that in mind, thanks.

  Thanked by 1oloke
• stable_genius Member

  May 12 edited May 12

  @oloke said:
  And finally, just to be extra sure, I would run something like this on a server that doesn't have any important data or services running. Discovering a critical vulnerability in SSH is highly unlikely, but seeing recent events, you never really know...

  Using OpenBSD to host the ssh sessions would make it more secure. Running an OpenBSD VPS inside your Linux VPS is a possibility, you would probably not have kvm enabled in qemu but that may not be a problem in this very lightweight use case.

  Thanked by 1cemalgnlts