I am starting to think the server should be manged too. I set up a remote node to connect to a server at home. it worked. good. to double check my notes about setting up the server, I wiped it and installed. which whiped the server's key, and so now the new server's key isn't in the remote node's lknow_hosts, so it won't connect. whoops.
Given the private key in the wild thing, it seems reasonable to tear down the server when the show is over, and build a new one with new keys for each show. On Mon, Dec 23, 2019 at 3:40 PM Carl Karsten <[email protected]> wrote: > 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: > https://salsa.debian.org/debconf-video-team/ansible/merge_requests/184 > > https://github.com/daradib/sidedoor#recommendations - seems lacking. > > 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? > > -- > Carl K > -- Carl K
