Re: FiSH Connection fails : mc freezing

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 ?




Hans Peter Stroebel <hpstr operamail com>

Yes, I do. But not Yahoo.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]