Mailing List Archive

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.

> 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.

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Dec 29, 2019 at 1:32 PM Stuart Henderson <stu@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@A:$ ssh -R 2222:localhost:22 user@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev