Another SSH client on Windows

[Cal Leeming [Simplicity Media Ltd]]

On Mon, Dec 10, 2012 at 11:33 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming at simplicitymedialtd.co.uk> wrote:

> Peter, can you reply off-list, thanks.
>
> Cal
>
> On Mon, Dec 10, 2012 at 3:37 AM, Peter Stuge <peter at stuge.se> wrote:
>
>> 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.
>>
>
> Please provide an example of how this would be "wildly inappropriate"
>
>
>>
>>
>> > > 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.
>>
>
> Duh.
>
>
>>
>>
>> > 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.
>>
>
> Sure, let me just put this on my list of 9834955 todo items to look at
> sometime in the future ;)
>

Sorry, I forgot to say thank you for your in-depth breakdown on this, gives
some food for thoughts!


>
>
>>
>>
>> //Peter
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>
>