Am Sonntag, 7. Oktober 2001 17:49 schrieb Pavel Roskin: Hi Pavel,
> > 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 don't understand. SSH already accepts all input of the remote program > on stdin. Only password, passphrase and confirmations (e.g. for unknown > host key) are asked on /dev/tty. I intended that. > > 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. > > I think it was Pavel Machek. But the problem with such patches is that > they have a very limited audience. Very small percentage of MC users will > recompile ssh just to get FiSH to work with passwords. This is the weak point, I agree. I`ll try to figure out if it is possible to make behave the ssh client without any hacks; I don`t understand yet how the code works. > And most importantly, it is not needed. It is possible to redirect > child's /dev/tty from a C program by using pseudoterminals, although I > don't know how to do it in the shell. I have no idea. > [...] > I think we are talking about different things. I meant that MC should > create the pseudoterminal, not SSH. If it were impossible, then I would > not be able to run ssh from MC with subshell support. MC controls all > input of ssh in this case. I don`t know if ssh checks if the controlling tty is a _real_ tty, though... > I agree that using /dev/tty is not very user-friendly. But it makes it > possible to distinguish between 5 channels of communication (3 channels > for the remote program and 2 local channels). Maybe ssh could use file > descriptors above stderr (i.e. 3) for local communication if they are open > on startup, but it's a theme for an ssh mailing list. > > > 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. > > My only question was whether MC should stand in the middle or let the user > to communicate with ssh directly. IMHO that could have some advantages (letting the user communicate with ssh directly) : - Trust - MC would be independent from varying output of ssh (unknown host key etc.) > > > 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. Quite more pretty than the actual situation ;-) cu, Hans -- Hans Peter Stroebel <[EMAIL PROTECTED]> Yes, I do. But not Yahoo. _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
