Sending env variables causes a proprietary SSH/SFTP server to drop the session [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
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.
ssh environment-variables sftp
asked Feb 1 at 14:04
Junaid Shahid
343
closed as too broad by muru, mdpc, Archemar, thrig, G-Man Feb 3 at 20:03
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
0
down vote
favorite
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.
ssh environment-variables sftp
asked Feb 1 at 14:04
Junaid Shahid
343
closed as too broad by muru, mdpc, Archemar, thrig, G-Man Feb 3 at 20:03
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
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 at 14:19
Well, the session is closed by the remote host (updating the question with relevant logs)
– Junaid Shahid
Feb 1 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 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 at 14:19
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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.
ssh environment-variables sftp
asked Feb 1 at 14:04
Junaid Shahid
343
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.
ssh environment-variables sftp
asked Feb 1 at 14:04
Junaid Shahid
343
edited Feb 1 at 14:40
asked Feb 1 at 14:04
Junaid Shahid
343
asked Feb 1 at 14:04
Junaid Shahid
343
asked Feb 1 at 14:04
Junaid Shahid
343
343
closed as too broad by muru, mdpc, Archemar, thrig, G-Man Feb 3 at 20:03
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as too broad by muru, mdpc, Archemar, thrig, G-Man Feb 3 at 20:03
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
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 at 14:19
Well, the session is closed by the remote host (updating the question with relevant logs)
– Junaid Shahid
Feb 1 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 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 at 14:19
add a comment |Â
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 at 14:19
Well, the session is closed by the remote host (updating the question with relevant logs)
– Junaid Shahid
Feb 1 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 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 at 14:19
2
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 at 14:19
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 at 14:19
Well, the session is closed by the remote host (updating the question with relevant logs)
– Junaid Shahid
Feb 1 at 14:37
Well, the session is closed by the remote host (updating the question with relevant logs)
– Junaid Shahid
Feb 1 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 at 15:29
"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 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 at 14:19
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 at 14:19
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
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.
answered Feb 3 at 14:35
telcoM
10.8k11132
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
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.
answered Feb 3 at 14:35
telcoM
10.8k11132
add a comment |Â
up vote
2
down vote
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.
answered Feb 3 at 14:35
telcoM
10.8k11132
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
answered Feb 3 at 14:35
telcoM
10.8k11132
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.
answered Feb 3 at 14:35
telcoM
10.8k11132
answered Feb 3 at 14:35
telcoM
10.8k11132
answered Feb 3 at 14:35
telcoM
10.8k11132
answered Feb 3 at 14:35
telcoM
10.8k11132
10.8k11132
add a comment |Â
add a comment |Â
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 at 14:19
Well, the session is closed by the remote host (updating the question with relevant logs)
– Junaid Shahid
Feb 1 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 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 at 14:19