No disconnect handler when using exec_request about russh HOT 5 CLOSED

Hah. how did I not think of that.
Yes, implementing drop does trigger when the client disconnects.

Thanks a bunch! :D

from russh.

You're experiencing the difference between having a TTY and not. When a TTY is allocated, the SSH client will send the keystrokes immediately and supply additional information such as terminal size.

With OpenSSH, ssh <host> defaults to having a allocating PTY when the client itself running in a terminal, and ssh <host> <command> defaults to working without one. You can override both:

• ssh -T <host> - shell without a TTY
• ssh -t <host> <command> - exec with a TTY

from russh.

P.S. ctrl-c will send a signal instead when no PTY is allocated

from russh.

Thanks for the quick response! :)

I am logging signals using

fn signal(self, channel: ChannelId, signal_name: russh::Sig, session: Session) -> Self::FutureUnit {
    info!("Signal: {} {:?}", channel, signal_name);
    self.finished(session)
}

but nothing is coming in, the ssh client just drops back to shell..

Unfortunately because of current (already running) client implementations I can't add a -t to the client requests.

I'm working on re-writing my personal proxy server from typescript to rust, so I can't change how to the clients interacts with the server.

I would at the very least expect a channel_close when a client disconnects, since a channel is opened via channel_open_session, Or am I misunderstanding how this should work?

from russh.

It's possible that your client just kills the connection without sending a signal or a channel_close message - in this case you can implement Drop for your handler - russh will drop it when the connection ends.

from russh.