RepoMirrors
/
openssh
mirror of git://anongit.mindrot.org/openssh.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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:
dtucker@openbsd.org 2020-02-21 00:04:43 +00:00 committed by Darren Tucker
parent 99ff8fefe4
commit 0001576a09
3 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
PROTOCOL
View File

@ -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 $

4
PROTOCOL.chacha20poly1305
View File

@ -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 $

4
PROTOCOL.u2f
View File

@ -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.