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 <[EMAIL PROTECTED]> Yes, I do. But not Yahoo. _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
