From 78a9456a0a95f73575f0ecce9a56599d78a3d551 Mon Sep 17 00:00:00 2001 From: christos Date: Sun, 26 Aug 2018 07:39:56 +0000 Subject: [PATCH] Potentially-incompatible changes ================================ This release includes a number of changes that may affect existing configurations: * ssh-keygen(1): write OpenSSH format private keys by default instead of using OpenSSL's PEM format. The OpenSSH format, supported in OpenSSH releases since 2014 and described in the PROTOCOL.key file in the source distribution, offers substantially better protection against offline password guessing and supports key comments in private keys. If necessary, it is possible to write old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments when generating or updating a key. * sshd(8): remove internal support for S/Key multiple factor authentication. S/Key may still be used via PAM or BSD auth. * ssh(1): remove vestigal support for running ssh(1) as setuid. This used to be required for hostbased authentication and the (long gone) rhosts-style authentication, but has not been necessary for a long time. Attempting to execute ssh as a setuid binary, or with uid != effective uid will now yield a fatal error at runtime. * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). * sshd(8): the precedence of session environment variables has changed. ~/.ssh/environment and environment="..." options in authorized_keys files can no longer override SSH_* variables set implicitly by sshd. * ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed. They will now use DSCP AF21 for interactive traffic and CS1 for bulk. For a detailed rationale, please see the commit message: https://cvsweb.openbsd.org/src/usr.bin/ssh/readconf.c#rev1.284 --- crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 | 4 ++-- crypto/external/bsd/openssh/dist/PROTOCOL.krl | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 b/crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 index 4857d38533d2..9ce2a1e3a146 100644 --- a/crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 +++ b/crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 @@ -16,7 +16,7 @@ that computes a 128 bit integrity tag given a message and a single-use The chacha20-poly1305@openssh.com combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley in [3], but differs in the layout of -data passed to the MAC and in the addition of encyption of the packet +data passed to the MAC and in the addition of encryption of the packet lengths. Negotiation @@ -103,5 +103,5 @@ References [3] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 -$OpenBSD: PROTOCOL.chacha20poly1305,v 1.3 2016/05/03 13:10:24 djm Exp $ +$OpenBSD: PROTOCOL.chacha20poly1305,v 1.4 2018/04/10 00:10:49 djm Exp $ diff --git a/crypto/external/bsd/openssh/dist/PROTOCOL.krl b/crypto/external/bsd/openssh/dist/PROTOCOL.krl index b9695107bac7..f319bad21d33 100644 --- a/crypto/external/bsd/openssh/dist/PROTOCOL.krl +++ b/crypto/external/bsd/openssh/dist/PROTOCOL.krl @@ -145,7 +145,7 @@ This section may appear multiple times. 5. KRL signature sections The KRL_SECTION_SIGNATURE section serves a different purpose to the -preceeding ones: to provide cryptographic authentication of a KRL that +preceding ones: to provide cryptographic authentication of a KRL that is retrieved over a channel that does not provide integrity protection. Its format is slightly different to the previously-described sections: in order to simplify the signature generation, it includes as a "body" @@ -166,4 +166,4 @@ Implementations that retrieve KRLs over untrusted channels must verify signatures. Signature sections are optional for KRLs distributed by trusted means. -$OpenBSD: PROTOCOL.krl,v 1.3 2015/01/30 01:10:33 djm Exp $ +$OpenBSD: PROTOCOL.krl,v 1.4 2018/04/10 00:10:49 djm Exp $