limiting port forwarding? (do better than just 'on' or 'off'?)
sen_ml at eccosys.com
sen_ml at eccosys.com
Fri Mar 3 19:26:56 EST 2000
thanks for responding. i don't know how i missed your response :-(
my apologies.
my comments follow below.
> i would like to be able to have users access a specific set of
> ports (and no others) on a machine running an ssh daemon via ssh's
> port-forwarding.
>
> i was thinking of doing this by not providing shell access (so
> using an appropriate command="command" option in each user's
> authorized_keys file), but i did not find an appropriate keyword
> for the sshd configuration file to control which ports should be
> permitted to be forwarded. i know about the AllowTcpForwarding
> keyword, but it does not appear to allow the granularity of control
> i would like, to put it mildly ;-)
djm> I was thinking of doing something along these lines. The mechanism
djm> I had in mind was a /etc/ssh/portforward file (suggestions for a
djm> better name welcomed) containing the following fields:
djm> username group remote_addr remote_port
djm> username could be a name, uid or an asterisk meaning "any"
djm> group could be a name, gid or an asterisk meaning "any"
djm> remote_addr could be a hostname, ip address or network in CIDR format
djm> remote_port could be a service name, port, port range (numbers with a
djm> hyphen between them) or an asterisk.
djm> That which is not implicitly allowed would be denied. We could ship a
djm> default file of "* * * *" for backwards compatibility.
djm> Thoughts?
one thing that comes to mind is that i would like to be able to have
the limiting apply per authorized key. clearly, when using the tcp
forwarding limiting, shell access should be denied for the limiting to
be of any use.
one scenario i have in mind is to provide a dummy account which is
used by all users of the ssh service. users are told apart by which
rsa key is used for authentication -- each entry in the authorized_keys
file is treated as a "user".
imho, ideally, there would be a virtual user mechanism that could be
shared by all services (e.g. ssh, pop, etc.) on a machine -- afaik,
once you create a user under the current unix user mechanism, this
allows code to run under the corresponding user id. i'd prefer not to
have to think about that scenario.
w/ such a user mechanism, i would be happy w/ the method you outlined
concerning how to configure the limiting of port-forwarding. afaik,
no such user mechanism exists (even if it does, it certainly doesn't
seem widespread), so i guess that point is moot.
since shell access for users should be denied if port forwarding is to
be limited, if you are going to be doing a per-user configuration of
port forwarding, it seems reasonable to place the limiting settings
inside ~/.ssh in some file. if authorized_keys is used, the settings
could go in there. if not, a separate file could exist.
i guess there is the issue of whether you prefer to have these settings
distributed or all in one place...
what do you think?
More information about the openssh-unix-dev
mailing list