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

>>>>> "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

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."

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