[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Thu Aug 17 18:52:09 AEST 2023


https://bugzilla.mindrot.org/show_bug.cgi?id=3603

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Shreenidhi Shedi from comment #0)
[...]
> When fips is enabled at server end and server has the following
> cipher set,
> 
> ```
> root at phdev:~ $ sshd -T | grep ciphers
> ciphers
> chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,
> aes128-gcm at openssh.com,aes256-gcm at openssh.com

This indicates your FIPS modifications to the server are incorrect.

The server seems to be advertising the chacha20 cipher but seems unable
or unwilling to actually use it.  If it's not going to support them it
should not offer them, and if the server's config explicitly includes
it then it should either refuse to start or remove them and log a
warning.

> root at phdev:~ $ rpm -q openssh
> openssh-9.1p1-10.ph5.x86_64 (this happens with 9.4p1 as well)
> ```
> 
> The handshake with client starts with chacha20-poly1305 and this
> cipher is not fips complaint.
> 
> I'm not sure what the intention was but in this commit:
> https://github.com/openssh/openssh-portable/commit/
> a22b9ef21285e81775732436f7c84a27bd3f71e0
> 
> chacha20 cipher was promoted.

That was the intent, and it's fine.  Simplifying a bit, the way it's
supposed to work is that the client picks the cipher from the list that
the server offers that it likes most.

Your server is lying about what ciphers it supports, and when the
client takes it up on its offer for chacha20, it doesn't work (from
your description, probably the server is aborting, but you'd have to
check your server logs).

Fix your server and it should work fine.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list