I want to access a web application running on a web server behind my office firewall from an external machine.

We have a bastion host running sshd that is accessible from the Internet.

I want to know if this solution is a bad idea:

  • Create an account on the bastion host with shell=/bin/false and no password ('testuser')
  • Create a ssh RSA key on the external machine
  • Add the public RSA key to the testuser's authorized_keys file
  • ssh to the bastion host from the external host using: ssh -N 8888:targethost:80
  • run my tests from the external host
  • shut down the ssh tunnel

I understand that if my RSA private key were compromised then someone could ssh to the bastion host. But are there other reasons this solution is a bad idea?

thank you!

  • Personally I think /sbin/nologin is more appropriate than /bin/false – einstiien Apr 6 '10 at 16:22
  • Not all distributions have nologin. Slackware 10, for example. They're both appropriate solutions. – Warner Apr 6 '10 at 16:54
  • Sorry, I checked a few distros I'm using before commenting to make sure I wasn't mistaken. Never actually used Slackware. – einstiien Apr 6 '10 at 17:38

I think this is a pretty secure setup, I use it myself. You will need to add '-L' to your command:

ssh -N -L 8888:targethost:80

As long as you don't use the '-g' option, only your client machine can access the port forward.

What I would recommend also is to make sshd on the bastion host listen on a non-standard port. If you are listening on a standard port, the attack traffic sometimes can eat up considerable amounts of CPU.

Also choose a good passphrase for your ssh key, and enter it only on trusted machines. Preferably Linux, it is less trivial to install keyloggers on Linux.

  • I would go one step further and say do ssh -N -L (specifying that the local listener should bind to localhost rather than glomming all your IPs). This prevents someone on your local network from stumbling on port 8888 on your workstation and doing Bad Things. – voretaq7 Apr 6 '10 at 15:56
  • Don't change the port, filter the traffic. – Warner Apr 6 '10 at 16:04
  • @voretaq7 Unless you explicitly specify the '-g' option, specifying is redundant. You can try the command and then 'netstat -tnlp' if you're not convinced :) – Prof. Moriarty Apr 6 '10 at 16:58
  • @Prof. Moriarty - True, but I'm paranoid (and you never know when some brain-dead person will put "GatewayPorts yes" in ssh_config: more obvious stupidity has made it into released systems :) – voretaq7 Apr 6 '10 at 18:26
  • @voretaq7 OK, you're right :) If you want good security, you need to be paranoid! – Prof. Moriarty Apr 6 '10 at 18:58

I don't think it's necessarily a bad idea. Put SSH on a port other than 22 and you'll make it a little more obscure for script kiddies to find, and if you're testing from a laptop computer externally I'd encrypt things on the drive so if it's stolen/lost/etc. you don't need to worry about the data being compromised. Otherwise the tunnels should help keep things being being intercepted between the bastion host and the laptop on the public webbertubes.

  • @warner: all things being equal, running ssh on a different port does not create a security risk. Assuming you still take the other appropriate security measures you would take anyways I don't see how it is a problem. – einstiien Apr 6 '10 at 16:25
  • It does not create additional risk but it is still a haphazard solution. A kluge at best. If you want to minimize the footprint, use packet filtering. – Warner Apr 6 '10 at 16:37
  • @einstiien: You're right, as long as you select a port < 1024. Also consider using port knocking instead. – Chris Lercher Apr 6 '10 at 16:39
  • I never implemented port knocking, but it does add an additional layer of security which might be worth it. – Prof. Moriarty Apr 6 '10 at 16:54

Stunnel could be a good alternative. You wouldn't need an account on the machine, and you can still authenticate the client with a certificate.

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.