You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When transferring data over an SSH channel to an Erang SSH daemon, if the data contains a character 0x03 (end of text character), then the IO read of the data from the SSH channel returns {error, interrupted}. If the character is not present in the string, the string is read and returned correctly.
This was discovered in the context of an SCP file transfer implementation by calling the one-time execution of the SCP command on an Erlang SSH daemon. The file data is read from standard_io, and in the case that the file data contains a 0x03 character, the read was interrupted, and the file transfer failed (the file was a DER format certificate).
To Reproduce
1 - Start an Erlang SSH daemon, following the instructions in the Erlang SSH Getting Started guide: https://www.erlang.org/doc/apps/ssh/using_ssh.html. Do not disable one-time execution, or assign a function to handle it (so that it defaults to using the erlang shell)
2 - Set up SSH keys to allow ssh connection without password.
3 - From a file, read some text with the character 0x03 in it.
4 - Pipe this text into a one-time execution ssh command to read a user input using the standard IO.
Expected behavior
I believe that the character 0x03 should not interrupt an IO read of the data from the SSH channel, as I don't know how a file with this character can be transferred through an SSH connection.
The SSH debug on the server side for these two commands shows that the character is delivered correctly on the server side:
This is from the information printed to the erlang shell after executing the functions ssh_dbg:on() and ssh_dbg.start()
The assumption is that this is related to the pseudoterminal that is used for SSH connections, as the character 0x03 (^C) is a breaking interrupt in a terminal, but I haven't been able to prove this.
The text was updated successfully, but these errors were encountered:
Hi,
I don't quite follow. What do you mean with "calling the one-time execution of the SCP command on an Erlang SSH daemon"?
Did you call "scp -P PORT ... HOST ..." where HOST:PORT is served by an Erlang SSH daemon?
The Erlang SSH daemon does not support the scp command of OpenSSH.
To transfer a file an sftp operation is to prefer. In that case there is no problem with the ^C character since a file is read at the server and sent to the client without any interpretations of the contents.
When using the exec functionality - like in the examples above - the server is instructed to execute a command in the server's shell as similar as possible to opening a shell directly to the server without any ssh involved. Since the input to the shell contains a ^C (character 0x03), the shell is instructed to stop the execution and close down everything.
Describe the bug
When transferring data over an SSH channel to an Erang SSH daemon, if the data contains a character 0x03 (end of text character), then the IO read of the data from the SSH channel returns {error, interrupted}. If the character is not present in the string, the string is read and returned correctly.
This was discovered in the context of an SCP file transfer implementation by calling the one-time execution of the SCP command on an Erlang SSH daemon. The file data is read from standard_io, and in the case that the file data contains a 0x03 character, the read was interrupted, and the file transfer failed (the file was a DER format certificate).
To Reproduce
1 - Start an Erlang SSH daemon, following the instructions in the Erlang SSH Getting Started guide: https://www.erlang.org/doc/apps/ssh/using_ssh.html. Do not disable one-time execution, or assign a function to handle it (so that it defaults to using the erlang shell)
2 - Set up SSH keys to allow ssh connection without password.
3 - From a file, read some text with the character 0x03 in it.
4 - Pipe this text into a one-time execution ssh command to read a user input using the standard IO.
The code for starting the SSH daemon:
And for running the single execution in a console, with and with the 0x03 character:
Expected behavior
I believe that the character 0x03 should not interrupt an IO read of the data from the SSH channel, as I don't know how a file with this character can be transferred through an SSH connection.
Affected versions
OTP Version: Erlang/OTP 24
Additional context
Operating system: Ubuntu 18.04.3 LTS
The SSH debug on the server side for these two commands shows that the character is delivered correctly on the server side:
This is from the information printed to the erlang shell after executing the functions
ssh_dbg:on()
andssh_dbg.start()
First example (text1=hello.):
Second example (text2=hel�lo.):
The assumption is that this is related to the pseudoterminal that is used for SSH connections, as the character 0x03 (^C) is a breaking interrupt in a terminal, but I haven't been able to prove this.
The text was updated successfully, but these errors were encountered: