Re: Incorrect protocol implementation by OpenSSH?

On Sat, 29 Sep 2007 00:33:08 +0100, Simon Tatham wrote:

H.K. Kingston-Smith <HKK-S@xxxxxxxxx> wrote:
Fair enough. The question still remains: What is a server supposed to
do when receiving an SSH_MSG_CHANNEL_REQUEST containing a request that
it can't honor, when the request has the want-reply field set to 0?

Nothing. If it can honour the request, it should do so and send no
packet back; otherwise, it should do nothing and send no packet back.

Is it not the case that if the server does not send some SSH packet
back the conversation will be deadlocked?

Not in general. Consider non-essential CHANNEL_REQUESTs such as
"pty-req" or "x11-req". The session can still proceed in the absence of
those, and if they're refused then there's not much the client can do
about it anyway, so a client might perfectly well decide not to bother
finding out whether they worked or not; it just requests them, and the
user either ends up with them enabled or not. In this situation there's
no reason why the session should be deadlocked if one of those requests
isn't granted.

That makes sense.

The "exec" request is a less obviously useful one to set want_reply=0
on, admittedly. But if the client chooses to discard enough error data
that it can't work out that it's in a deadlock situation, that's its own
fault, and it's not the server's job to second-guess it.

I am not sure I entirely agree with that. If the client specifies
want-reply = 0 and the server does not support "exec", how can the client
know the reason behind the deadlock?

It would seem that an "exec" (or "shell") request with want-reply
set to 0 sent to a server that does not support such a capability will
necessarily lead to a deadlock. Is this right in general? It most
certainly is when dealing with OpenSSH clients.





.

Relevant Pages

  • Re: Incorrect protocol implementation by OpenSSH?
    ... request that it can't honor, when the request has the want-reply field ... packet back; otherwise, it should do nothing and send no packet ... so a client might perfectly well decide not ... enough error data that it can't work out that it's in a deadlock ...
    (comp.security.ssh)
  • Re: breaking the model
    ... > The forms data then is in the Request object. ... HTTP Request; in this case, the form POST Request from the Page. ... client and server. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Resolving record with enumerated type
    ... In a CPU BFM package, ... because data goes in two directions (request from the ... from the server to the client), you'll need some way to orchestrate ...
    (comp.lang.vhdl)
  • Re: WSE 3.0 + UserNameToken without X.509 Cert/Kerberos + Signing + Encryption How?
    ... I still think that there is a lot of benefit for Secure Conversation ... message security and thefore it does not encrypt the message. ... between client and server using a UserNameToken that passes the UserName ... assuming the client request adds a proper UserNameToken... ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Performance Issue with Runtime Image
    ... >> the client, closes the connection, then dies. ... request before even accepting the next incoming connection. ... The client program is unaffected so presumably the server is ...
    (comp.lang.smalltalk.dolphin)