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

[Tinker]

Hi!

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.

I would like to disable this "class" of connections altogether. The
outcome will be that all authenticated connections will lead to a
command, be it /usr/libexec/sftp-server or other.

So something like "ForwardingOnlyConnections on/off".

Would you be interested in adding this to your next release?

Thanks!

[Ángel González]

Post by Tinker
Hi!
I tried with all available options to disable forwarding-only
"AllowAgentForwarding no
AllowTcpForwarding no"
This had no effect, so what I got in effect was dummy connections.
I would like to disable this "class" of connections altogether. The
outcome will be that all authenticated connections will lead to a
command, be it /usr/libexec/sftp-server or other.
So something like "ForwardingOnlyConnections on/off".
Would you be interested in adding this to your next release?
Thanks!

I don't think the ssh protocols allows that. You first authenticate, and
only then you create the different channels. Also, it would be possible
to create a pty channel, then a forwarding, then close the first channel.
Do you want to allow forwardings for "command connections"?

[Tinker]

Post by Ángel González

Post by Tinker
Hi!
I tried with all available options to disable forwarding-only
"AllowAgentForwarding no
AllowTcpForwarding no"
This had no effect, so what I got in effect was dummy connections.
I would like to disable this "class" of connections altogether. The
outcome will be that all authenticated connections will lead to a
command, be it /usr/libexec/sftp-server or other.
So something like "ForwardingOnlyConnections on/off".
Would you be interested in adding this to your next release?
Thanks!

I don't think the ssh protocols allows that. You first authenticate,
and only then you create the different channels. Also, it would be
possible to create a pty channel, then a forwarding, then close the
first channel.
Do you want to allow forwardings for "command connections"?

Angel,

Yes - actually my whole problem is that ForceCommand is invoked for
*all* SSH connections, *except* for the forwarding-only connections.

Maybe another solution would be to add an option so that ForceCommand
always is run, e.g. for /bin/noop on all non-SFTP non-shell non-command
connections.

Thanks!

[Tinker]

Post by Tinker

Post by Ángel González

Post by Tinker
Hi!
I tried with all available options to disable forwarding-only
"AllowAgentForwarding no
AllowTcpForwarding no"
This had no effect, so what I got in effect was dummy connections.
I would like to disable this "class" of connections altogether. The
outcome will be that all authenticated connections will lead to a
command, be it /usr/libexec/sftp-server or other.
So something like "ForwardingOnlyConnections on/off".
Would you be interested in adding this to your next release?
Thanks!

I don't think the ssh protocols allows that. You first authenticate,
and only then you create the different channels. Also, it would be
possible to create a pty channel, then a forwarding, then close the
first channel.
Do you want to allow forwardings for "command connections"?

Angel,
Yes - actually my whole problem is that ForceCommand is invoked for
*all* SSH connections, *except* for the forwarding-only connections.
Maybe another solution would be to add an option so that ForceCommand
always is run, e.g. for /bin/noop on all non-SFTP non-shell
non-command connections.

Ah - kindly let me know how you see that this works currently, and what
you say about the suggestion?

Thanks

[Peter Stuge]

Post by Tinker
I tried with all available options to disable forwarding-only
"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?

Post by Tinker
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.

Post by Tinker
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

[Tinker]

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

Post by Peter Stuge

Post by Tinker
I tried with all available options to disable forwarding-only
"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?

Post by Tinker
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.

Post by Tinker
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
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Tinker]

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

[...]

Post by Tinker
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.

[Darren Tucker]

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

[...]

Post by Tinker
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]

Post by Tinker
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?

Post by Tinker
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?

Post by Tinker
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

[Tinker]

Post by Darren Tucker

Post by Tinker
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?

Post by Tinker
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.

Post by Darren Tucker
Does the result of the script matter?

No.

Post by Darren Tucker

Post by Tinker
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.)

Post by Darren Tucker
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.

Post by Darren Tucker
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?)

Post by Darren Tucker
[1] http://www.openbsd.org/faq/pf/authpf.html

Thanks!

[Tinker]

[...]

Post by Tinker

Post by Darren Tucker
What is the script going to do?

You didn't answer this.

Register the login to the group's login database.

Post by Tinker
How would you do it using bsdauth?
(PAM seems very redundant to install on OBSD.)

You are using OpenBSD or something else?

OpenBSD.

[...]

Post by Tinker

Post by Darren Tucker
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?)

Assuming you write the PF rules to do so you should be able to match
local processes (using "user" rules and the $user_id authpf macro) as
well as connections from the IP address they're logging in as (using
"from" rules and $user_ip macro).

Wait, to PF, isn't the user for all SSH connections "root" (independent
of what user you log in as)?

Also, how would PF know when an SSH connection became authenticated as
to trig some rule to run a script, then.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/pf.conf.5?query=pf%2econf&arch=i386

But all of this is speculative because you still have not described
what the objective of this exercise is.

The object is to get a complete set of registrations of all logins on
all servers, at auth time, sent by the registration script to the
central database.


(If the auth time requirement was not there, adding the script as a
"pipe" line in syslog.conf could have worked, but I think because it's
quite indirect it's unpreferable, also not sure if you can get the
client IP there.)

[Darren Tucker]

[...]

Post by Tinker

Post by Darren Tucker
What is the script going to do?

You didn't answer this.

Post by Tinker
How would you do it using bsdauth?
(PAM seems very redundant to install on OBSD.)

You are using OpenBSD or something else?

[...]

Post by Tinker

Post by Darren Tucker
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?)

Assuming you write the PF rules to do so you should be able to match
local processes (using "user" rules and the $user_id authpf macro) as
well as connections from the IP address they're logging in as (using
"from" rules and $user_ip macro).

But all of this is speculative because you still have not described
what the objective of this exercise is.

[Darren Tucker]

On Thu, Nov 26, 2015 at 5:23 PM, Tinker <***@openmailbox.org> wrote:
[...]

Wait, to PF, isn't the user for all SSH connections "root" (independent of
what user you log in as)?

Not since privilege separation became the default ten years or so ago:
forwarded TCP connections will come from the unprivileged child sshd
running as the logged-in user.

Also, how would PF know when an SSH connection became authenticated as to
trig some rule to run a script, then.

authpf would just be the mechanism for ensuring that they'd sent a
session request, otherwise their outgoing tcp connections coming out
of sshd would get denied by PF. You could have your script as the
login shell do its thing then exec authpf (or authpf-noip) at the end.

The object is to get a complete set of registrations of all logins on all
servers, at auth time, sent by the registration script to the central
database.
(If the auth time requirement was not there, adding the script as a "pipe"
line in syslog.conf could have worked, but I think because it's quite
indirect it's unpreferable, also not sure if you can get the client IP
there.)

OK, thanks. It feels like there should be some way to get a bsdauth
module to do this, but I've never tried anything like this before. I
can't find an obvious equivalent to a PAM session module, I'm not even
sure there is one. I'll think about it a bit more.

[Tinker]

Post by Darren Tucker
[...]

Post by Tinker
Wait, to PF, isn't the user for all SSH connections "root"
(independent of
what user you log in as)?

forwarded TCP connections will come from the unprivileged child sshd
running as the logged-in user.

Post by Tinker
Also, how would PF know when an SSH connection became authenticated as
to
trig some rule to run a script, then.

authpf would just be the mechanism for ensuring that they'd sent a
session request, otherwise their outgoing tcp connections coming out
of sshd would get denied by PF. You could have your script as the
login shell do its thing then exec authpf (or authpf-noip) at the end.

Can you give an example of the pf.conf line and shellscript, that
appends the username and remote IP logged in to, to /tmp/logins.txt?
E.g. echo $user $ip >> /tmp/logins.txt .

Post by Darren Tucker

Post by Tinker
The object is to get a complete set of registrations of all logins on
all
servers, at auth time, sent by the registration script to the central
database.
(If the auth time requirement was not there, adding the script as a
"pipe"
line in syslog.conf could have worked, but I think because it's quite
indirect it's unpreferable, also not sure if you can get the client IP
there.)

OK, thanks. It feels like there should be some way to get a bsdauth
module to do this, but I've never tried anything like this before. I
can't find an obvious equivalent to a PAM session module, I'm not even
sure there is one. I'll think about it a bit more.

login.conf has an "approve" program option, I guess actually that one
applies for SSHD logins too?

www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/login.conf.5?query=login%2econf&sec=5

[Damien Miller]

Post by Tinker
Hi!
"AllowAgentForwarding no
AllowTcpForwarding no"
This had no effect, so what I got in effect was dummy connections.
I would like to disable this "class" of connections altogether. The outcome
will be that all authenticated connections will lead to a command, be it
/usr/libexec/sftp-server or other.

There's no real way to do this in the SSH protocol. After the SSH transport
protocol is running and authentication has completed, there's no ironclad
way to distinguish between a connection that will never execute a command
from one that's merely slow to do so.

I don't understand why turning off agent/X11/TCP forwarding was no
sufficient for you - could you clarify?

-d

[Tinker]

Damien,

Presuming it's actually using BSDauth, I think the most viable option is
to use the "approve" program option in login.conf to reach this goal
which is to get a command run on every successful SSH auth, to answer
your question.

Will need to try it out, will be back here if it does not.

The pf.conf auth user discussed in this thread previously could perhaps
work but I think it would be asynchronous.

Thanks,
Tinker

Post by Damien Miller

Post by Tinker
Hi!
I tried with all available options to disable forwarding-only
"AllowAgentForwarding no
AllowTcpForwarding no"
This had no effect, so what I got in effect was dummy connections.
I would like to disable this "class" of connections altogether. The
outcome
will be that all authenticated connections will lead to a command, be
it
/usr/libexec/sftp-server or other.

There's no real way to do this in the SSH protocol. After the SSH
transport
protocol is running and authentication has completed, there's no
ironclad
way to distinguish between a connection that will never execute a
command
from one that's merely slow to do so.
I don't understand why turning off agent/X11/TCP forwarding was no
sufficient for you - could you clarify?
-d
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev