[BACK]Return to PROTOCOL CVS log [TXT][DIR] Up to [local] / src / usr.bin / ssh

Diff for /src/usr.bin/ssh/PROTOCOL between version 1.48.4.1 and 1.49

version 1.48.4.1, 2023/12/18 14:57:43 version 1.49, 2023/08/28 03:28:43
Line 104 
Line 104 
   
 This is identical to curve25519-sha256 as later published in RFC8731.  This is identical to curve25519-sha256 as later published in RFC8731.
   
 1.9 transport: strict key exchange extension  1.9 transport: ping facility
   
 OpenSSH supports a number of transport-layer hardening measures under  OpenSSH implements a transport level ping message SSH2_MSG_PING
 a "strict KEX" feature. This feature is signalled similarly to the  and a corresponding SSH2_MSG_PONG reply.
 RFC8308 ext-info feature: by including a additional algorithm in the  
 initiial 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  #define SSH2_MSG_PING   192
 name in a peer's KEXINIT packet, it MUST make the following changes to  #define SSH2_MSG_PONG   193
 the the protocol:  
   
 a) During initial KEX, terminate the connection if any unexpected or  The ping message is simply:
    out-of-sequence packet is received. This includes terminating the  
    connection if the first packet received is not SSH2_MSG_KEXINIT.          byte            SSH_MSG_PING
    Unexpected packets for the purpose of strict KEX include messages          string          data
    that are otherwise valid at any time during the connection such as  
    SSH2_MSG_DEBUG and SSH2_MSG_IGNORE.  The reply copies the data (which may be the empty string) from the
 b) After sending or receiving a SSH2_MSG_NEWKEYS message, reset the  ping:
    packet sequence number to zero. This behaviour persists for the  
    duration of the connection (i.e. not just the first          byte            SSH_MSG_PONG
    SSH2_MSG_NEWKEYS).          string          data
   
   Replies are sent in order. They are sent immediately except when rekeying
   is in progress, in which case they are queued until rekeying completes.
   
   The server advertises support for these messages using the
   SSH2_MSG_EXT_INFO mechanism (RFC8308), with the following message:
   
           string          "ping@openssh.com"
           string          "0" (version)
   
   The ping/reply message is implemented at the transport layer rather
   than as a named global or channel request to allow pings with very
   short packet lengths, which would not be possible with other
   approaches.
   
 2. Connection protocol changes  2. Connection protocol changes
   
Legend:
Removed from v.1.48.4.1  
changed lines
  Added in v.1.49