Does ssh run commands (rather than shell itself) in a login shell?

Question

According to man sshd:

 LOGIN PROCESS
      When a user successfully logs in, sshd does the following:
  <...>

        9.   Runs user's shell or command.  All commands are run under the
             user's login shell as specified in the system password data‐
             base.

It is not clear, though, does "run under the user's login shell" literally mean "Login shell, as in bash -l"? My experiments show that no, it is not:

$ ssh u@h shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'
Not login shell

I can't see why this is so? It results in commands being run doesn't get the usual environment as just logins to shell. This is cumbersome.

Answer 1

login shell can mean two different things in that context:

1. the shell that is defined as the login shell for the user in the account database.

   For instance:

   $ getent passwd stephane
   stephane:*:1000:1000:Stephane Chazelas:/home/stephane:/bin/zsh
   

   /bin/zsh is my login shell, the 7^th field in my entry in the account database. Some other users may have /bin/tcsh, /bin/fish, /bin/bash, /sbin/nologin, /bin/false...

2. an invocation of a shell used to initialise a login session, the ones that are usually done by login / sshd... by prefixing the argv[0] with - (some shells also accept a -l or --login option for that) and tell the shell to interpret some session initialisation files such as .profile, .login, .zlogin, etc.

In any case the sh in ssh is for shell, and sshd like rshd before it, always invokes a shell to interpret the code sent by the client if any.

If you run:

ssh user@host foo    bar

Where foo and bar arguments are passed to ssh, ssh joins them with spaces and sends the foo bar shell code to the server.

The server on host will run the login shell of user with 3 arguments:

0. the basename of the login shell. In my case zsh
1. -c
2. the code given by the client: foo bar in that example

And the shell will interpret that as code in its own syntax¹, it will not be run as a login shell, the argv[0] doesn't start with a -.

If no argument is passed to the client, like when it's invoked as:

ssh user@host

Then the rlogin mode is entered (like rsh that used to run rlogin when not passed a command), then a pseudo-tty is used and sshd runs the login shell of the user with only one argument (argv[0]):

0. the basename of the login shell prefixed with a -, in my case -zsh.

And that tells the shell it is running as a login shell and it will read .zprofile / .profile / .login.

So to sum up:

• ssh host shell-code is like rsh host shell-code and runs a command remotely by having the login shell of the remote user parse some code.
• ssh host is like rlogin host, and logs you in remotely by starting your login shell in login shell mode in a virtual terminal.

---

^{¹ for this very simple one, except for /bin/false or /sbin/nologin of course and maybe for users who like to have /usr/bin/python3 as their login shell, the code will interpreted the same by all shells, but for more complex ones, there will be some variation. See also How to execute an arbitrary simple command over ssh without knowing the login shell of the remote user?}

Answer 2

No, SSH only invokes a login shell when logging you into a shell, not when running a command. This means that if you want your login initialization files to run (e.g. ~/.profile), you need to do this explicitly. This is a deliberate design choice: in the days where most logins were on a text terminal, many users would run commands in their .profile which only make sense when logging in for an interactive session. (This is much less common now that most people log in locally to a graphical session.) You wouldn't want a quick ssh example.com ls, or worse an rsync example.com:somefile ., to start Emacs and turn on your modem to fetch your email!

---

The command in SSH is a string, obtained by concatenating the command line arguments with a space in between. For example ssh u@h shopt -q login_shell runs the command shopt -q login_shell. It's exactly equivalent to ssh u@h 'shopt -q login_shell', or ssh u@h 'shopt -q' login_shell, etc.

SSH passes that string to the user's login shell. SSH does not know about any other shell. The server might be running on a non-Unix system or in a restricted environment where there is no program called sh or bash.

The SSH server runs the executable that is listed in the user database as the user's login shell, but not necessarily as a login shell. When the command line is non-empty, it passes a three-argument list:

• argv[0] is the program's base name, following the usual convention.
• argv[1] is the string -c.
• argv[2] is the command passed by the client.

For an empty command line, the SSH server invokes the user's login shell as a login shell. This means a one-argument list:

• argv[0] is a dash (-) followed by the program's base name.

For example, here's the output of ssh localhost 'cat /proc/$$/cmdline | tr \\0 \\n' on a Linux machine:

sh
-c
cat /proc/$$/cmdline | tr \\0 \\n

For a login shell, it's more difficult to observe, because the login shell itself will typically run other programs. The easy way to see what's going on is to temporarily disable the login shell's initialization file(s), for example by temporarily renaming ~/.profile (or ~/.bash_profile, ~/.zprofile, etc. depending on which shell you use). Here's an example on an account with /bin/sh as the login shell:

$ mv ~/.profile ~/not.profile
$ ssh localhost
(/etc/motd content goes here)
Last login: Mon Apr 24 18:00:30 2023
$ cat /proc/$$/cmdline; echo
-sh
$ exit
Connection to localhost closed.
$ mv ~/not.profile ~/.profile