Re: Securing local host of reverse SSH tunnel?
On 9/17/20 1:27 AM, Nate Bargmann wrote: * On 2020 16 Sep 12:08 -0500, Alex Mestiashvili wrote: btw, there is package authprogs, doing exactly that and not only. It seems to only be in Bullseye right now. It's not in Buster nor Buster backports. As the target computer is a Freedombox, it is running Buster so I will have to see if I can build it locally. - Nate it should be as easy as pip --user install authprgos, but it is also available in buster-backports from today. Best, Alex
Re: Securing local host of reverse SSH tunnel?
* On 2020 15 Sep 13:54 -0500, Fabrice BAUZAC-STEHLY wrote: > 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. This proved to be easiest so far. Once I had the tunnel set up I prefixed the key with 'command="/usr/sbin/nologin"' which gives a failure message when a typical 'ssh user@server' command is issued from the remote computer. Thanks! - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Securing local host of reverse SSH tunnel?
* On 2020 16 Sep 12:08 -0500, Alex Mestiashvili wrote: > btw, there is package authprogs, doing exactly that and not only. It seems to only be in Bullseye right now. It's not in Buster nor Buster backports. As the target computer is a Freedombox, it is running Buster so I will have to see if I can build it locally. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Securing local host of reverse SSH tunnel?
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.
Re: Securing local host of reverse SSH tunnel?
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
Re: Securing local host of reverse SSH tunnel?
>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 Not an expert but did you look at the certificate based authentication? You can define your own certificate authority and allow only the certificates signed (it's a public key) by your ca can to connect to your ssh server. 1 - Generate a key pair for the ca ( and another for he remote user) $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/ca -m PEM 2- Sign the public key of the user ssh-keygen -s ca \ -I \ -V 20191220:20201220 \ user_key.pub will be logged on your server everytime a connection is opened with user_key.pub. -v stands for key validity. 3 - Allow on your LAN (ssh server) TrustedUserCAKeys /secure/permission/ca.pub This means, any certificate signed with this ca will be granted access to your server. Of course you can restrict what the users whose login is allowed (particularly prevent root login ). Note: using the certificate based authentication, you can even choose what kind of features are allowed to be used with a particular certificate. a k.a AllowX11Forward and many more. Maybe a good reading of ssh doc may provide you an better approach for your use case. ssh(1) Hope this will help.
Re: Securing local host of reverse SSH tunnel?
Nate Bargmann wrote: > 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. Use Wireguard. It's available in newer kernels and in backports. wg sets up an encrypted, routed network between your remote system and your local system (or network). Then you can ssh directly into your remote system without giving it any new privileges back to your local system. -dsr-
Securing local host of reverse SSH tunnel?
Hi All. 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. If there is another way, I've yet to find it. TIA - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
