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

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.

On Thu, Nov 26, 2015 at 4:11 PM, Tinker <tinkr at openmailbox.org>
wrote:
> The goal is to get a script invoked *at login time*,
This part I follow, but having a script run is just a means to an end
not the end itself.  What is the script going to do?
> so that the authentication only is known to the client after that the
script invocation
> has completed.
I don't quite follow the part about the "authentication being known to
the client".  You want your command to complete before allowing any
port forwards?  Does the result of the script matter?
> 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.
PAM or bsdauth are the two obvious ways to do this.  If you are always
using public-key authentication, you could possibly abuse
AuthorizedKeysCommand in sshd_config.

This sounds a bit like what authpf[1] does.  I imagine you could write
firewall rules to block outgoing tcp connections from sshd until after
authpf runs, if that is an option for you.

[1] http://www.openbsd.org/faq/pf/authpf.html

-- 
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:33, Darren Tucker wrote:
> On Thu, Nov 26, 2015 at 4:11 PM, Tinker <tinkr at openmailbox.org>
wrote:
>> The goal is to get a script invoked *at login time*,
> 
> This part I follow, but having a script run is just a means to an end
> not the end itself.  What is the script going to do?
> 
>> so that the authentication only is known to the client after that the 
>> script invocation
>> has completed.
> 
> I don't quite follow the part about the "authentication being
known to
> the client".  You want your command to complete before allowing any
> port forwards?
Yes.
> Does the result of the script matter?
No.
>> 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.
> 
> PAM or bsdauth are the two obvious ways to do this.
How would you do it using bsdauth?

(PAM seems very redundant to install on OBSD.)
> If you are always
> using public-key authentication, you could possibly abuse
> AuthorizedKeysCommand in sshd_config.
As in key files. Could be partially interesting to know how a 
passthrough script would look for it, but, if an all-encompassing way 
could be worked out it would be better i.e. that supports password 
logins too.
> This sounds a bit like what authpf[1] does.  I imagine you could write
> firewall rules to block outgoing tcp connections from sshd until after
> authpf runs, if that is an option for you.
(That sounds like a very indirect approach, in particular as it would 
cover only some connections?)
> 
> [1] http://www.openbsd.org/faq/pf/authpf.html
Thanks!