[Bug 210] New: can't prevent port forwarding on a per-user basis

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Mon Apr 8 22:05:26 EST 2002


http://bugzilla.mindrot.org/show_bug.cgi?id=210

           Summary: can't prevent port forwarding on a per-user basis
           Product: Portable OpenSSH
           Version: -current
          Platform: All
               URL: http://reactor-core.org/security/HOWTO-Anonymous-CVS-
                    Over-SSH
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: krooger at debian.org


I've written up a little HOWTO on how I set up my CVS server to allow
anonymous access via ssh.  I did it essentially the same as the
method documented by Theo and crew.  Where their login shell has a lot   
of stuff in it, mine is a simple execle() statement.  Url is here:
   http://reactor-core.org/#code

After following the steps outlined in the HOWTO, and in the README that comes
with anoncvssh.shar, I came across the following problem.  How can I disable
things like port forwarding, X forwarding, agent forwarding, and so on to people
who are connecting to this passwordless account?  The anoncvssh.shar README does
not address this, so I'm wondering how the OpenBSD anonymous CVS services
protect themselves from abuse of forwarding.

The .ssh/authorized_keys file seems to provide the perfect solution,
except that users are not logging in with public keys; they are being
logged in without any key or password.  And this is as it needs to be.

I thought of one solution, but am not sure if it is correct:  What if
"*" was understood to mean "any key not otherwise specified in this
file" in the authorized_keys file?  Then I could turn all the options on
and off to my hearts content.  My only hesitation is that since the user
is logging in via password mechanism, no public key is involved, so
authorized_keys probably wouldn't even come into the picture.

I'm not married to the above idea; but I would like some mechanism to
enable and disable sshd features on a per user basis, so that I can use
ssh to provide encryption for otherwise cleartext public services,
without compromising my box, or locking down users that I do trust.

Also, in authorized_keys I can limit the -L port forwarding; how about a
keyword for controlling -R port forwarding as well?  I don't want Joe
Random CVS user opening up a port to listen on my box.

Cheers!



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the openssh-unix-dev mailing list