Created attachment 3626 [details] Proof of Concept Hi there, On default Fedora 37 installation I found an interesting issue. In my home directory I have the following config: Host redhat HostName 192.16.122.253 User mto #Identityfile /home/mto/.ssh/id_ed25519 ProxyCommand ssh -T -i /home/mto/.ssh/id_ed25519 mto@192.168.122.253 When I'm trying to connect, I receive the following message: -bash: line 1: $'SSH-2.0-OpenSSH_8.8\r': command not found As you can see, OpenSSH tries to execute banner version as command. Based on the StackOverflow (link: https://unix.stackexchange.com/questions/269024/change-ssh-banner-which-is-grabbed-by-netcat) we can modify banner and it has to be exactly 11 characters long, otherwise the binary gets corrupted. Please refer to provided screenshot for proof. Thanks, Mateusz
(In reply to Mateusz from comment #0) [...] > As you can see, OpenSSH tries to execute banner version as command. That's because that's what you configured it to do, although it's not immediately obvious. What's happening is that the proxy command is bringing up an interactive session, then the client tries to initiate an SSH connection with the proxycommand which is connected to a shell at the other end. The client's initial banner is sent over the proxycommand to the that shell which tries to run it, fails, and returns the error that you see. If we strip your example down to the proxycommand you can see this: $ ssh -o 'ProxyCommand ssh -vvv 127.0.0.1' 127.0.01 [...] debug2: shell request accepted on channel 0 debug2: channel 0: rcvd ext data 59 -bash: line 1: $'SSH-2.0-OpenSSH_9.0\r': command not found debug2: channel 0: written 59 to efd 6 It's not clear what exactly you're trying to do, but you probably want to add a "-W [host]:[port]" to the proxycommand (or use ProxyJump). > Based on the StackOverflow (link: > https://unix.stackexchange.com/questions/269024/change-ssh-banner- > which-is-grabbed-by-netcat) we can modify banner That's different because it's referring to the banner string sent by the server side. In your case the string is sent by the client.
We believe this is not actually a bug in OpenSSH. If you have more details that indicate otherwise, please reopen this bug.
OpenSSH 9.3 has been released. Close resolved bugs