Merge changes between OpenSSH-10.0 and 10.2

Author: zoulasc

crypto/external/bsd/openssh/bin/ssh-agent/Makefile

@@ -1,9 +1,9 @@
-#	$NetBSD: Makefile,v 1.7 2023/06/03 09:09:02 lukem Exp $
+#	$NetBSD: Makefile,v 1.8 2025/10/11 15:45:06 christos Exp $
 
 BINDIR=/usr/bin
 
 PROG=	ssh-agent
-SRCS=	ssh-agent.c ssh-pkcs11-client.c
+SRCS=	misc-agent.c ssh-agent.c ssh-pkcs11-client.c
 
 COPTS.ssh-agent.c+=	${CC_WNO_FORMAT_TRUNCATION}
 COPTS.ssh-pkcs11-client.c+= -Wno-error=deprecated-declarations

crypto/external/bsd/openssh/dist/PROTOCOL

@@ -33,15 +33,11 @@ The method is documented in:
 
 http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
 
-1.3. transport: New public key algorithms "ssh-rsa-cert-v01@openssh.com",
-     "ssh-dsa-cert-v01@openssh.com",
-     "ecdsa-sha2-nistp256-cert-v01@openssh.com",
-     "ecdsa-sha2-nistp384-cert-v01@openssh.com" and
-     "ecdsa-sha2-nistp521-cert-v01@openssh.com"
+1.3. transport: Certificate key algorithms
 
 OpenSSH introduces new public key algorithms to support certificate
 authentication for users and host keys. These methods are documented
-in the file PROTOCOL.certkeys
+in at https://datatracker.ietf.org/doc/draft-miller-ssh-cert/
 
 1.4. transport: Elliptic Curve cryptography
 
@@ -82,29 +78,20 @@ contains:
 1.6 transport: AES-GCM
 
 OpenSSH supports the AES-GCM algorithm as specified in RFC 5647.
-Because of problems with the specification of the key exchange
-the behaviour of OpenSSH differs from the RFC as follows:
+Because of problems with the design of the algorithm negotiation in this
+RFC, OpenSSH (and other SSH implementations) use different rules as
+described in:
 
-AES-GCM is only negotiated as the cipher algorithms
-"aes128-gcm@openssh.com" or "aes256-gcm@openssh.com" and never as
-an MAC algorithm. Additionally, if AES-GCM is selected as the cipher
-the exchanged MAC algorithms are ignored and there doesn't have to be
-a matching MAC.
+https://datatracker.ietf.org/doc/draft-miller-sshm-aes-gcm/
 
 1.7 transport: chacha20-poly1305@openssh.com authenticated encryption
 
 OpenSSH supports authenticated encryption using ChaCha20 and Poly1305
-as described in PROTOCOL.chacha20poly1305.
+as described in:
 
-1.8 transport: curve25519-sha256@libssh.org key exchange algorithm
+https://datatracker.ietf.org/doc/draft-ietf-sshm-chacha20-poly1305/
 
-OpenSSH supports the use of ECDH in Curve25519 for key exchange as
-described at:
-http://git.libssh.org/users/aris/libssh.git/plain/doc/curve25519-sha256@libssh.org.txt?h=curve25519
-
-This is identical to curve25519-sha256 as later published in RFC8731.
-
-1.9 transport: ping facility
+1.8 transport: ping facility
 
 OpenSSH implements a transport level ping message SSH2_MSG_PING
 and a corresponding SSH2_MSG_PONG reply.
@@ -137,34 +124,16 @@ than as a named global or channel request to allow pings with very
 short packet lengths, which would not be possible with other
 approaches.
 
-1.10 transport: strict key exchange extension
-
-OpenSSH supports a number of transport-layer hardening measures under
-a "strict KEX" feature. This feature is signalled similarly to the
-RFC8308 ext-info feature: by including a additional algorithm in the
-initial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
-"kex-strict-c-v00@openssh.com" to its kex_algorithms and the server
-may append "kex-strict-s-v00@openssh.com". These pseudo-algorithms
-are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored
-if they are present in subsequent SSH2_MSG_KEXINIT packets.
-
-When an endpoint that supports this extension observes this algorithm
-name in a peer's KEXINIT packet, it MUST make the following changes to
-the protocol:
-
-a) During initial KEX, terminate the connection if out-of-sequence
-   packet or any message that is not strictly required by KEX is
-   received. This includes terminating the connection if the first
-   packet received is not SSH2_MSG_KEXINIT. Unexpected packets for
-   the purpose of strict KEX include messages that are otherwise
-   valid at any time during the connection such as SSH2_MSG_DEBUG,
-   SSH2_MSG_IGNORE or SSH2_MSG_UNIMPLEMENTED.
-b) After sending or receiving a SSH2_MSG_NEWKEYS message, reset the
-   packet sequence number to zero. This behaviour persists for the
-   duration of the connection (i.e. not just the first
-   SSH2_MSG_NEWKEYS).
-
-1.11 transport: SSH2_MSG_EXT_INFO during user authentication
+1.9 transport: strict key exchange extension
+
+OpenSSH supports a number of transport-layer hardening measures
+designed to thwart the so-called "Terrapin" attack against the
+early SSH protocol. These are collectively referred to as
+"strict KEX" and documented in an Internet-Draft:
+
+https://datatracker.ietf.org/doc/draft-miller-sshm-strict-kex/
+
+1.10 transport: SSH2_MSG_EXT_INFO during user authentication
 
 This protocol extension allows the SSH2_MSG_EXT_INFO to be sent
 during user authentication. RFC8308 does allow a second
@@ -369,52 +338,9 @@ and "hostkeys-prove-00@openssh.com"
 
 OpenSSH supports a protocol extension allowing a server to inform
 a client of all its protocol v.2 host keys after user-authentication
-has completed.
-
-	byte		SSH_MSG_GLOBAL_REQUEST
-	string		"hostkeys-00@openssh.com"
-	char		0 /* want-reply */
-	string[]	hostkeys
-
-Upon receiving this message, a client should check which of the
-supplied host keys are present in known_hosts.
-
-Note that the server may send key types that the client does not
-support. The client should disregard such keys if they are received.
-
-If the client identifies any keys that are not present for the host,
-it should send a "hostkeys-prove@openssh.com" message to request the
-server prove ownership of the private half of the key.
-
-	byte		SSH_MSG_GLOBAL_REQUEST
-	string		"hostkeys-prove-00@openssh.com"
-	char		1 /* want-reply */
-	string[]	hostkeys
-
-When a server receives this message, it should generate a signature
-using each requested key over the following:
-
-	string		"hostkeys-prove-00@openssh.com"
-	string		session identifier
-	string		hostkey
-
-These signatures should be included in the reply, in the order matching
-the hostkeys in the request:
-
-	byte		SSH_MSG_REQUEST_SUCCESS
-	string[]	signatures
-
-When the client receives this reply (and not a failure), it should
-validate the signatures and may update its known_hosts file, adding keys
-that it has not seen before and deleting keys for the server host that
-are no longer offered.
+has completed. This is documented in an Internet-Draft
 
-These extensions let a client learn key types that it had not previously
-encountered, thereby allowing it to potentially upgrade from weaker
-key algorithms to better ones. It also supports graceful key rotation:
-a server may offer multiple keys of the same type for a period (to
-give clients an opportunity to learn them using this extension) before
-removing the deprecated key from those offered.
+https://datatracker.ietf.org/doc/draft-miller-sshm-hostkey-update/
 
 2.6. connection: SIGINFO support for "signal" channel request
 
@@ -765,15 +691,15 @@ authorized_keys files, are formatted as a single line of text consisting
 of the public key algorithm name followed by a base64-encoded key blob.
 The public key blob (before base64 encoding) is the same format used for
 the encoding of public keys sent on the wire: as described in RFC4253
-section 6.6 for RSA and DSA keys, RFC5656 section 3.1 for ECDSA keys
-and the "New public key formats" section of PROTOCOL.certkeys for the
-OpenSSH certificate formats.
+section 6.6 for RSA keys, RFC5656 section 3.1 for ECDSA keys and
+https://datatracker.ietf.org/doc/draft-miller-ssh-cert/
+for the OpenSSH certificate formats.
 
 5.2 Private key format
 
 OpenSSH private keys, as generated by ssh-keygen(1) use the format
 described in PROTOCOL.key by default. As a legacy option, PEM format
-(RFC7468) private keys are also supported for RSA, DSA and ECDSA keys
+(RFC7468) private keys are also supported for RSA and ECDSA keys
 and were the default format before OpenSSH 7.8.
 
 5.3 KRL format
@@ -792,5 +718,5 @@ master instance and later clients.
 OpenSSH extends the usual agent protocol. These changes are documented
 in the PROTOCOL.agent file.
 
-$OpenBSD: PROTOCOL,v 1.55 2024/01/08 05:05:15 djm Exp $
-$NetBSD: PROTOCOL,v 1.24 2024/06/25 16:36:54 christos Exp $
+$OpenBSD: PROTOCOL,v 1.59 2025/08/06 11:22:53 dtucker Exp $
+$NetBSD: PROTOCOL,v 1.25 2025/10/11 15:45:06 christos Exp $

crypto/external/bsd/openssh/dist/PROTOCOL.agent

@@ -1,4 +1,4 @@
-$NetBSD: PROTOCOL.agent,v 1.18 2025/04/09 15:49:31 christos Exp $
+$NetBSD: PROTOCOL.agent,v 1.19 2025/10/11 15:45:06 christos Exp $
 The SSH agent protocol is described in
 https://datatracker.ietf.org/doc/draft-ietf-sshm-ssh-agent/
 
@@ -74,17 +74,6 @@ identities and, in particular, signature requests will check the key
 constraints against the session-bind@openssh.com bindings recorded for
 the agent connection over which they were received.
 
-3. SSH_AGENT_CONSTRAIN_MAXSIGN key constraint
-
-This key constraint allows communication to an agent of the maximum
-number of signatures that may be made with an XMSS key. The format of
-the constraint is:
-
-	byte		SSH_AGENT_CONSTRAIN_MAXSIGN (0x03)
-	uint32		max_signatures
-
-This option is only valid for XMSS keys.
-
 3. associated-certs-v00@openssh.com key constraint extension
 
 The key constraint extension allows certificates to be associated
@@ -116,4 +105,4 @@ A SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED will return SSH_AGENT_SUCCESS
 if any key (plain private or certificate) was successfully loaded, or
 SSH_AGENT_FAILURE if no key was loaded.
 
-$OpenBSD: PROTOCOL.agent,v 1.24 2024/11/27 13:27:34 djm Exp $
+$OpenBSD: PROTOCOL.agent,v 1.25 2025/08/29 03:50:38 djm Exp $