openssh unix dev - Nov 2015 - How disable forwarding-only connections (i.e. non-shell/command non-sftp connections)? (Maybe this is a feature request!)

Hi Peter,

What I am looking for is an SSHD configuration where every successfully 
authenticated connection also guaranteedly will lead to a ForcedCommand 
invocation.


Currently I understand this to be the case only for the connections that 
open channel to deliver a terminal, command or SFTP (I don't know if you 
have a collective name for such non-forwarding channels).


Is this possible?

Do you feel that it is a relevant feature?

Thanks,
Tinker

On 2015-11-26 08:10, Peter Stuge wrote:
> Tinker wrote:
>> I tried with all available options to disable forwarding-only
>> connections, by:
>> 
>> "AllowAgentForwarding no
>> AllowTcpForwarding no"
>> 
>> This had no effect, so what I got in effect was dummy connections.
> 
> The above two options combined with X11Forwarding no added to your
> sshd_config will disallow all forwarding.
> 
> Please explain what you mean by "dummy" above?
> 
> 
>> I would like to disable this "class" of connections
altogether.
> 
> Note that a forwarding is not a connection, but a channel. One
> connection can have several channels.
> 
> 
>> The outcome will be that all authenticated connections will lead to
>> a command, be it /usr/libexec/sftp-server or other.
> 
> The above three options should do just that. If it's not working as
> you want then please provide debug log output from the sshd where you
> have added the three above configuration statements, when a client
> connects to it and is able to open a forwarding channel. That would
> be a bug.
> 
> 
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, Nov 26, 2015 at 3:41 PM, Tinker <tinkr at openmailbox.org>
wrote:
> What I am looking for is an SSHD configuration where every successfully
> authenticated connection also guaranteedly will lead to a ForcedCommand
> invocation.
[...]
> Is this possible?
I don't think it's possible.  Or at least, not in any reasonable way.

The SSH (v2) protocol can have zero or more channels multiplexed over
it, and after the connection has been established (and authenticated)
it is up to the client to request whatever channels it wants.

Simplifying a little, these channels can be "session" (ie interactive
shell or non-interactive commands) or port forwards.  The client may
specify zero or more of these channels of either type, and there's
nothing that requires the client to request a session channel at all
(eg ssh's -N option).  The "session" request is where ForceCommand
is
applied.

You could potentially hack the server to reject forwarding requests
until it had seen a session request, but that'd break reasonable
client behaviours.

What's the objective of this exercise?

-- 
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.

On 2015-11-26 13:03, Darren Tucker wrote:
> On Thu, Nov 26, 2015 at 3:41 PM, Tinker <tinkr at openmailbox.org>
wrote:
>> What I am looking for is an SSHD configuration where every 
>> successfully
>> authenticated connection also guaranteedly will lead to a 
>> ForcedCommand
>> invocation.
> [...]
>> Is this possible?
> 
> I don't think it's possible.  Or at least, not in any reasonable
way.
> 
> The SSH (v2) protocol can have zero or more channels multiplexed over
> it, and after the connection has been established (and authenticated)
> it is up to the client to request whatever channels it wants.
> 
> Simplifying a little, these channels can be "session" (ie
interactive
> shell or non-interactive commands) or port forwards.  The client may
> specify zero or more of these channels of either type, and there's
> nothing that requires the client to request a session channel at all
> (eg ssh's -N option).  The "session" request is where
ForceCommand is
> applied.
Aha, I understand the protocol level problem.
> You could potentially hack the server to reject forwarding requests
> until it had seen a session request, but that'd break reasonable
> client behaviours.
> 
> What's the objective of this exercise?
The goal is to get a script invoked *at login time*, so that the 
authentication only is known to the client after that the script 
invocation has completed.

Does that make sense as a usecase? :)

Can it be done?

I understand that it can can be done via PAM, but then PAM is not in all 
environments and everyone don't like PAM.