Google 网上论坛不再支持新的 Usenet 帖子或订阅项。历史内容仍可供查看。

Can server disallow -N option?

已查看 77 次
跳至第一个未读帖子

Bryan McWhirt

未读,
2011年1月20日 11:25:222011/1/20
收件人
Is it possible to tell the server to not allow -N style connections to
the server. Basically I want to force the login shell to run. Both
Command and ForceCommand do not seem to work when a -N connection is
made so I want to force users to open a shell.

Simon Tatham

未读,
2011年1月21日 12:34:302011/1/21
收件人

In principle, in terms of what the SSH protocol permits: a server
can't _literally_ force a client to open a shell channel, because the
client initiates the process by sending SSH_MSG_CHANNEL_OPEN.

A server could refuse any other service in the absence of a shell
channel, though: if the -N users are just there for the port
forwarding, you could have the server refuse all channel open requests
for 'direct-tcpip' and all global requests for 'tcpip-forward' until a
shell channel was opened. That would render ssh -N completely useless.

In practice, I don't know of any server that supports this. It seems
like a pretty unfriendly thing to want to do to your users!
--
Simon Tatham "infinite loop _see_ loop, infinite"
<ana...@pobox.com> - Index, Borland Pascal Language Guide

Bryan McWhirt

未读,
2011年1月21日 13:59:242011/1/21
收件人
On 1/21/11 12:34 PM, Simon Tatham wrote:
> Bryan McWhirt<bmmc...@gmail.com> wrote:
>> Is it possible to tell the server to not allow -N style connections to
>> the server. Basically I want to force the login shell to run. Both
>> Command and ForceCommand do not seem to work when a -N connection is
>> made so I want to force users to open a shell.
>
> In principle, in terms of what the SSH protocol permits: a server
> can't _literally_ force a client to open a shell channel, because the
> client initiates the process by sending SSH_MSG_CHANNEL_OPEN.
>
> A server could refuse any other service in the absence of a shell
> channel, though: if the -N users are just there for the port
> forwarding, you could have the server refuse all channel open requests
> for 'direct-tcpip' and all global requests for 'tcpip-forward' until a
> shell channel was opened. That would render ssh -N completely useless.
>
> In practice, I don't know of any server that supports this. It seems
> like a pretty unfriendly thing to want to do to your users!

Well unfortunately because of the -N there is no way to limit the number
of connections a valid user can create. In theory you could have a user
who has access to 10,000 IP addressed create 10,000 shellless tunnels.
You can of course limit the number of connections to a service but that
doesn't stop a single user from taking them all stopping other user from
using the service.

The goal here is to allow our field agents to use SSH to tunnel traffic
when in the field. OpenVPN was not a solution because in many places the
field agents can not install anything and all VPN require a network
driver of some sort and in man cases they will not have administrative
rights. SSH solves this but if a field agent leave the connection open
by accident, or decides to use it from home or share the account there
is nothing that can be done. You just fire the employee. However I would
prefer to just keep it from happening at all. The only way I know to do
this is writing a custom login shell like 'nologin' that allows only one
instance of itself per user. This works fine unless the -N option is
used. The -N option allows for a DDoS attack if a valid user
account/certificate is obtained. Every solution I have found for this is
cleanup and not preventative.

The current OSes we use here are FreeBSD, OS X, and IRIX. If anyone has
a preventative solution that I can implement in those OSes I would
greatly appreciate it. More so if the solution is identical across the
board.

0 个新帖子