Open zhanglc opened 1 year ago
Based on https://serverfault.com/questions/994646/ssh-on-windows-corrupted-mac-on-input, run: ssh -Q mac
then add -m <one of the macs from the output of ssh-Q mac>
to the ssh -vvv root@x.x.x.x
command
Client and Server had negotiated the mac algorithm, So the way you say it is not feasible @tgauth
debug1: kex: server->client cipher: aes128-ctr MAC: umac-128-etm@openssh.com compression: none debug1: kex: client->server cipher: aes128-ctr MAC: umac-128-etm@openssh.com compression: none
Could you still try the -m option explicitly? The error message is the same as in the link above, and that was the solution.
hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com are also listed in sshd_algorithms.conf
, could you remove umac-128-etm@openssh.com and see if one of the other MACs works?
Also, have you tried updating the server from OpenSSH 8.4 to a more current version? Or have you seen this issue with any other SSH clients aside from Windows OpenSSH 9.2?
@tgauth It works when use ssh -m hmac-sha2-256-etm@openssh.com xxx@x.x.x.x
, thanks a lot .
By the way , why the algo umac-128-etm@openssh.com not work ? different implament between OpenSSH 8.4
and OpenSSH_for_Windows_9.2p1
?
Great!
It seems like this might be related to the crypto libraries used with each OpenSSH and their implementations of umac-128-etm@openssh.com - see https://github.com/PowerShell/Win32-OpenSSH/issues/1359. Do you know if the server has FIPS enabled?
I have installed the latest version OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 and issue is still there when below macs are used.
umac-128-etm@openssh.com umac-128@openssh.com
To workaround, I have added the below to my %USERPROFILE%/.ssh/config file
Host * MACs=hmac-sha2-256,hmac-sha2-512,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
or use the below command line option wen invoking ssh
ssh -oMACs=hmac-sha2-256,hmac-sha2-512,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com username@server.com
This has resolved the issue. Same works fine from putty, mac, Red Hat Linux 8 and 7 without any issues, so issue seems to be with Windows OpenSSH client. Hopefully it gets fixed eventually so no workaround is needed.
We believe that the issue is coming from LibreSSL, specifically: https://github.com/libressl/portable/issues/603. We will see if we can get any traction on the thread.
Thanks for the update. Hopefully libressl version for windows can be fixed. I noticed this issue when i disabled chacha20-poly1305@openssh.com encryption algorithm on linux 8.9 server and windows / linux decided to use umac-128-etm@openssh.com to mitigate terrapin attack.
I have experienced the same issue as @ket000 .
_Corrupted MAC on input. ssh_dispatch_runfatal: Connection to XXX.XXX.XXX.XXX port 22: message authentication code incorrect
Version: OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
Workaround: ssh -m hmac-sha2-512 user@host
Reporting the same issue. _Corrupted MAC on input. _ssh_dispatch_run_fatal: Connection to * port 22: message authentication code incorrect__
ssh -V on client: OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2 server: OpenSSH_8.0p1, OpenSSL 1.1.1k FIPS 25 Mar 2021
@ket000 solution worked for me
It seems to be confirmed now that the MAC algorithms umac-128-etm@openssh.com
and umac-128@openssh.com
are not working at the moment. Instead of relying on user configuration to work around the issue, would it make sense to push a new release that completely disables these algorithms?
having the same issue here on Oracle Linux 8 with openssh-server-8.0p1-19.el8_9.2.x86_64 (latest package available)
"Corrupted MAC on input" with putty but fine with the ssh from windows cmd
logs: Corrupted MAC on input. [preauth] ssh_dispatch_run_fatal: Connection from 1.2.3.4 port 12345: message authentication code incorrect [preauth]
i downgraded openssh-server to openssh-server-8.0p1-19.el8_8.x86_64 (dnf downgrade openssh-server)
then it works
This is a known issue since Redhat updated the openssh-server to newer version to resolve the terrapin vulnerability. The same is true for oracle linux 8. Oracle has pulled the offending version from their repo today Feb 5th 2024.
To resolve the issue, sudo dnf downgrade openssh-server sudo dnf clean all
Last command will make sure package cache is clean and no longer install the offending version. Reference links
https://github.com/oracle/oracle-linux/issues/125 https://access.redhat.com/security/cve/cve-2023-48795?cmdf=CVE-2023-48795+redhat
Version that causes the issue : openssh-server-8.0p1-19.el8_9.2.x86_64 which makes below cipher not to work including putty 0.80 and other ubuntu servers
chacha20-poly1305@openssh.com aes128-ctr aes192-ctr aes256-ctr
When you downgrade, all 3 packages will be updated to lower version : 8.0p1-19.el8_9.2 openssh openssh-clients openssh-server
Error is still there. No newer Version than v9.5.0.0p1-Beta (LibreSSL 3.8.2)
And Windows Server 2022 is affected "Feature OpenSSH" (OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2)
We need a bugfixed version.
Having a similar issue with sftp and wondering what the command option would be to get past this.
example:
ssh -Q mac hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 hmac-md5 hmac-md5-96 umac-64@openssh.com umac-128@openssh.com hmac-sha1-etm@openssh.com hmac-sha1-96-etm@openssh.com hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com hmac-md5-etm@openssh.com hmac-md5-96-etm@openssh.com umac-64-etm@openssh.com umac-128-etm@openssh.com
sftp -m hmac-sha2-256 user@ftp.customer.com unknown option -- m usage: sftp [-46aCfpqrv] [-B buffer_size] [-b batchfile] [-c cipher] [-D sftp_server_path] [-F ssh_config] [-i identity_file] [-J destination] [-l limit] [-o ssh_option] [-P port] [-R num_requests] [-S program] [-s subsystem | sftp_server] destination
@eskov-comsearch - since -m
is a ssh_option, the syntax for sftp would be:
sftp -o MACS=hmac-sha2-256 user@ftp.customer.com
@tgauth - thank you for your response. I tried that just now and I am still getting the same error:
sftp -o MACS=hmac-sha2-256 user@sftp.customer.com
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 8.9.97.35 port 22: message authentication code incorrect
Connection closed.
Connection closed
I also tried a few others above. Only 1 gave a different response:
sftp -o MACS=hmac-sha1-96 user@sftp.customer.com Unable to negotiate with x.y.z.w port 22: no matching MAC found. Their offer: hmac-sha2-512-etm@openssh.com,hmac-sha2-512,hmac-sha2-256-etm@openssh.com,hmac-sha2-256,hmac-sha1-etm@openssh.com,hmac-sha1 Connection closed Connection closed.
Suggestions?
When I look at this file, sudo nano /etc/ssh/ssh_config it is empty except for an include statement of a non existant file.
@eskov-comsearch, have you tried all the MACs offered by the server - hmac-sha2-512-etm@openssh.com,hmac-sha2-512,hmac-sha2-256-etm@openssh.com,hmac-sha2-256,hmac-sha1-etm@openssh.com,hmac-sha1
If none of the other MACs offered by the server work, suggest looking at the other workarounds above.
yes, I have tried all of those.
I have also reached out to my counterpart at the customer to see if they can resolve it from their end.
@tgauth , thank you for your help. My customer partner sent me this to try, which allowed me to log in: sftp -c aes256-gcm@openssh.com and I was able to incorporate that into our overall process. They had recently updated.
Prerequisites
Steps to reproduce
sshd_config:
sshd_algorithms.conf
ssh output:
Expected behavior
Actual behavior
Error details
No response
Environment data
Version
OpenSSH_for_Windows_9.2p1, LibreSSL 3.7.2
Visuals
No response