Re: FiSH Connection fails : mc freezing

[Hans Peter Stroebel <hpstr operamail com>]

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 ?

ciao,

Hans

-- 

Hans Peter Stroebel <hpstr operamail com>

Yes, I do. But not Yahoo.