Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: KexAlgorithms accepts gss-* algorithms, if not the only algorithm but it is absolutely unclear what this setting does. Apparently it does nothing at all? At least there is no difference noticeable at first in basic usage. Version-Release number of selected component (if applicable): 9.0p1-17.fc38 How reproducible: always Steps to Reproduce: 1. sudo sshd -T # see defaut settings 2. sudo sshd -T -oGSSAPIKexAlgorithms=gss-curve25519-sha256- # seems to have an effect that makes sense 3. sudo sshd -T -oKexAlgorithms=gss-curve25519-sha256- # kex_algorithms: invalid argument 4. sudo sshd -T -oKexAlgorithms=curve25519-sha256,gss-curve25519-sha256- # seems to silently ignore gss-* option? 5. sudo sshd -T -oKexAlgorithms=curve25519-sha256 # seems to have an effect that makes sense Actual results: It is not documented (e.g. not shown in ssh -Q KexAlgorithms and not mentioned in the manpage) that one can add gss-* algorithms to KexAlgorithms directive or what affect it has to add them there. It is unclear whether one should add them to GSSAPIKexAlgorithms or both to enable them. Likewise it is unclear, what must be done to limit the set of GSSAPI key exchange algorithms for example to gss-curve25519-sha256-. Expected results: It is clear, why there are two distinct options to configure KexAlgorithms and when to use which with which options. Additional info: I am filing this bug here, as it must be related to a patch done in Fedora: https://src.fedoraproject.org/rpms/openssh/blob/f38/f/openssh-8.0p1-gssapi-keyex.patch There is no code for the relevant options upstream in OpenSSH.
NOTE: non-GSSAPI algorithms like curve25519-sha256 are not valid in GSSAPIKexAlgorithms: Unsupported KEX algorithm "curve25519-sha256"
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
I can still reproduce this in OpenSSH version 9.6p1-1.fc40.2 in Fedora Linux 40.
The algorithms are relevant when GSS Key exchange is in use. The patch you mention implements RFC8732 and RFC4462. Fedora implements this support as downstream patch you refer to. If you don't use Kerberos for authentication, it shouldn't affect you.
Thank you for your explanation. Perhaps to make it more clear: man sshd_config states for the KexAlgorithms directive: The supported algorithms are: curve25519-sha256 curve25519-sha256 diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group14-sha256 diffie-hellman-group16-sha512 diffie-hellman-group18-sha512 diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 sntrup761x25519-sha512 The list of available key exchange algorithms may also be obtained using "ssh -Q KexAlgorithms". ssh -Q KexAlgorithms yields the same list in slightly different order. This to me looks like either the documentation is wrong as gss-curve25519-sha256- is accepted as well or the patch contains a bug, that it accepts algorithms for this directive, that should not be allowed.
I agree hat it's a documentation issue. Would you mind submitting a patch?
Ok, then to question to me would be what intended effect it shall have to add the gss-* algorithms to the "normal" KexAlgorithms directive. I would be happy to contribute a patch, but as of now I do not know what should be written in the documentation as what it really does. Just extending the list in the man page and the ssh -Q output does not seem right to me, as they are not valid as a standalone option and I don't understand the inner workings good enough on how these are linked.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
These algorithms are managed by a separate configuration option GSSAPIKexAlgorithms. They are proposed by client has GSSAPIKeyExchange option on.
For sure the gss-* algorithms only work properly, if the GSSAPI key exchange is allowed. Nevertheless, these algorithms seem to have some effect also when GSSAPI key exchange is not allowed. As far as I can tell, RFC 8732 and RFC 4462 don't specify how the GSSAPI algorithms specified in GSSAPIKexAlgorithms relate to KexAlgorithms. My point is that KexAlgorithms irrespective of other settings (also irrespective of GSSAPIKeyExchange and GSSAPIKexAlgorithms) sometimes accepts gss-* arguments, even though there are not listed as valid options in the man page or output of ssh -Q KexAlgorithms. It is still not fully clear to me, what they do in KexAlgorithms and I don't want to document it wrong. If the gss-* algorithms are only managed by the GSSAPIKexAlgorithms option and not the KexAlgorithms option, why are they accepted in KexAlgorithms sometimes anyway?
> If the gss-* algorithms are only managed by the GSSAPIKexAlgorithms option and not the KexAlgorithms option, why are they accepted in KexAlgorithms sometimes anyway? The gss-* algorithms are managed only by GSSAPIKexAlgorithms, as Dima already wrote. I think the reason why the are ignored in the list of KexAlgorithms is that they are valid key exchange algorithms for SSH. Under the hood, the logic is that when the client has GSSAPI configured for the given host, it adds these GSSAPIKexAlgorithms to the list of key exchange algorithms and if also the server has some matching, the key exchange continues with the GSSAPI. I introduced this option at the time when we needed some way to control the list of negotiated GSSAPI kex algorithms instead of blindly appending the list of all supported GSSAPI kex algorithms. This works for configuring what gssapi kex algorithms you want, but there might still be some corner cases and bugs that were caused by me, some underlying openssh code changes or rebases over the years. All relevant code should be in the following patch if you want to dig into that deeper: https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/0011-openssh-9.6p1-gssapi-keyex.patch Going back to your questions: > Ok, then to question to me would be what intended effect it shall have to add the gss-* algorithms to the "normal" KexAlgorithms directive. None > Just extending the list in the man page and the ssh -Q output does not seem right to me, as they are not valid as a standalone option and I don't understand the inner workings good enough on how these are linked. We have the GSSAPI kex algorithms under the following query option: ssh -Q kex-gss > man sshd_config states for the KexAlgorithms directive: > > The supported algorithms are: > [...] > ssh -Q KexAlgorithms yields the same list in slightly different order. The order does not matter. Its just list sorted for readability, while the query lists the list as it is in internal tables. The order of preference is completely different (and managed by crypto policies in Fedora anyway). > 4. sudo sshd -T -oKexAlgorithms=curve25519-sha256,gss-curve25519-sha256- # seems to silently ignore gss-* option? I think this specific corner case is caused by the following change in kex_alg_by_name() function: https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/0011-openssh-9.6p1-gssapi-keyex.patch#_1320 which validates the names against both kexalgs and gss_kexalgs lists. I think this is because this function is used somewhere later to validate the names where we need to match both of the lists. The gss- names are likely eventually filtered out from the resulting list, but you can observe this glitch. But clearly, it does not have any effect on SSH function. Hope it clears the confusion a bit. Is it an issue? Likely not. Can this be fixed? Indeed! Am I going to fix it? Likely not. While I appreciate your persistence and interest in the internals, it sounds to me like a non-issue.
Thank you for your explanation, insights and work on Fedora! I know that the ordering is not important. I just specified that for the sake of accuracy/completeness. I totally agree that this has low priority. Would you be open to a patch from me to improve this patch? It would definitely take a longer while as I am not familiar with the OpenSSH code base, no expert in C programming and not yet a Fedora contributor (even though I wanted to for a longer while now), wherefore I am also not familiar with the Fedora processes involved.
To me this now seems like the documentation for GSSAPIKexAlgorithms should be updated to include a hint for ssh -Q kex-gss and the parsing code for KexAlgorithms should be adjusted to not allow any gss-* values anymore.
And ssh -Q GSSAPIKexAlgorithms should be added as as an alias for ssh -Q kex-gss.
Yes, the patches are welcome
Here is the preliminary start of the patch for ssh -Q: diff --git a/ssh.c b/ssh.c index 8d27f6379..86b8e1357 100644 --- a/ssh.c +++ b/ssh.c @@ -847,7 +847,8 @@ main(int ac, char **av) else if (strcmp(optarg, "kex") == 0 || strcasecmp(optarg, "KexAlgorithms") == 0) cp = kex_alg_list('\n'); - else if (strcmp(optarg, "kex-gss") == 0) + else if (strcmp(optarg, "kex-gss") == 0 || + strcasecmp(optarg, "GSSAPIKexAlgorithms") == 0) cp = kex_gss_alg_list('\n'); else if (strcmp(optarg, "key") == 0) cp = sshkey_alg_list(0, 0, 0, '\n'); diff --git a/ssh_config.5 b/ssh_config.5 index 8a4b469cf..908a4fceb 100644 --- a/ssh_config.5 +++ b/ssh_config.5 @@ -1038,6 +1038,9 @@ The default is .Dq gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-, gss-curve25519-sha256-,gss-group14-sha1-,gss-gex-sha1- . This option only applies to connections using GSSAPI. +.Pp +The list of supported key exchange algorithms may also be obtained using +.Qq ssh -Q GSSAPIKexAlgorithms . .It Cm HashKnownHosts Indicates that .Xr ssh 1 diff --git a/sshd_config.5 b/sshd_config.5 index cf3b248ba..9184b16a4 100644 --- a/sshd_config.5 +++ b/sshd_config.5 @@ -784,6 +784,9 @@ The default is .Dq gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-, gss-curve25519-sha256-,gss-group14-sha1-,gss-gex-sha1- . This option only applies to connections using GSSAPI. +.Pp +The list of supported key exchange algorithms may also be obtained using +.Qq ssh -Q GSSAPIKexAlgorithms . .It Cm HostbasedAcceptedAlgorithms Specifies the signature algorithms that will be accepted for hostbased authentication as a list of comma-separated patterns.
As I cannot find any information on how the Fedora patches are generated: How shall I generate/format my patches? When using git diff --patch and git format-patch I can produce only similar patches but not identical ones as in https://src.fedoraproject.org/rpms/openssh/tree/f43 Also as my patch to 0012-openssh-9.6p1-gssapi-keyex.patch breaks e.g. 0030-openssh-8.0p1-crypto-policies.patch and 0053-support-authentication-indicators-in-GSSAPI.patch I have also changed these. Shall I submit a patch that updates all of these Fedora patches accordingly? Or shall I submit individual patches for that? Shall I rather just post complete new versions for the individual Fedora patches? Or shall I just provide a new patch like 0054- that does the suggested changes on top of all existing ones? While this does not require changes in the existing Fedora patches, this would seem like a less clean solution to me.
I don't recall how I used to generate patches for f43, probably manually. For the latest Fedora versions I used a github branch https://github.com/beldmit/openssh-portable/tree/beldmit-f44-102p1 but now I passed the maintenance to my colleague and it's not totally up-to-date. So the ideal solution for me looks like creating a branch based on the current patches, amending them, and reexporting them back. I would skip the unnecessary changes (number of patches, git version, minor line numbers shift etc) and provide only meaning ones.
My patch also fixes two unrelated minor issues in the Fedora crypto-policies patch (0026-openssh-8.0p1-crypto-policies.patch in Fedora Linux 44; 0027-openssh-8.0p1-crypto-policies.patch in Fedora Rawhide): 1. In ssh_config.5 under KexAlgorithms a new paragraph starts in the middle of a sentence. 2. In ssh_config.5 the documentation of PubkeyAcceptedAlgorithms is missing a full stop. Is this ok as I have to edit this file anyway? Or shall I open separate issues for that?
Created attachment 2145254 [details] Proposed Fedora 44 patch to replace current 0011-openssh-9.6p1-gssapi-keyex.patch
Created attachment 2145255 [details] Proposed Fedora 44 patch to replace current 0026-openssh-8.0p1-crypto-policies.patch
Created attachment 2145256 [details] Proposed Fedora 44 patch to replace current 0038-openssh-7.7p1-fips.patch
Created attachment 2145257 [details] Proposed Fedora 44 patch to replace current 0048-support-authentication-indicators-in-GSSAPI.patch
Created attachment 2145258 [details] Proposed Fedora 44 patch to replace current 0049-NIST-curves-hybrid-KEX-implementation.patch
Are the attached patches what you had in mind?
Created attachment 2145264 [details] Proposed Fedora Rawhide patch to replace current 0013-openssh-9.6p1-gssapi-keyex.patch
Created attachment 2145265 [details] Proposed Fedora Rawhide patch to replace current 0027-openssh-8.0p1-crypto-policies.patch
Created attachment 2145266 [details] Proposed Fedora Rawhide patch to replace current 0038-openssh-7.7p1-fips.patch
Created attachment 2145267 [details] Proposed Fedora Rawhide patch to replace current 0047-support-authentication-indicators-in-GSSAPI.patch
Created attachment 2145268 [details] Proposed Fedora Rawhide patch to replace current 0048-NIST-curves-hybrid-KEX-implementation.patch
Thank you very much! I plan to work on it in rawhide in near future.
FEDORA-2026-cb05db1092 (openssh-10.3p1-6.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-cb05db1092
Thanks! Fixes are landing in rawhide
FEDORA-2026-a80275b42d (openssh-10.2p1-12.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-a80275b42d
FEDORA-2026-cb05db1092 (openssh-10.3p1-6.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-a80275b42d has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-a80275b42d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a80275b42d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Sorry, that I must reopen this bug again. I just noticed now that when reducing one of my patches for Rawhide to the minimum changes I actually removed one character too much: In line 104 of the 0027-openssh-8.0p1-crypto-policies.patch there is one @ missing at the start of the line: https://src.fedoraproject.org/rpms/openssh/blob/eba6246f724790c17a895e9c9151cd89caf6c84b/f/0027-openssh-8.0p1-crypto-policies.patch#_104 Since the patch command used in the RPM builds is too lenient when parsing this invalid patch file, it only quietly ignores everything after this error, resulting in a patch that is only partially applied. If possible, you should probably enforce stricter parsing as git apply does as well. I have attached a corrected version of the patch that fixes this mistake. I apologize that this somehow slipped through. With FEDORA-2026-a80275b42d in Fedora 44 everything seems fixed. Thank you!
Created attachment 2148019 [details] Corrected proposed Fedora Rawhide patch to replace current 0027-openssh-8.0p1-crypto-policies.patch
Applied, thanks
FEDORA-2026-5e2df3f862 (openssh-10.3p1-8.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-5e2df3f862
FEDORA-2026-5e2df3f862 (openssh-10.3p1-8.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-a80275b42d (openssh-10.2p1-12.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.