On 9/15/20 8:53 PM, Fabrice BAUZAC-STEHLY wrote: > Nate Bargmann writes: > >> I am going to be deploying a Debian system at a location where I am >> unsure if I can make any inbound connection into that system. I am >> going to set up an SSH tunnel from that system to a host in my LAN. >> What I am concerned about is the remote possibility of theft and >> therefore exposing my LAN to an inbound connection where a shell prompt >> can be obtained. I will be setting up a private/public key pair. My >> plan is to SSH into the internal host and then initiate an SSH >> connection to the defined port and ultimately log into the remote >> system. >> >> The site is physically secure, but ... While I understand that at the >> remote end I can instruct the SSH client not to request a pseudo tty, if >> a thief has the private key, all he needs to do is initiate a connection >> and get a shell prompt on my internal host (due to being run from a >> startup script, the private key cannot be password protected, or can >> it?). >> >> What I would like to do is in some way configure the ssh daemon on my >> internal host to not allow any access other than allocating the port for >> the reverse connection. Ideally, this restriction should be based on >> the public key of the pair but I've not seen in sshd_config(5) a way for >> the Match directive to use the public key as its trigger. > > To restrict what an SSH account can do, you can use the command="..." > setting in the autorized_keys file. It is documented in sshd(8). I use > it specifically to restrain the possible actions that can be done with > that private key. As the command, you can use any program or script > that can check the arguments and perform the requested action, without > allowing any unforeseen action. > > -- > Fabrice BAUZAC-STEHLY > PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D >
btw, there is package authprogs, doing exactly that and not only.