Why does SSH require a *local* shell?

[Ian Pilcher]

And is there a way to get around this requirement?

I am trying to set up a service that will provide an SSH tunnel. It
basically just needs to run:

ssh -NT -L 8080:localhost:80 tunnel@remote

I have created a "tunnel" user on both the local and remote systems for
this purpose. On the remote system, the tunnel user's shell is set to
/bin/true, and this doesn't cause any problems (thanks to the -N
parameter).

However, I've found that SSH doesn't work if the *local* tunnel user
doesn't have a working shell. For example, if I set the local tunnel
user's shell to /sbin/nologin, the connection fails with the following
message.

debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: ssh_exchange_identification: This account is currently not
available.

ssh_exchange_identification: Connection closed by remote host

"tunnel" is a service account, so it really shouldn't have a shell.

Why is SSH trying to run the *local* user's shell, and is there a way to
change this behavior?

--
========================================================================
Ian Pilcher arequ...@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

[William Unruh]

On 2021-06-04, Ian Pilcher <arequ...@gmail.com> wrote:
> And is there a way to get around this requirement?
>
> I am trying to set up a service that will provide an SSH tunnel. It
> basically just needs to run:
>
> ssh -NT -L 8080:localhost:80 tunnel@remote
>
> I have created a "tunnel" user on both the local and remote systems for
> this purpose. On the remote system, the tunnel user's shell is set to
> /bin/true, and this doesn't cause any problems (thanks to the -N
> parameter).
>
> However, I've found that SSH doesn't work if the *local* tunnel user
> doesn't have a working shell. For example, if I set the local tunnel
> user's shell to /sbin/nologin, the connection fails with the following
> message.

Something has to interpret that that series of alphabetical characters
into commands, options, etc. That is what a shell does. The program
"nologin" does not do that. You could put it into /etc/rc.local in which
case it will be the root shell that does it.

[Ian Pilcher]

On 6/4/21 4:48 PM, William Unruh wrote:
> Something has to interpret that that series of alphabetical characters
> into commands, options, etc. That is what a shell does. The program
> "nologin" does not do that. You could put it into /etc/rc.local in which
> case it will be the root shell that does it.

You didn't read my question completely. I was asking why the SSH client
was executing the shell on the *local* system (the system on which the
SSH client itself is running). I've already set the shell on the remote
system to /bin/true, and it works fine (since I'm only creating a
tunnel).

It turns out that the issue was the presence of a ProxyCommand in the
global configuration (presumably added by the FreeIPA installation).
strace showed that the SSH client tries to use a shell to run the
command specified by the ProxyCommand, which obviously fails if the
shell is /sbin/nologin. After overriding that for this specific usage,
I am able to establish the tunnel as a "shell-less" user.

[Grant Taylor]

On 6/4/21 3:56 PM, Ian Pilcher wrote:
> It turns out that the issue was the presence of a ProxyCommand in the
> global configuration (presumably added by the FreeIPA installation).
> strace showed that the SSH client tries to use a shell to run the
> command specified by the ProxyCommand, which obviously fails if the
> shell is /sbin/nologin. After overriding that for this specific usage,
> I am able to establish the tunnel as a "shell-less" user.

Thank you for the follow up.

Though I will argue that from a Unix process perspective, the local user
/does/ have a shell. It's just not an interactive shell that we
typically think of. ;-)



--
Grant. . . .
unix || die