securing a hop

[Carl Karsten]

On Sun, Dec 29, 2019 at 1:32 PM Stuart Henderson <stu at spacehopper.org>
wrote:

> On 2019/12/28 22:06, Carl Karsten wrote:
> > for the A nat B C connect back to A using -R 2222:localhost:22 pattern,
> > (see diagram at https://github.com/daradib/sidedoor)
> > I want to limit B's user to just what is needed to do the port forward.
> >
> > I am hoping this is documented, but I can't find much more than "you
> should
> > future out how to secre it."
> >
> > I setup an ansible playbook to instal and configure sidedoor on A. I have
> > written some docs on securing B which is mostly:
> >
> > 1. append to /etc/ssh/sshd_config (user is from sidedoor.yml)
> > Match User {user}
> >     MaxSessions 60
> >     PasswordAuthentication no
> >     ChrootDirectory %h
> >     X11Forwarding no
> >     AllowTcpForwarding yes
>
> AllowTcpForwarding also accepts local/remote to add restrictions, and/or
> you can set PermitOpen to restrict which address/ports can be forwarded.
>

oh this brings up something I want to address: which I'm not sure the terms
to use to describe, so bear with me.

I want the A-B connection to only allow a port on B to be forwarded back to
A.
The server should enforce this as I can't control what happens with A or
the key pair used.

If that isnt clear:

A,B,C are hostnames, user and admin are usernames.

user's private key is on A and public key is on B - that's how the A to B
connection is made:
user at A:$ ssh -R 2222:localhost:22 user at B
admin connects form C to B to A using admin's keys.

I'm assuming user's keys will be taken. (don't have physical security on A,
trying to do that is too hard)

what I don't want is: user keys are taken home to box D, D connects to B
and used B as a open proxy.



>
> >     PermitTunnel no
> >     PermitTTY no
> >     Banner none
> >     ForceCommand /bin/false
>
> Others seem sane.
>
> > https://salsa.debian.org/debconf-video-team/ansible/merge_requests/184
> >
> > Those options are from me reading the docs and collecting tips i found on
> > internet.  A friend pointed out "be aware sftp is likely enabled."
>
> ForceCommand prevents running the sftp server process.
>
>
Specifying a command to prevent all commands seems sloppy.
It seems like it needlessly exposes an attack surface.
Shouldn't there be a "don't allow commands" option?


> > Once I have something solid, hopefully someone can find a place for it to
> > live and projects like mine and sidedoor can reference it.
>
>

-- 
Carl K