FiSH Connection fails : mc freezing

[Hans Peter Stroebel]

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 <hpstr at operamail.com>

Yes, I do. But not Yahoo.