Re: FiSH Connection fails : mc freezing

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 ;-)




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]