Re: A background ssh can take over the tty from bash?

[John McKown]

On Sat, Jun 10, 2017 at 9:19 AM, Clark Wang <dearvoid@gmail.com> wrote:

> (I'm using bash 4.4.12 on Debian 8)
>
> Please follow the following steps to reproduce.
>
> From tty #1:
>
> $ tty
> /dev/pts/11
> $ ssh -o ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0.0.1
> root@127.0.0.1's password:
> $ ps -C ssh uw
> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
> root       716  0.0  0.2  44428   692 ?        Ss   22:04   0:00 ssh -o
> ControlMaster=yes -o ControlPath=/tmp/socket.tmp -N -f 127.0
> $
> $
> ​​
> ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
> 9999 &
> [1] 725
> $    <-- Then I cannot input anything except CTRL-C
>
> Go to tty #2:
>
> $ ps t pts/11 jw
>  PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
> 32714   725   725 32714 pts/11   32714 S        0   0:00 ssh -o
> ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 9999
>   579 32714 32714 32714 pts/11   32714 Ss+      0   0:00 bash
> $
>
> If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp
> 127.0.0.1 sleep 9999" then tty #1 (pts/11) would be able to accept my input
> again. Seems like the background "ssh" at tty #1 is consuming all input. I
> cannot understand this since it should be stopped by SIGTTIN if it tries to
> read from the tty.
>
> Idea?
>
> -clark
>

​IMO, not a bug in BASH, so this is the wrong forum. But, since I'm already
blathering on, I'd say the problem is that you have invoked "ssh"
incorrectly.​ In particular, ssh _does_ read from stdin normally. But, from
the man page:

 -f      Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords
             or passphrases, but the user wants it in the background.  This
implies -n.  The recommended way to start X11 programs
             at a remote site is with something like ssh -f host xterm.

             If the ExitOnForwardFailure configuration option is set to
“yes”, then a client started with -f will wait for all
             remote port forwards to be successfully established before
placing itself in the background.


So instead of:

​
ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep 9999
&

Try:

​
ssh -f -o ControlMaster=no -o ControlPath=/tmp/socket.tmp 127.0.0.1 sleep
9999

-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown