SSH client insists on /dev/tty - SSH

This is a discussion on SSH client insists on /dev/tty - SSH ; Hi, I'm running a RHEL 5.2 on an IBM System z Mainframe. From this system, I created a RAM disk with some necessary binaries and my own init script. I now can boot into this RAM disk using the distribution ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: SSH client insists on /dev/tty

  1. SSH client insists on /dev/tty

    Hi,

    I'm running a RHEL 5.2 on an IBM System z Mainframe. From this system, I
    created a RAM disk with some necessary binaries and my own init script.
    I now can boot into this RAM disk using the distribution kernel [1].

    There are two ways to connect to this system running with my RAM disk:
    Directly with a x3270 terminal [2] or via SSH to the SSH server,
    running within this RAM disk. The problem is that SSH [3] is not
    working when I use the x3270 client.

    If I try to SSH to another machine from within the RAM disk, SSH will
    say:

    debug1: read_passphrase: can't open /dev/tty: No such device or address
    Host key verification failed.

    Obviously, /dev/tty *does* exist and has the proper permissions:

    sh-3.2# ls -l /dev/tty
    crw-rw-rw- 1 sysload 0 5, 0 Oct 21 15:01 /dev/tty

    The shell running in this terminal is using /dev/console, although ps
    doesn't seem to get this right:

    sh-3.2# ps
    PID TTY TIME CMD
    717 ? 00:00:00 sh

    sh-3.2# ls -l /proc/717/fd
    total 0
    lrwx------ 1 sysload 0 64 Oct 21 15:01 0 -> /dev/console
    lrwx------ 1 sysload 0 64 Oct 21 15:05 1 -> /dev/console
    lrwx------ 1 sysload 0 64 Oct 21 15:05 2 -> /dev/console
    lrwx------ 1 sysload 0 64 Oct 21 15:05 255 -> /dev/console
    [..]

    If I connect via SSH from my client, the shell running within this
    session is using pts/0. Now, I *can* SSH to another machine, since SSH
    is now able to ask for a password.

    The problem is, that I need SSH to work without this, because there are
    scripts that need to be run. But I can't figure out how to tell SSH
    which device to use. The -t option doesn't do the trick.

    Since I have no idea on what to do next, any hint would be greatly
    appreciated.

    thanks in advance,
    stephan


    [1] In this case 2.6.18-92.el5
    [2] That's like a serial terminal, for those not familiar with System z
    [3] OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006

  2. Re: SSH client insists on /dev/tty

    >>>>> "SM" == Stephan Mann writes:

    SM> Hi, I'm running a RHEL 5.2 on an IBM System z Mainframe. From this
    SM> system, I created a RAM disk with some necessary binaries and my
    SM> own init script. I now can boot into this RAM disk using the
    SM> distribution kernel [1].

    SM> There are two ways to connect to this system running with my RAM
    SM> disk: Directly with a x3270 terminal [2] or via SSH to the SSH
    SM> server, running within this RAM disk. The problem is that SSH [3]
    SM> is not working when I use the x3270 client.

    SM> If I try to SSH to another machine from within the RAM disk, SSH
    SM> will say:

    SM> debug1: read_passphrase: can't open /dev/tty: No such device or
    SM> address Host key verification failed.

    SM> Obviously, /dev/tty *does* exist and has the proper permissions:

    SM> sh-3.2# ls -l /dev/tty crw-rw-rw- 1 sysload 0 5, 0 Oct 21 15:01
    SM> /dev/tty

    The *file* exists, but is it mapped to the right device? I think you
    don't know; as you say next, your shell isn't actually using /dev/tty.

    SM> The shell running in this terminal is using /dev/console, although
    SM> ps doesn't seem to get this right:

    SM> sh-3.2# ps PID TTY TIME CMD 717 ? 00:00:00 sh

    SM> sh-3.2# ls -l /proc/717/fd total 0 lrwx------ 1 sysload 0 64 Oct
    SM> 21 15:01 0 -> /dev/console lrwx------ 1 sysload 0 64 Oct 21 15:05
    SM> 1 -> /dev/console lrwx------ 1 sysload 0 64 Oct 21 15:05 2 ->
    SM> /dev/console lrwx------ 1 sysload 0 64 Oct 21 15:05 255 ->
    SM> /dev/console [..]

    SM> If I connect via SSH from my client, the shell running within this
    SM> session is using pts/0. Now, I *can* SSH to another machine, since
    SM> SSH is now able to ask for a password.

    SM> The problem is, that I need SSH to work without this, because
    SM> there are scripts that need to be run. But I can't figure out how
    SM> to tell SSH which device to use. The -t option doesn't do the
    SM> trick.

    SM> Since I have no idea on what to do next, any hint would be greatly
    SM> appreciated.

    SM> thanks in advance, stephan


    SM> [1] In this case 2.6.18-92.el5 [2] That's like a serial terminal,
    SM> for those not familiar with System z [3] OpenSSH_4.3p2, OpenSSL
    SM> 0.9.8b 04 May 2006

    --
    Richard Silverman
    res@qoxp.net


  3. Re: SSH client insists on /dev/tty

    Stephan Mann wrote:
    > debug1: read_passphrase: can't open /dev/tty: No such device or address

    [...]
    > Obviously, /dev/tty *does* exist and has the proper permissions:
    > sh-3.2# ls -l /dev/tty
    > crw-rw-rw- 1 sysload 0 5, 0 Oct 21 15:01 /dev/tty


    /dev/tty is defined to point to the "controlling terminal" of
    whatever process tries to open it. Some processes have no
    controlling terminal, in which case they will receive an ENXIO error
    when trying to open /dev/tty - which is what you're seeing above.
    The presence or absence of the special file itself is not the point.

    The trouble is that "controlling terminal" never quite means what
    you think it means. In particular, it need not bear any relation to
    the terminal device that your process has open on fds 0, 1 and 2:
    even if all those fds point to the same terminal device, your
    official controlling terminal is at liberty to be something else, or
    nothing at all.

    > The shell running in this terminal is using /dev/console, although ps
    > doesn't seem to get this right:
    >
    > sh-3.2# ps
    > PID TTY TIME CMD
    > 717 ? 00:00:00 sh


    ps _is_ getting it right: it's showing you - accurately - that your
    official controlling terminal is not set, even though all your file
    descriptors are what you want them to be.

    If I needed to solve this problem, I'd use a small utility of my own
    which allocates a pseudo-terminal and runs a subprocess inside it.
    Unfortunately, I've never got round to publishing that utility
    properly on my website, but if you can access Subversion servers you
    should be able to get hold of it by checking out

    svn://svn.tartarus.org/sgt/filter

    and running "make nullfilter". Then, if you run the resulting
    nullfilter binary, it will start a subshell which should have a
    sensible controlling terminal. Alternatively, running
    "nullfilter -- ssh " will cause nullfilter to wrap just
    the ssh command itself.

    (I never really intended nullfilter to be a useful program in its
    own right; the rest of that source directory is full of filter
    programs which run things in ptys and interfere in various ways with
    their I/O. nullfilter is the trivial member of that class of
    programs, since it doesn't interfere with the I/O at all, but
    curiously I keep finding uses like this one for it. Never neglect
    the trivial case!)
    --
    Simon Tatham "Every person has a thinking part that wonders what
    the part that isn't thinking isn't thinking about."

  4. Re: SSH client insists on /dev/tty

    On 2008-10-22, Simon Tatham wrote:
    > Stephan Mann wrote:
    >> debug1: read_passphrase: can't open /dev/tty: No such device or address

    [..]
    >>
    >> sh-3.2# ps
    >> PID TTY TIME CMD
    >> 717 ? 00:00:00 sh

    >
    > ps _is_ getting it right: it's showing you - accurately - that your
    > official controlling terminal is not set, even though all your file
    > descriptors are what you want them to be.


    Thank you very much for your explanation. I guess I'll have to learn about
    terminals in Linux.

    > If I needed to solve this problem, I'd use a small utility of my own
    > which allocates a pseudo-terminal and runs a subprocess inside it.
    > Unfortunately, I've never got round to publishing that utility
    > properly on my website, but if you can access Subversion servers you
    > should be able to get hold of it by checking out
    >
    > svn://svn.tartarus.org/sgt/filter


    Nice! I'll definitely take a look. I did a checkout and will report back
    as soon as possible but unfortunately I will be offline for a few days.

    many thanks again,
    stephan

+ Reply to Thread