I'm looking for advice on securing a public ssh box/account so that 'anyone' can connect to it for forwarding ports back to the client. This seems like a problem that should have at least one well accepted solution, and yet I can't find it. Let's make it.
I'm working on getting ssh access to the video machines when they have private IPs behind a firewall (pretty much always) using ssh port forwarding:
1. We have publicly accessible machines (call them Ss) that are subject to all the hacking. The accept connections on normal ports .. 22, 80, etc. We are not afraid of this.
2, Box A is a machine running voctomix at a conference. it has a user account (videoteam) and a key pair generated. it has dc people's public keys in videoteam's authorized_keys. dc people keep their private keys private, but the physical access to A isn't at all perfect, so I am willing to assert the videoteam private key can be taken.
3. Box P is a publicly accessible box that has videoteam's public key in authorized_keys, so it can accept an ssh connection from box A and forward P's 1234 port back to A's any port (like 22.) This should not put P at more risk than S. even if someone make A's private key public. yes?
OK, so allowing someone shell access to a box does increase the risk, we don't need a shell, lets not do that. /etc/passwd .. shell=/bin/false or /sbin/nologin takes care of that.
shell=/bin/false (which does allow the sidedoor connection) - when I connect, I see the MOTD banner, which makes me fidget.
nologin prints:
This account is currently not available.
which bothers me as it isn't really true. This account's shell isn't but if you keep the connection alive the port forwarding still works. (good, but more fidgeting.)
I am wondering what else can be done to P to make it less vulnerable, again assuming someone has the private key.
Should we white list connections?
turn off the motd banners? (I like them when I am connecting)
disable password connections for the one account? given I assume everyone has the private key, seems pointless.
ps - can someone double check the way I get P's key to put on A's known_hosts? I am not shown the fingerprint:
The authenticity of host '
wiki.debian.org (82.195.75.112)' can't be established.
ED25519 key fingerprint is SHA256:A08PkJsZEyAhDrdUwCXcthmJ2ywDqZIO+CNpM4UOPRU.
Which I am assuming should be part of the process, right?
--