openssh unix dev - Oct 2001 - FYI : FiSh connection over SSH fails : midnight commander freezing

Hello List-Members,

the forwarded message below is an excerpt from an actual discussion from the 
Midnigt Commander mailing list (mc at gnome.org, see www.gnome.org/mc/ for 
details).

It`s about a bug and a yet half-implemented feature in the mc fish (File 
transfer over shell) virtual file system support.
The FiSh filesystem allows the user to treat files on a remote server over a 
shell (ssh/rsh) connection as if they were local files, including the 
transfer of files over the shell connection from one filesystem to another.

This feature works fine over a ssh connection if ssh authenticates the user 
with a RSA key that is not protected with any passphrase.

If ssh requires any user interaction (passphrase request) instead, it does so 
on /dev/tty. mc cannot handle this I/O on /dev/tty yet and freezes. This 
problem should affect mc on all operating systems.

We're thinking about several solutions :

One of them would be to extend the ssh client to support an "-I"
switch that
makes it accepting the password on it`s STDIN, and (maybe) surpressing the 
password question or redirect it to it`s STDOUT or /dev/null.

I'm aware that normally this is not a desired behaviour (to avoid that users
are storing unencrypted passwords ?)
In this case it is not intended to store the unencrypted password in an 
expect script for example, but to enable the midnight commander to request 
the password in a popup window and then feed it to the ssh client`s stdin.
It is, for example, intended for use on computers where it might not be 
desired to store unprotected RSA private keys without passphrase, like 
notebooks.

Reading the code of the ssh client, it seems to me (I'm a C beginner, but 
somewhat intermediate in Perl) that it might be able to read from STDIN, but 
I did not figure out how yet (see below).

Any hints or comments would be highly welcome.

Thank you.


----------  Weitergeleitete Nachricht  ----------
Subject: Re: FiSH Connection fails : mc freezing
Date: Sun, 7 Oct 2001 15:40:58 +0200
From: Hans Peter Stroebel <hpstr at operamail.com>
To: mc at gnome.org


Am Sonntag,  7. Oktober 2001 10:44 schrieb Pavel Roskin:

Hi Pavel, Hi Pavel,   ;-)
> > fish does not suuport password auth because ssh always reads passwd
from
> > /ddev/tty. Fixssh to acceptt passwd from stdin, and we an fix mc.
>
> Actually, there is a good reason why ssh uses /dev/tty.  The standard
> channels (stdout, stdin, stderr) are connected to the remote program and
> should be completely independent from the authentication.  At least the
> recent versions of OpenSSH do it this way.  You can do this:
>
> ssh prog <infile >outfile 2>errfile
I tried that; indeed, it is not possible to redirect SSH`s input/output sent
to /dev/tty.

On the other hand, I think it would not be necessary to make SSH accept all
input on it`s stdin, would it ? The passphrase should be sufficient.

I tried to examine the code of OpenSSH 2.3.0p1 and to insert an -I
switch, but it seems to be quite complicated to me.

BTW, who did "invent" this switch ? Google left me completely
clueless.

However, the code in cli.c (precisely, the client function
"cli_read_passphrase") seems to have the possibilty to read even from
stdin :

  /*
   * Presents a prompt and returns the response allocated with xmalloc().
   * Uses /dev/tty or stdin/out depending on arg.  Optionally disables echo
   * of response depending on arg.  Tries to ensure that no other userland
   * buffer is storing the response.
   */

As one of the arguments a variable "from_stdin" is passed, but I did
whether
figure out where this variable is set nor where it is defined, it seems to be
always 0.

Depending on the value of "from_stdin", the function
"cli_open" seems to
return the file descriptors of /dev/tty or of stdin/stdout. I have no idea
yet if this behaviour, most probably depending on the value of
"from_stdin"
and maybe "cli_input" and "cli_output" (initialized with -1)
can be
influenced by an external application like mc _without_ hacking ssh, and if
it concerns only the initial operation of reading the password or _all_ of
SSH`s I/O.

If yes, this might help to solve the problem.
> It is possible to control /dev/tty of ssh if it's run in a
pseudoterminal,
> similar to how MC runs the subshell.  Still it will require that mc
I did not get SSH to allocate a pseudoterminal, it refuses if it is not the
controlling tty.
> interprets the output of ssh somehow.  Maybe MC could capture all output
> until ssh runs the fish server _or_ asks for the password/passphrase, but
> I envision problems with making it secure and reliable.
I tried even to surpress SSH`s output of the password request, no success.
After having compiled it for about some 20 times, I gave up (for now...).

At least, I did not break the program with my first tries in C ;-)

However, I`m not sure if this could resolve the problem, as the password has
to be fed to SSH in the right moment anyway.
> Another solution would be to hide the panels and run ssh on the same tty
> as MC.  The panels would be restored when the remote fish server answers.
> This would not be pretty, but it would completely eliminate the need to
> redirect /dev/tty and capture/feed anything.
How would this work ? I found no possibility to hide the panels temporarily ?
Hacking required ?

[...]

-------------------------------------------------------

Regards,

Hans

-- 

Hans Peter Stroebel <hpstr at operamail.com>

Yes, I do. But not Yahoo.

On Sun, Oct 07, 2001 at 05:04:46PM +0200, Hans Peter Stroebel
wrote:
> It`s about a bug and a yet half-implemented feature in the mc fish (File 
> transfer over shell) virtual file system support.
> The FiSh filesystem allows the user to treat files on a remote server over
a
> shell (ssh/rsh) connection as if they were local files, including the 
> transfer of files over the shell connection from one filesystem to another.
> 
> This feature works fine over a ssh connection if ssh authenticates the user
> with a RSA key that is not protected with any passphrase.
> 
> If ssh requires any user interaction (passphrase request) instead, it does
so
> on /dev/tty. mc cannot handle this I/O on /dev/tty yet and freezes. This 
> problem should affect mc on all operating systems.
> 
> We're thinking about several solutions :
you could abuse ssh-askpass:

if $DISPLAY is set and stdin is not a tty then
ssh executes $SSH_ASKPASS and waits for the userinput
on stdin.

-m