otp
otp copied to clipboard
SSH CLI command echoed twice with OTP 26
Describe the bug On an SSH CLI, the command entered is echoed twice. Occurs on 3 different shells. Did not occur in OTP 24.
To Reproduce
- Start an SSH server in OTP 26.2.5 with Elixir 1.16.3, pointing to your own SSH keys. Here is the one I ran.
defmodule SshCliIssue do
def start(port) do
:ssh.start()
pwdfun = fn _, _, _, _ -> true end
:ssh.daemon(port, [
{:system_dir, ~c"./"},
{:user_dir, ~c"./"},
{:pwdfun, pwdfun}
])
end
end
- Start the server on a port.
iex(2)> SshCliIssue.start 7022
{:ok, #PID<0.5326.0>}
iex(3)>
- Connect to the server, logging in with any user and password combination (root/root, for example)
- Enter any command, such as hello.
- Observe the command being echoed twice on OTP 26, but not when done in OTP 24 OTP 26.2.5
user@ubuntu22:~$ ssh [email protected] -p 7022
SSH server
Enter password for "root"
([email protected]) password:
Eshell V14.2.5.9 (press Ctrl+G to abort, type help(). for help)
1> helloworld.
1> helloworld.
helloworld
2> helloworld1.
2> helloworld1.
helloworld1
3> helloworld2.
3> helloworld2.
helloworld2
4> helloworld3.
4> helloworld3.
helloworld3
5>
OTP 24.1.3
user@ubuntu22:~$ ssh [email protected] -p 7022
SSH server
Enter password for "root"
([email protected]) password:
Eshell V12.1.3 (abort with ^G)
1> helloworld.
helloworld
2> helloworld1.
helloworld1
3> helloworld2.
helloworld2
4> helloworld3.
helloworld3
5> helloworld4.
helloworld4
6> helloworld5.
helloworld5
7> helloworld6.
helloworld6
8> Connection to 192.168.1.31 closed by remote host.
Connection to 192.168.1.31 closed.
user@ubuntu22:~$
Expected behavior I expect the command to only be echoed once, as it was with OTP 24.
Affected versions OTP 26.2.5 (with Elixir 1.16.3)
Additional context This happens on both Windows clients and Linux clients. The 3 I tried were Putty and Teraterm on Windows, and the standard terminal on Ubuntu 22.
I have attached a zip of screenshots to also show the issue.
can you try more recent OTP-26 version? preferably the latest - is the issue present with OTP 26.2.5.12 ?
I can confirm this issue is still present in OTP 26.2.5.12.
strange. I failed to reproduce it on OTP-26.2.5 with Erlang sample code, similar to yours. can you try without Elixir?
I have reproduced it in erlang only with this.
user@ubuntu22:~/src/ssh_cli_issue$ erl
Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:6:6] [ds:6:6:10] [async-threads:1] [jit:ns]
Eshell V14.2.5 (press Ctrl+G to abort, type help(). for help)
1> ssh:start().
ok
2> Pwdfun = fun (_, _, _, _) -> true end.
#Fun<erl_eval.39.105768164>
3> ssh:daemon(7022, [{system_dir, "./"}, {user_dir, "./"}, {pwdfun, Pwdfun}]).
{ok,<0.101.0>}
4>
While I was at it, I also tested with https://github.com/erlang/otp/releases/tag/OTP-27.3.4 (the latest at time of writing), and the issue is present there too. Again, with erlang only.
For quicker reproduction, I have found opening a new terminal to connect via SSH the quickest way. Reconnecting on an already open terminal/putty session often does not reproduce the issue (tera term application seems to exit on a closed connection, so not applicable here).
Some further analysis.
- OTP-26.0: does not contain the issue, but does have a multiline issue (https://github.com/erlang/otp/issues/7318) which was fixed by https://github.com/erlang/otp/pull/7242
- OTP-26.0.1: Same as OTP-26.0, no change with regard to the issue.
- OTP-26.0.2: Fixes the multiline issue (https://github.com/erlang/otp/issues/7318) with https://github.com/erlang/otp/pull/7242 but introduces a new line to the prompt after entering a command.
user@ubuntu22:~$ ssh [email protected] -p 7022
SSH server
Enter password for "root"
([email protected]) password:
Eshell V14.0.2 (press Ctrl+G to abort, type help(). for help)
1> helloworld.
helloworld
2> helloworld1.
helloworld1
3> helloworld2.
helloworld2
4>
- OTP-26.1: is where the full issue I described above initiates. ** Update ** it appears to start from this commit, particularly the group.erl file: https://github.com/erlang/otp/commit/71b06336c8be3b3ed5110151ecb2a4667db3104e
I have reproduced it, and will try to make a fix for it, it seems to happen only when you have 2 rows of empty space below the prompt in the terminal