Page MenuHomeFreeBSD

update base system OpenSSH to 8.7p1

Authored by emaste on Apr 25 2021, 11:32 PM.



This is a diff of my WIP OpenSSH 8.7p1 update tree against the current OpenSSH 7.9p1 in freebsd/main. Posted here for testing and overall comment; not intended for review. (Although it may be useful to examine changes in specific files.)

D28624 is a roll-up review of FreeBSD's base system changes applied against upstream OpenSSH 8.6p1 and is more useful for review.

Diff Detail

Lint Skipped
Unit Tests Skipped

Event Timeline

emaste retitled this revision from update base system OpenSSH to 8.6p1 to update base system OpenSSH to 8.7p1.

update to 8.7p1

emaste edited the summary of this revision. (Show Details)

This is my current WIP updating to 8.7p1, a diff against freebsd/main which currently has OpenSSH 7.9p1.
I will update D28624 shortly (to be a diff of 8.7p1 in the base system against upstream 8.7p1).
D31807 is a diff of in-tree 7.9p1 against upstream 7.9p1.


TODO resolve this


TODO: pass in version addendum as the 3rd param to kex_exchange_identification

Address the two identified TODOs

I have tried to apply this patch but crypto/openssh/sftp-realpath.c seems to be a completely new file missing in 14-CURRENT sources.

Indeed, from

It turns out there is a renamed file that confuses patch. If you've
applied this patch you should be able to rectify it by running:

mv crypto/openssh/openbsd-compat/realpath.c crypto/openssh/sftp-realpath.c

If you haven't applied the patch yet I've regenerated it. with
--no-renames, here:

Upstream's release notes are at - we should find important release notes to summarize when we commit the update to the base system. I've taken a first pass at identifying notable changes:


  • sshd(8): Remove support for obsolete "host/port" syntax. Slash- separated host/port was added in 2001 as an alternative to host:port syntax for the benefit of IPv6 users. These days there are establised standards for this like [::1]:22 and the slash syntax is easily mistaken for CIDR notation, which OpenSSH supports for some things. Remove the slash notation from ListenAddress and PermitOpen; bz#2335
  • ssh(1): When prompting whether to record a new host key, accept the key fingerprint as a synonym for "yes". This allows the user to paste a fingerprint obtained out of band at the prompt and have the client do the comparison for you.


  • ssh-keygen(1): when acting as a CA and signing certificates with an RSA key, default to using the rsa-sha2-512 signature algorithm. Certificates signed by RSA keys will therefore be incompatible with OpenSSH versions prior to 7.2 unless the default is overridden (using "ssh-keygen -t ssh-rsa -s ...").


It is now possible[1] to perform chosen-prefix attacks against the
SHA-1 hash algorithm for less than USD$50K. For this reason, we will
be disabling the "ssh-rsa" public key signature algorithm that depends
on SHA-1 by default in a near-future release.
  • ssh(1), sshd(8), ssh-keygen(1): this release removes the "ssh-rsa" (RSA/SHA1) algorithm from those accepted for certificate signatures (i.e. the client and server CASignatureAlgorithms option) and will use the rsa-sha2-512 signature algorithm by default when the ssh-keygen(1) CA signs new certificates.
  • ssh(1), sshd(8): the above removal of "ssh-rsa" from the accepted CASignatureAlgorithms list.
  • ssh-sk-helper(8): this is a new binary. It is used by the FIDO/U2F support to provide address-space isolation for token middleware libraries (including the internal one). It needs to be installed in the expected path, typically under /usr/libexec or similar.

    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.

(Note that additional work on the FreeBSD side may be needed in order to make FIDO/U2F support work in the base system.)




  • ssh(1): this release enables UpdateHostkeys by default subject to some conservative preconditions:
    • The key was matched in the UserKnownHostsFile (and not in the GlobalKnownHostsFile).
    • The same key does not exist under another name.
    • A certificate host key is not in use.
    • known_hosts contains no matching wildcard hostname pattern.
    • VerifyHostKeyDNS is not enabled.
    • The default UserKnownHostsFile is in use.




Imminent deprecation notice

OpenSSH will disable the ssh-rsa signature scheme by default in the
next release.
  • scp(1): this release changes the behaviour of remote to remote copies (e.g. "scp host-a:/path host-b:") to transfer through the local host by default. This was previously available via the -3 flag. This mode avoids the need to expose credentials on the origin hop, avoids triplicate interpretation of filenames by the shell (by the local system, the copy origin and the destination) and, in conjunction with the SFTP support for scp(1) mentioned below, allows use of all authentication methods to the remote hosts (previously, only non-interactive methods could be used). A -R flag has been added to select the old behaviour.
  • scp(1): experimental support for transfers using the SFTP protocol as a replacement for the venerable SCP/RCP protocol that it has traditionally used. SFTP offers more predictable filename handling and does not require expansion of glob(3) patterns via the shell on the remote side.

    SFTP support may be enabled via a temporary scp -s flag. It is intended for SFTP to become the default transfer mode in the near future, at which time the -s flag will be removed. The -O flag exists to force use of the original SCP/RCP protocol for cases where SFTP may be unavailable or incompatible.

I'm worried about the .depend file that's committed. Why is that there?
Did you intend to include the .github pipeline configurations? They won't be used on FreeBSD w/o other magic being written.


Does this need to be committed to the tree?

So other than those two things, this looks good to me.

looks good from a git point of view.

This revision is now accepted and ready to land.Sep 7 2021, 8:53 PM

I'm worried about the .depend file that's committed. Why is that there?

It just came from upstream (as with the GitHub CI pipeline parts). Seems it does no harm other than leading to a bit of confusion.