FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-07-22T19:33:44Z 2026-07-22T19:33:44Z Enji Cooper ngie@FreeBSD.org 2026-07-22T19:33:44Z urn:sha1:4db3872aabc33088cf180599c5eaa23b6f58e6d1 The ssh-sk-helper utility only functions if/when MK_USB == yes. Installing it on systems where MK_USB == no doesn't make sense. Differential Revision: https://reviews.freebsd.org/D58246 2025-08-26T19:04:16Z Ed Maste emaste@FreeBSD.org 2025-08-26T19:04:16Z urn:sha1:8e28d84935f2f0ee081d44f9803f3052b960e50b Full release notes are available at https://www.openssh.com/txt/release-10.0 Selected highlights from the release notes: Potentially-incompatible changes - This release removes support for the weak DSA signature algorithm. [This change was previously merged to FreeBSD main.] - This release has the version number 10.0 and announces itself as "SSH-2.0-OpenSSH_10.0". Software that naively matches versions using patterns like "OpenSSH_1*" may be confused by this. - sshd(8): this release removes the code responsible for the user authentication phase of the protocol from the per-connection sshd-session binary to a new sshd-auth binary. Security - sshd(8): fix the DisableForwarding directive, which was failing to disable X11 forwarding and agent forwarding as documented. [This change was previously merged to FreeBSD main.] New features - ssh(1): the hybrid post-quantum algorithm mlkem768x25519-sha256 is now used by default for key agreement. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D51630 2025-02-19T17:20:44Z Ed Maste emaste@FreeBSD.org 2025-02-19T17:20:44Z urn:sha1:0fdf8fae8b569bf9fff3b5171e669dcd7cf9c79e Highlights from the release notes are reproduced below. Some security and bug fixes were previously merged into FreeBSD and have been elided. See the upstream release notes for full details (https://www.openssh.com/releasenotes.html). --- Future deprecation notice ========================= OpenSSH plans to remove support for the DSA signature algorithm in early 2025. Potentially-incompatible changes -------------------------------- * sshd(8): the server will now block client addresses that repeatedly fail authentication, repeatedly connect without ever completing authentication or that crash the server. See the discussion of PerSourcePenalties below for more information. Operators of servers that accept connections from many users, or servers that accept connections from addresses behind NAT or proxies may need to consider these settings. * sshd(8): the server has been split into a listener binary, sshd(8), and a per-session binary "sshd-session". This allows for a much smaller listener binary, as it no longer needs to support the SSH protocol. As part of this work, support for disabling privilege separation (which previously required code changes to disable) and disabling re-execution of sshd(8) has been removed. Further separation of sshd-session into additional, minimal binaries is planned for the future. * sshd(8): several log messages have changed. In particular, some log messages will be tagged with as originating from a process named "sshd-session" rather than "sshd". * ssh-keyscan(1): this tool previously emitted comment lines containing the hostname and SSH protocol banner to standard error. This release now emits them to standard output, but adds a new "-q" flag to silence them altogether. * sshd(8): (portable OpenSSH only) sshd will no longer use argv[0] as the PAM service name. A new "PAMServiceName" sshd_config(5) directive allows selecting the service name at runtime. This defaults to "sshd". bz2101 New features ------------ * sshd(8): sshd(8) will now penalise client addresses that, for various reasons, do not successfully complete authentication. This feature is controlled by a new sshd_config(5) PerSourcePenalties option and is on by default. * ssh(8): allow the HostkeyAlgorithms directive to disable the implicit fallback from certificate host key to plain host keys. Portability ----------- * sshd(8): expose SSH_AUTH_INFO_0 always to PAM auth modules unconditionally. The previous behaviour was to expose it only when particular authentication methods were in use. * ssh(1), ssh-agent(8): allow the presence of the WAYLAND_DISPLAY environment variable to enable SSH_ASKPASS, similarly to the X11 DISPLAY environment variable. GHPR479 --- Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48914 2024-07-15T22:43:39Z Warner Losh imp@FreeBSD.org 2024-07-15T04:46:32Z urn:sha1:e9ac41698b2f322d55ccf9da50a3596edb2c1800 This is a residual of the $FreeBSD$ removal. MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix 2023-08-16T17:55:03Z Warner Losh imp@FreeBSD.org 2023-08-16T17:55:03Z urn:sha1:d0b2dbfa0ecf2bbc9709efc5e20baf8e4b44bbbf Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/ 2021-11-04T17:01:44Z Ed Maste emaste@FreeBSD.org 2021-10-07T03:31:17Z urn:sha1:e9a994639b2af232f994ba2ad23ca45a17718d2b Description of FIDO/U2F support (from OpenSSH 8.2 release notes, https://www.openssh.com/txt/release-8.2): This release adds support for FIDO/U2F hardware authenticators to OpenSSH. U2F/FIDO are open standards for inexpensive two-factor authentication hardware that are widely used for website authentication. In OpenSSH FIDO devices are supported by new public key types "ecdsa-sk" and "ed25519-sk", along with corresponding certificate types. ssh-keygen(1) may be used to generate a FIDO token-backed key, after which they may be used much like any other key type supported by OpenSSH, so long as the hardware token is attached when the keys are used. FIDO tokens also generally require the user explicitly authorise operations by touching or tapping them. Generating a FIDO key requires the token be attached, and will usually require the user tap the token to confirm the operation: $ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk Generating public/private ecdsa-sk key pair. You may need to touch your security key to authorize key generation. Enter file in which to save the key (/home/djm/.ssh/id_ecdsa_sk): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/djm/.ssh/id_ecdsa_sk Your public key has been saved in /home/djm/.ssh/id_ecdsa_sk.pub This will yield a public and private key-pair. The private key file should be useless to an attacker who does not have access to the physical token. After generation, this key may be used like any other supported key in OpenSSH and may be listed in authorized_keys, added to ssh-agent(1), etc. The only additional stipulation is that the FIDO token that the key belongs to must be attached when the key is used. To enable FIDO/U2F support, this change regenerates ssh_namespace.h, adds ssh-sk-helper, and sets ENABLE_SK_INTERNAL (unless building WITHOUT_USB). devd integration is not included in this change, and is under investigation for the base system. In the interim the security/u2f-devd port can be installed to provide appropriate devd rules. Reviewed by: delphij, kevans Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32509 2017-08-02T08:35:51Z Enji Cooper ngie@FreeBSD.org 2017-08-02T08:35:51Z urn:sha1:4b330699f819a81d8e34d471225143ffeb321855 directories to SUBDIR.${MK_TESTS} idiom This is being done to pave the way for future work (and homogenity) in ^/projects/make-check-sandbox . No functional change intended. MFC after: 1 weeks 2015-10-15T22:55:08Z Bryan Drewery bdrewery@FreeBSD.org 2015-10-15T22:55:08Z urn:sha1:aa92269e4636d8ec1b42fcd66e6f52c479e77516 MFC after: 3 weeks Sponsored by: EMC / Isilon Storage Division 2014-05-06T04:22:01Z Warner Losh imp@FreeBSD.org 2014-05-06T04:22:01Z urn:sha1:c6063d0da8e1f8d8452b0c2ee1c7ad718c1a7052 from the latter. 2014-04-21T21:39:25Z Julio Merino jmmv@FreeBSD.org 2014-04-21T21:39:25Z urn:sha1:38f0b757fd84d17d0fc24739a7cda160c4516d81 This change adds tests/ directories in the source tree to create various subdirectories in /usr/tests/ and to install placeholder Kyuafiles for them. the relevant hierarchies are: cddl, etc, games, gnu and secure. The reason for this is to simplify the addition of new test programs for utilities or libraries under any of these directories. Doing so on a case by case basis is unnecessary and is quite an obscure process.