Is it possible that a server that doesn't anticipate/ does not support environment variables from clients, terminate such sessions upon noticing the client sending such variables?

I have captured debug level logs for the sftp client, everything goes fine until the very end i.e successful authentication, request for sftp subsystem. At this stage, when client sends env variables, the server closes the session.

Another sftp client, runs to completion of the session, as that one is not sending any env data.

I am aware of AcceptEnv, SendENv features in openssh s/w, but is this behavior warranted on behalf of the proprietary sftp/ssh server (to drop a session from a client that tries to send env data)?

debug1: channel request 0: subsystem
debug2: callback done
debug1: channel 0: open confirm rwindow 32000 rmax 35000
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 client-session (t4 r43 i0/0 o0/0 fd 6/7)

debug3: channel_close_fds: channel 0: r 6 w 7 e 8
debug1: fd 0 clearing O_NONBLOCK
debug2: fd 1 is not O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Connection to xyz.com closed by remote host.
  • 2
    Everything is possible. - Server should not close the session, but it can reject the variables. - Are you sure that it's the server that is closing the connection? Cannot it be the client incorrectly handling the reject? – Martin Prikryl Feb 1 '18 at 14:19
  • Well, the session is closed by the remote host (updating the question with relevant logs) – Junaid Shahid Feb 1 '18 at 14:37
  • "is this behavior warranted on behalf of the proprietary sftp/ssh server" .. How can we know without knowing what spec was used to develop that server? – muru Feb 1 '18 at 15:29
  • Well, the client logs indicate that the baseline ssh compatibility is SSH2, so this is what is agreed upon by both parties. I was wondering if there was any provision at the proto level for such a behavior. and all.. – Junaid Shahid Feb 2 '18 at 14:19

Closing the connection is clearly an excessive reaction, unless the server administrator can specifically configure what should happen when such a request is made. I would expect it to be treated like any other SSH2 protocol options: if the server either does not allow or does not understand the options requested by the client, the server should ignore those options and proceed with the things it can accept.

There is a precedent of sorts: when new encryption algorithms were added to OpenSSH, some firmware implementations of SSH (in ILOM/iLO/iRMC etc. remote administration hardware etc.) had not allocated a buffer big enough for the client's list of encryption methods, and failed to establish a connection unless the number of negotiable encryption methods was shortened by client-side configuration. This was without question treated as a bug, and was fixed whenever possible in subsequent firmware versions.

I'd recommend making a bug report to the vendor of the proprietary SSH server.

| improve this answer | |
  • can not solve this? – 244boy May 24 '19 at 8:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.