Discussion:
Securing local host of reverse SSH tunnel?
(too old to reply)
Nate Bargmann
2020-09-15 12:00:02 UTC
Permalink
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
Dan Ritter
2020-09-15 12:20:01 UTC
Permalink
Post by Nate Bargmann
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-
echo test
2020-09-15 12:40:01 UTC
Permalink
Post by Nate Bargmann
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 <user-name> \
-V 20191220:20201220 \
user_key.pub
<user-name> 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.
Fabrice BAUZAC-STEHLY
2020-09-15 19:00:02 UTC
Permalink
Post by Nate Bargmann
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
Alex Mestiashvili
2020-09-16 17:10:02 UTC
Permalink
Post by Fabrice BAUZAC-STEHLY
Post by Nate Bargmann
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.
Nate Bargmann
2020-09-16 23:30:01 UTC
Permalink
Post by Alex Mestiashvili
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
Alex Mestiashvili
2020-09-22 08:30:02 UTC
Permalink
Post by Nate Bargmann
Post by Alex Mestiashvili
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

Nate Bargmann
2020-09-17 18:40:01 UTC
Permalink
Post by Fabrice BAUZAC-STEHLY
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 ***@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
Loading...