Why "ssh -f -n" still connects to ptys?

[Darren Tucker]

On Tue, Feb 7, 2017 at 5:15 PM, Clark Wang <dearvoid at gmail.com> wrote:
> See following example:
>
> $ ps p 45374
>    PID TTY      STAT   TIME COMMAND
>  45374 ?        Ss     0:00 ssh -N -D 7777 -f -n localhost
> $ ls -l /proc/45374/fd/
> total 0
> lrwx------ 1 root root 64 2017-02-07 14:12 0 -> /dev/pts/2
> lrwx------ 1 root root 64 2017-02-07 14:12 1 -> /dev/pts/2
> lrwx------ 1 root root 64 2017-02-07 14:12 2 -> /dev/pts/2
> lrwx------ 1 root root 64 2017-02-07 14:12 3 -> socket:[348711]
> lrwx------ 1 root root 64 2017-02-07 14:12 4 -> socket:[348767]
> $
>
> Why not open FDs 0, 1 and 2 on /dev/null?

It's not obvious from the man page (I had to look at the code), but
that's not how it works.  -n affects the handling of the descriptor
attached to the ssh command channel, not the descriptors that the ssh
process uses to interact with the user.

-n (or -f, you only need to set one of them) set stdin_null_flag, and
what it does when setting up the channel connected to the remote
command is:

ssh_session2_open [...]
        if (stdin_null_flag)
                in = open(_PATH_DEVNULL, O_RDONLY);
        else
                in = dup(STDIN_FILENO);
        out = dup(STDOUT_FILENO);
        err = dup(STDERR_FILENO);

Compare with and without -n:

$ ssh localhost sleep 60
$ ls -l /proc/25235/fd
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 0 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 1 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 2 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 3 -> 'socket:[149316207]'
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 4 -> 'socket:[149316212]'
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 5 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 6 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:26 7 -> /dev/pts/30

$ ssh -n localhost sleep 60
$ ls -l /proc/24959/fd/
total 0
lrwx------ 1 dtucker dtucker 64 Feb  8 15:25 0 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:25 1 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:25 2 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:25 3 -> 'socket:[149315695]'
lrwx------ 1 dtucker dtucker 64 Feb  8 15:25 4 -> 'socket:[149315701]'
lrwx------ 1 dtucker dtucker 64 Feb  8 15:25 6 -> /dev/pts/30
lrwx------ 1 dtucker dtucker 64 Feb  8 15:25 7 -> /dev/pts/30

Note that fd#5 (stdin attached to the command channel) is missing in
the second.  In your case you're not seeing any change in behaviour
because -N causes ssh to not request a command channel at all.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.