exit-status message handling

[ter...@gmail.com]

Hi Ron,

I have server that when connected writes some data to the client and closes connection.

When I connect to that server from another host through asyncssh using direct TCP connection I see (when debug logging is enabled) that just before channel close it logs
"Received unknown channel request: exit-status" . As I understand RFC4254 this is not obligatory message and doesn't require replay from the client. At the same time it looks useful for the client to be able process this message if available. I guess to process this I need to extend SSHChannel somehow but I could not find a way to tell asyncssh to use my custom version except monkeypatching the channel returned by create_connection(...). What would be the proper way of handling such a message?

Regards,

Mikhail

[Ron Frederick]

Hi Mikhail,

On Feb 5, 2021, at 11:38 AM, ter...@gmail.com <ter...@gmail.com> wrote:
> I have server that when connected writes some data to the client and closes connection.
>
> When I connect to that server from another host through asyncssh using direct TCP connection I see (when debug logging is enabled) that just before channel close it logs "Received unknown channel request: exit-status" . As I understand RFC4254 this is not obligatory message and doesn't require replay from the client. At the same time it looks useful for the client to be able process this message if available. I guess to process this I need to extend SSHChannel somehow but I could not find a way to tell asyncssh to use my custom version except monkeypatching the channel returned by create_connection(...). What would be the proper way of handling such a message?

Are you saying that you are seeing an SSH server send an “exit-status” message on a direct-tcpip connection? If so, what server was this? I’ve never see that before in my own testing.

Looking at RFC 4254, it talks about how this message can be sent “when the command running at the other end terminates”. To me, that implies that it should only be applicable to “shell”, “exec”, or possibly “subsystem” channels, not direct-tcpip or forwarded-tcpip channels. So, in AsyncSSH, the handling of exit-status is only present on the SSHClientChannel class and sent by calling exit() on an SSHServerChannel, but not handled or generated from an SSHForwardChannel.
--
Ron Frederick
ro...@timeheart.net

[Mikhail Terekhov]

On 2021-02-05 23:07, Ron Frederick wrote:
> On Feb 5, 2021, at 11:38 AM, ter...@gmail.com <ter...@gmail.com> wrote:
>> I have server that when connected writes some data to the client and closes connection.
>>
>> When I connect to that server from another host through asyncssh using direct TCP connection I see (when debug logging is enabled) that just before channel close it logs "Received unknown channel request: exit-status" . As I understand RFC4254 this is not obligatory message and doesn't require replay from the client. At the same time it looks useful for the client to be able process this message if available. I guess to process this I need to extend SSHChannel somehow but I could not find a way to tell asyncssh to use my custom version except monkeypatching the channel returned by create_connection(...). What would be the proper way of handling such a message?
> Are you saying that you are seeing an SSH server send an “exit-status” message on a direct-tcpip connection? If so, what server was this? I’ve never see that before in my own testing.

It is freeSSHd from http://www.freesshd.com/. It is pretty ancient and
not supported anymore.

> Looking at RFC 4254, it talks about how this message can be sent “when the command running at the other end terminates”. To me, that implies that it should only be applicable to “shell”, “exec”, or possibly “subsystem” channels, not direct-tcpip or forwarded-tcpip channels. So, in AsyncSSH, the handling of exit-status is only present on the SSHClientChannel class and sent by calling exit() on an SSHServerChannel, but not handled or generated from an SSHForwardChannel.

Yes, I've read it this way as well, but thought initially it could
convey some additional information in case of direct connection as well.
Do you think it is just an oversight on the freeSSHd side and could be
safely ignored?

[Ron Frederick]

On Feb 6, 2021, at 8:46 AM, Mikhail Terekhov <ter...@gmail.com> wrote:
> On 2021-02-05 23:07, Ron Frederick wrote:
>> On Feb 5, 2021, at 11:38 AM, ter...@gmail.com <ter...@gmail.com> wrote:
>>> I have server that when connected writes some data to the client and closes connection.
>>>
>>> When I connect to that server from another host through asyncssh using direct TCP connection I see (when debug logging is enabled) that just before channel close it logs "Received unknown channel request: exit-status" . As I understand RFC4254 this is not obligatory message and doesn't require replay from the client. At the same time it looks useful for the client to be able process this message if available. I guess to process this I need to extend SSHChannel somehow but I could not find a way to tell asyncssh to use my custom version except monkeypatching the channel returned by create_connection(...). What would be the proper way of handling such a message?
>> Are you saying that you are seeing an SSH server send an “exit-status” message on a direct-tcpip connection? If so, what server was this? I’ve never see that before in my own testing.
>
> It is freeSSHd from http://www.freesshd.com/. It is pretty ancient and not supported anymore.

Unfortunately, it looks like source code for freeSSHd is only available if you purchase a commercial license, so it’s hard to know if the exit-status it sends on a direct-tcpip channel ever returns any additional information, but I would be surprised if it did.

>> Looking at RFC 4254, it talks about how this message can be sent “when the command running at the other end terminates”. To me, that implies that it should only be applicable to “shell”, “exec”, or possibly “subsystem” channels, not direct-tcpip or forwarded-tcpip channels. So, in AsyncSSH, the handling of exit-status is only present on the SSHClientChannel class and sent by calling exit() on an SSHServerChannel, but not handled or generated from an SSHForwardChannel.
>
> Yes, I've read it this way as well, but thought initially it could
> convey some additional information in case of direct connection as well.
> Do you think it is just an oversight on the freeSSHd side and could be
> safely ignored?

Yes - I think you can safely ignore it. Sending exit-status still requires that a separate close message be sent immediately after it. So, as long as it still sends the close, there should be no problem interoperating with AsyncSSH (or other SSH clients). On the AsyncSSH side, there should be no consequence of it other than the log message, and as you noted even that only shows up if you enable debug logging.
--
Ron Frederick
ro...@timeheart.net

[Mikhail Terekhov]

Thank you very much for clarification!