forked from openssh/openssh-portable
-
-
Notifications
You must be signed in to change notification settings - Fork 47
HPN-SSH 18.7.1 Release #137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a patched based on one written by Kim Minh Kaplan and submitted to OpenSSH in 2018. This implements *some* features of RFC 8305 but, significnatly, does not do asynchronous DNS queries. It is currently only implemented for direct and proxy connections as found in sshconnect.c. This is the first version of the patch and is not in its final form. Eventually the RFC 8305 methods will be moved their own file and the necessary methods made public for use elsewhere in the code base.
This is a patched based on one written by Kim Minh Kaplan and submitted to OpenSSH in 2018. This implements *some* features of RFC 8305 but, significnatly, does not do asynchronous DNS queries. It is currently only implemented for direct and proxy connections as found in sshconnect.c. This is the first version of the patch and is not in its final form. Eventually the RFC 8305 methods will be moved their own file and the necessary methods made public for use elsewhere in the code base. Note: the regression test is of dubious value as the tests happen on localhost. It's mostly to ensure that any connection can take place rather than testing the functionality of the imeplementation. This will likely change in future versions.
The makes the happy_eyeballs function public so we can use it elsewhere if necessary. It also reduces the code complexity in sshconnect.c.
I also forgot to add those files to the commit.
The default IPQoS for SSH had changed from interactive = lowdelay bulk = throughput to interactive = af21 bulk = cs1 The result of this being that in test scenarios, where we used tc qdisc to insert delay on IPv6, the IPv4 connections ended up having the same effective delay as the IPv6. This meant that we'd always end up using the IPv6 connection even though IPv4 was not being delayed. I don't really understand DSCP enough to undertand why this is happening but this might be a test artifact. In any case, being that both IPv4 and IPv6 had the same effective delay the IPv6 connection would always end up winning the race because of the 250ms pause between the IPv6 and IPv4 attempts. This commit stil lhas too many debug statements in it but it works for testing.
This is a runtime option to specify the delay between starting the IPv6 connection and the IPv4 connection. The default is 250ms as per RFC 8305. This must be a positive integer. 0 or negative values will be rewritten to a value of 1ms. Updated documentation to include HappyEye options.
We were previously resolving the issue by changing the defaults for all connections. We now only change the QoS defaults if we are using RRFC 8305.
While the AES-CTR algorithm is FIPS certified this implementation is not. This causes FIPS to automatically error out when the aes-ctr-mt cipher is loaded. This can be resolved by using the DisableMTAES options but this requires the user to be aware of it and know why FIPS is erroring out. This will automatically detect if FIPS mode is enabled on fedora variants that write to /proc/sys/crypto/fips_enabled. In the event this entry doesn't exist or that we can't read from it we assume that FIPS mode is not enabled and we allow parallel ciphers. This does not apply to the ChaCha20 cipher as the algorithm itself is not FIPS validated and it's up to the admin to make sure it's not being offered as an option.
These fixes include pushing the SCP resume tests to their own test script. They don't work under windows so we now skip them. It also includes a change to the XOR function in cipher-ctr-mt. We were trying to do a 64 bit XOR but it was causing UBs in some of the CI tests. Until we have that resolved we need to stick with 32 bit XORs. Which we *really* need to resolve. The last major thing was that valgrind was consistently hanging on the rekey test (valgrind-5). Using the --fair-sched=try option for thread serialization in valgrind resolves that issue.
This came up under CI testing with MacOS.
Tabs not allowed in indents.
changes requested from review.
fips_enabled() in misc.c originally had debug messages that reported if the parallel ciphers were enabled or not. This was the wrong place for those messages. They should be in session.c and ssh.c when we check the FIPS status. Also, the function had unclear variable names. These were updated to be more descriptive.
Bug ci system
Feature happy eyes
Disable the parallel AES-CTR cipher under FIPS mode.
We should only need to change the IPQoS options for the client side to support RFC 8305.
I used the new DSCP values from the 10.1 branch instead of the 10.0 current. Annoying mistake
Increment version number
dorrellmw
approved these changes
Sep 29, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All commits approved through prior PRs or through direct review.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are 2 main changes since 18.7.0.
RFC 8305 aka Happy Eyeballs
This is for use on dual stack systems meaning that they have both IPv4 and IPv6 TCP stacks. When enabled this option will try to connect to the target over both IPv4 and IPv6 with preference given to IPv6. This preference is created by giving IPv6 a 250ms head start over the IPv4 connection. Users can change this with the HappyDelay option. The first connection that completes successfully will be used. Any outstanding connection attempts will be closed. As of version 18.7.1 this option should be considered somewhat experimental.
usage:
-oHappyEyes=[Yes|No] will enable Happy Eyeballs. The default is no.
-oHappyDelay=[N] where N is a positive integer expressed in
milliseconds. The default value of 250ms is
suggested by RFC 8305.
FIPS Mode and Parallel Ciphers
Using HPN-SSH in operating systems working in FIPS mode (e.g. RHEL with FIPS enabled) preclude the use of parallel ciphers. This is because the parallel AES-CTR implementation is not FIPS certified and will cause FIPS to exit with an error when loaded. In the case of the parallel ChaCha20 cipher the algorithm itself has not been FIPS certified and no implementation of ChaCha20 should be allowed in FIPS mode. We suggest the use of the AES-GCM cipher when operating under FIPS mode for optimal performance. This is behaviour is not user adjustable.
Minor Changes
The 64bit XOR method used in AES-CTR-MT was causing undefined behaviour. We have reduce the maximum bit size of an XOR to 32 bits until we develop a better XOR method. XORing is one of those things that can have an outsized impact on performance so please let us know if you see any noticeable performance hit. Also, if anyone wants to solve the XOR issue for us we'd love the help. Various changes have been made to the CI system on github and we've changed some minor parts of the regression test suites.