upstream: Fix some typos and an incorrect word in docs. Patch from
itoama at live.jp via github PR#172. OpenBSD-Commit-ID: 166ee8f93a7201fef431b9001725ab8b269d5874
This commit is contained in:
parent
99ff8fefe4
commit
0001576a09
6
PROTOCOL
6
PROTOCOL
|
@ -194,7 +194,7 @@ layer 2 frames or layer 3 packets. It may take one of the following values:
|
|||
SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */
|
||||
|
||||
The "tunnel unit number" specifies the remote interface number, or may
|
||||
be 0x7fffffff to allow the server to automatically chose an interface. A
|
||||
be 0x7fffffff to allow the server to automatically choose an interface. A
|
||||
server that is not willing to open a client-specified unit should refuse
|
||||
the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful
|
||||
open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
|
||||
|
@ -298,7 +298,7 @@ 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 disgregard such keys if they are received.
|
||||
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
|
||||
|
@ -496,4 +496,4 @@ OpenSSH's connection multiplexing uses messages as described in
|
|||
PROTOCOL.mux over a Unix domain socket for communications between a
|
||||
master instance and later clients.
|
||||
|
||||
$OpenBSD: PROTOCOL,v 1.36 2018/10/02 12:51:58 djm Exp $
|
||||
$OpenBSD: PROTOCOL,v 1.37 2020/02/21 00:04:43 dtucker Exp $
|
||||
|
|
|
@ -34,7 +34,7 @@ Detailed Construction
|
|||
The chacha20-poly1305@openssh.com cipher requires 512 bits of key
|
||||
material as output from the SSH key exchange. This forms two 256 bit
|
||||
keys (K_1 and K_2), used by two separate instances of chacha20.
|
||||
The first 256 bits consitute K_2 and the second 256 bits become
|
||||
The first 256 bits constitute K_2 and the second 256 bits become
|
||||
K_1.
|
||||
|
||||
The instance keyed by K_1 is a stream cipher that is used only
|
||||
|
@ -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.4 2018/04/10 00:10:49 djm Exp $
|
||||
$OpenBSD: PROTOCOL.chacha20poly1305,v 1.5 2020/02/21 00:04:43 dtucker Exp $
|
||||
|
||||
|
|
|
@ -142,7 +142,7 @@ choose not to include this information in the public key or save it by
|
|||
default.
|
||||
|
||||
Attestation information is useful for out-of-band key and certificate
|
||||
registration worksflows, e.g. proving to a CA that a key is backed
|
||||
registration workflows, e.g. proving to a CA that a key is backed
|
||||
by trusted hardware before it will issue a certificate. To support this
|
||||
case, OpenSSH optionally allows retaining the attestation information
|
||||
at the time of key generation. It will take the following format:
|
||||
|
@ -169,7 +169,7 @@ is signed over a blob that consists of:
|
|||
byte[] extensions
|
||||
byte[32] SHA256(message)
|
||||
|
||||
No extensons are yet defined for SSH use. If any are defined in the future,
|
||||
No extensions are yet defined for SSH use. If any are defined in the future,
|
||||
it will be possible to infer their presence from the contents of the "flags"
|
||||
value.
|
||||
|
||||
|
|
Loading…
Reference in New Issue