Bug 210 - can't prevent port forwarding on a per-user basis
Summary: can't prevent port forwarding on a per-user basis
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: -current
Hardware: All All
: P2 enhancement
Assignee: OpenSSH Bugzilla mailing list
URL: http://reactor-core.org/security/HOWT...
Keywords:
Depends on:
Blocks: V_4_4
  Show dependency treegraph
 
Reported: 2002-04-08 22:05 AEST by Jonathan Walther
Modified: 2006-09-28 19:25 AEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Walther 2002-04-08 22:05:22 AEST
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!
Comment 1 Markus Friedl 2002-04-08 22:17:06 AEST
check this

http://www.mindrot.org/~djm/ssh-keynote/
Comment 2 Jonathan Walther 2002-04-09 00:25:25 AEST
Excellent.

Will the KeyNote patch be folded into -current at some point?

Does /etc/sshd_policy override the directives in /etc/sshd_config?
Comment 3 Damien Miller 2003-01-07 17:52:56 AEDT
I should rewrite the keynote stuff with privsep in mind (i.e do checking in child)
Comment 4 Damien Miller 2006-07-12 22:56:34 AEST
bug #1180 has implemented this, it will be in openssh-4.4
Comment 5 Darren Tucker 2006-09-28 19:25:15 AEST
With the release of 4.4, we believe that this bug is now closed.  For information about the release please see http://www.openssh.com/txt/release-4.4 .