restricting TCP forwarding - SSH

This is a discussion on restricting TCP forwarding - SSH ; Any user with an existing file as a shell entry in /etc/passwd can use ssh forwarding. This rather defeats the purpose of scponly. Is it possible to restrict this on a per-group or per-user basis? Or is running a second ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: restricting TCP forwarding

  1. restricting TCP forwarding

    Any user with an existing file as a shell entry in /etc/passwd can use
    ssh forwarding. This rather defeats the purpose of scponly.

    Is it possible to restrict this on a per-group or per-user basis? Or is
    running a second ssh server the only solution?

    Steven

  2. Re: restricting TCP forwarding

    >>>>> "SM" == Steven Mocking writes:

    SM> Any user with an existing file as a shell entry in /etc/passwd can
    SM> use ssh forwarding. This rather defeats the purpose of scponly.

    SM> Is it possible to restrict this on a per-group or per-user basis?
    SM> Or is running a second ssh server the only solution?

    Not with OpenSSH, though other SSH servers such as Tectia and vshd do have
    this capability.

    --
    Richard Silverman
    res@qoxp.net


  3. Re: restricting TCP forwarding

    Richard E. Silverman wrote:
    >>>>>> "SM" == Steven Mocking writes:

    >
    > SM> Any user with an existing file as a shell entry in /etc/passwd can
    > SM> use ssh forwarding. This rather defeats the purpose of scponly.
    >
    > SM> Is it possible to restrict this on a per-group or per-user basis?
    > SM> Or is running a second ssh server the only solution?
    >
    > Not with OpenSSH, though other SSH servers such as Tectia and vshd do have
    > this capability.


    With openssh if you set ownership and permissions on .ssh &
    ..ssh/authorized_keys such that the user can't modify it (e.g. owned by
    root) you can use the no-port-forwarding option on the key.
    --
    Flash Gordon, living in interesting times.
    Web site - http://home.flash-gordon.me.uk/
    comp.lang.c posting guidelines and intro:
    http://clc-wiki.net/wiki/Intro_to_clc

  4. Re: restricting TCP forwarding

    Flash Gordon wrote:
    > With openssh if you set ownership and permissions on .ssh &
    > .ssh/authorized_keys such that the user can't modify it (e.g. owned by
    > root) you can use the no-port-forwarding option on the key.


    Thanks for the info - that works fine for public/private key
    authentication, but there are some id-10-t issues on the user side of
    the equation, so that is not an option. Key authentication wouldn't work
    for most SFTP clients anyway.

    I did some further digging and apparently there's a patch to add a Match
    keyword to sshd so you can do this on a per-user or per-host basis.
    Courtesy of Benjamin Donnachie from the scponly mailing list.

    Here's the thread:
    http://bugzilla.mindrot.org/show_bug.cgi?id=1180

    Steven.

  5. Re: restricting TCP forwarding

    Steven Mocking wrote on 10/05/2006 20:13:
    > Flash Gordon wrote:
    >> With openssh if you set ownership and permissions on .ssh &
    >> .ssh/authorized_keys such that the user can't modify it (e.g. owned
    >> by root) you can use the no-port-forwarding option on the key.

    >
    > Thanks for the info - that works fine for public/private key
    > authentication, but there are some id-10-t issues on the user side of
    > the equation, so that is not an option. Key authentication wouldn't
    > work for most SFTP clients anyway.
    >
    > I did some further digging and apparently there's a patch to add a
    > Match keyword to sshd so you can do this on a per-user or per-host
    > basis. Courtesy of Benjamin Donnachie from the scponly mailing list.
    >
    > Here's the thread: http://bugzilla.mindrot.org/show_bug.cgi?id=1180
    >


    please check the man page to see why this doesn't really exist

    http://www.openbsd.org/cgi-bin/man.c...86&format=html

    AllowTcpForwarding
    Specifies whether TCP forwarding is permitted. The default is
    ``yes''. Note that disabling TCP forwarding does not
    improve se-
    curity unless users are also denied shell access, as they
    can al-
    ways install their own forwarders.

  6. Re: restricting TCP forwarding

    Old thread, I know...

    In article , Flash Gordon writes:
    >With openssh if you set ownership and permissions on .ssh &
    >.ssh/authorized_keys such that the user can't modify it (e.g. owned by
    >root) you can use the no-port-forwarding option on the key.


    Be warned - even if I don't own the .ssh directory, I own it's name in
    my home directory and can easily rename it and then create a new one
    with my desired settings.

    Bye, Andy

    --
    Andreas Ley, Rechenzentrum, Universitaet Karlsruhe, D-76128 Karlsruhe, Germany
    Andreas.Ley@rz.uni-karlsruhe.de, Phone: +49 721 608 6341, Fax: +49 721 32550
    "Solche Mails [...] liest kein Mensch, da er danach erstmal eine Zigarettenpause
    braucht (fuer mich als Nichtraucher ein grosses Problem)." -- Jochen Kaiser

  7. Re: restricting TCP forwarding

    On 2006-06-01, Andreas Ley wrote:
    > Be warned - even if I don't own the .ssh directory, I own it's name in
    > my home directory and can easily rename it and then create a new one
    > with my desired settings.


    You can put authorized_keys someplace other than the users' home dirs
    with the AuthorizedKeysFile sshd_config.

    To the OP: right now you can't restrict port forwarding per-user for the
    general case with OpenSSH right now. There is work going on to add it
    and other similar capabilities:
    http://bugzilla.mindrot.org/show_bug.cgi?id=match
    (there's a patch against 4.3p2 in there)

    With this, you would configure sshd_config with something like:

    AllowTcpForwarding yes
    Match Group scponly
    AllowTcpForwarding no

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

+ Reply to Thread