Another SSH client on Windows

Peter Stuge peter at stuge.se
Mon Dec 10 14:37:10 EST 2012


Cal Leeming [Simplicity Media Ltd] wrote:
> > > * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE"
> >
> > As was mentioned this is the server rejecting your new channel.
> 
> This should be nicely hidden by opening another connection then in
> the event of channels running out.
> 
> Think outside the box :)

It's not about any box.

Creating a new session automatically is what *you* want, but it may
be wildly inappropriate in any number of scenarios, so it is not a
reasonable default.


> > So start looking at, or even thinking about, what is required to do
> > it, and start sending patches. Again, you'll find that a general
> > solution is not possible.
> 
> Actually, it is. One method has already been described by the OP.

What was described is no general solution.


> I am not a C coder (8 years python dev), so I cannot contribute patches.

How deep is your operating system knowledge? The problem is on that
level, so hopefully you've been using python for lots of OS things,
because it would help to model this problem.

Every interactive session is a shell process started by sshd.

The current working directory is a per-process property.

It is inappropriate for an SSH client to make assumptions about
any processes on the server which the client does not control.

Interactive sessions are by definition not such processes; they are
controlled by the user.

It was mentioned before on this list, maybe several times, that there
is no standardized API for a process (sshd) to find the cwd of one of
it's child processes (your shell) - and of course even if OpenSSH did
that, it is still no general solution, because other SSH servers may
not be able to do it.

I suggest that you create a subsystem which enumerates every other
channel the invoking user currently has opened in sshd, and looks
up their cwd.

(SSH subsystems speak a protocol which you define on stdio.)

You can make this an @openssh.com subsystem and if implemented
within sshd it would work fabulously, but that is *still* no
general solution.

A general solution needs to work regardless of which sshd is being
used. That constraint means that python is just as good a tool as any
other for creating the solution.

I say a general solution is not possible.

You can prove me wrong by sending patches with new python files which
do it.


//Peter


More information about the openssh-unix-dev mailing list