OpenSSH 8.2 がリリースされました
2020/02/14, OpenSSH 8.2 がリリースされました.
- OpenSSH 8.2 Release Note 中の OpenSSH 8.2 での変更点の翻訳
- この記事にも添付します.
- OpenSSH 移植版付属文書の翻訳
SHA-1 の危殆化による変更, FIDO/U2F 対応が行なわれています.
2020/02/14 16:25(JST) 現在 tarball が https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ などで配布されていないようです. (2020/02/15 には解消されました) https://github.com/openssh/openssh-portable は更新されています.
https://www.openssh.com/txt/release-8.2
Future deprecation notice
=========================
将来廃止される機能についての通知
It is now possible[1] to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K. For this reason, we will be
disabling the "ssh-rsa" public key signature algorithm by default in a
near-future release.
USドル 50K より少ない金額で SHA-1 アルゴリズムに対する選択プレフィックス
攻撃が実行できることが [1] で示されている. このため, 我々は
近い将来のリリースで "ssh-rsa" 公開鍵署名アルゴリズムをデフォルトでは
無効にする予定だ.
This algorithm is unfortunately still used widely despite the
existence of better alternatives, being the only remaining public key
signature algorithm specified by the original SSH RFCs.
このアルコリズムは, よりよい代替アルゴリズムがあるにもかかわらず
もともとの SSH RFC で定義された公開鍵署名アルゴリズムのの中で
ただ1つ残ったアルゴリズムとして,
不幸なことにいまだ広く用いられている.
The better alternatives include:
次に示すものがよりよい代替だ:
* The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
algorithms have the advantage of using the same key type as
"ssh-rsa" but use the safe SHA-2 hash algorithms. These have been
supported since OpenSSH 7.2 and are already used by default if the
client and server support them.
RFC8332 の RSA SHA-2 署名アルゴリズム rsa-sha-256/512.
これらのアルゴリズムは "ssh-rsa" と同じ鍵タイプを用いる利点があり
安全な SHA-2 ハッシュアルゴリズムを用いている. これらは
OpenSSH 7.2 以降でサポートされており, クライアントとサーバが
サポートしているならすでにデフォルトで用いられている.
* The ssh-ed25519 signature algorithm. It has been supported in
OpenSSH since release 6.5.
ssh-ed25519 署名アルゴリズム. OpenSSH 6.5 以降でサポートされている.
* The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These
have been supported by OpenSSH since release 5.7.
RFC5656 の ECDSA アルゴリズム: ecdsa-sha2-nistp256/384/521. These
これらは OpenSSH 5.7 以降でサポートされている.
To check whether a server is using the weak ssh-rsa public key
algorithm, for host authentication, try to connect to it after
removing the ssh-rsa algorithm from ssh(1)'s allowed list:
サーバが, ホストの認証のために, 弱い ssh-rsa 公開鍵アルゴリズムを
利用しているか検査するには, ssh(1) の許可リストから ssh-rsa
アルゴリズムを除いたあとで接続を試行すればよい.
ssh -oHostKeyAlgorithms=-ssh-rsa user@host
If the host key verification fails and no other supported host key
types are available, the server software on that host should be
upgraded.
ホスト鍵検証が失敗し他にサポートされたホスト鍵の種類がない場合,
ホストのサーバソフトウェアをアップグレードする必要がある.
A future release of OpenSSH will enable UpdateHostKeys by default
to allow the client to automatically migrate to better algorithms.
Users may consider enabling this option manually.
OpenSSH の将来のリリースでは, クライアントがよりよいアルゴリズムに
自動的に移行できるようにする UpdateHostKeys 設定項目をデフォルトで有効にする.
ユーザはこの設定項目をマニュアルで有効にしてもよい.
[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf
Security
========
セキュリティ
* ssh(1), sshd(8), ssh-keygen(1): this release removes the "ssh-rsa"
(RSA/SHA1) algorithm from those accepted for certificate signatures
(i.e. the client and server CASignatureAlgorithms option) and will
use the rsa-sha2-512 signature algorithm by default when the
ssh-keygen(1) CA signs new certificates.
ssh(1), sshd(8), ssh-keygen(1): このリリースで "ssh-rsa" (RSA/SHA1)
アルゴリズムを 証明書の署名のために受け入れる署名 (すなわち,
クライアントとサーバの CASignatureAlgorithms 設定項目) から除く.
また, ssh-keygen(1) の CA が新しい証明書に署名する際の
デフォルトのアルゴリズムとして rsa-sha2-512 署名アルゴリズムを
利用する.
Certificates are at special risk to the aforementioned SHA1
collision vulnerability as an attacker has effectively unlimited
time in which to craft a collision that yields them a valid
certificate, far more than the relatively brief LoginGraceTime
window that they have to forge a host key signature.
証明書は前述の SHA1 衝突脆弱性に対して特別なリスクがある.
攻撃者は正当な署名を生成する衝突を工夫するのに,
実質的に無限の時間を使える.
ホスト鍵の署名を攻撃者が偽造するには
比較的に短時間な LoginGraceTime で指定された時間内に行なう必要がある.
The OpenSSH certificate format includes a CA-specified (typically
random) nonce value near the start of the certificate that should
make exploitation of chosen-prefix collisions in this context
challenging, as the attacker does not have full control over the
prefix that actually gets signed. Nonetheless, SHA1 is now a
demonstrably broken algorithm and futher improvements in attacks
are highly likely.
OpenSSH 証明書フォーマットは, CAが指定する(典型的にはランダムな)
ナンス値を証明書の先頭近くに含んでいる.
この値は, 攻撃者が実際に署名したプレフィックスに対して
完全なコントロールがない場合でも, この文脈での挑戦で,
選択プレフィックス衝突による攻撃に利用されうる.
それにもかかわらず, SHA1 は今や明らかに破られたアリゴリズムで
攻撃がさらに改良されることが大いにありえる.
OpenSSH releases prior to 7.2 do not support the newer RSA/SHA2
algorithms and will refuse to accept certificates signed by an
OpenSSH 8.2+ CA using RSA keys unless the unsafe algorithm is
explicitly selected during signing ("ssh-keygen -t ssh-rsa").
Older clients/servers may use another CA key type such as
ssh-ed25519 (supported since OpenSSH 6.5) or one of the
ecdsa-sha2-nistp256/384/521 types (supported since OpenSSH 5.7)
instead if they cannot be upgraded.
7.2 より前の OpenSSH のリリースは, より新しい RSA/SHA2 アルゴリズムを
をサポートしておらず, 安全でないアルゴリズムを署名の際に
明示的に選択した場合 ("ssh-keygen -t ssh-rsa") を除いて
OpenSSH 8.2 以降の CA が RSA 鍵を用いて署名した証明書を受け入れられなくなる.
古いクライアント/サーバは, アップグレードできないならば, 代わりに (OpenSSH 6.5
以降でサポートされている) ssh-ed25519 や (OpenSSH 5.7
以降でサポートされている) ecdsa-sha2-nistp256/384/521
のうちの1つのような 別の CA 鍵タイプを利用することになる.
Potentially-incompatible changes
================================
潜在的に非互換な変更
This release includes a number of changes that may affect existing
configurations:
このリリースは既存の設定に影響するいくつかの変更がある.
* ssh(1), sshd(8): the above removal of "ssh-rsa" from the accepted
CASignatureAlgorithms list.
ssh(1), sshd(8): 前述のように CASignatureAlgorithms
で受け入れるリストから "ssh-rsa" を除去
* ssh(1), sshd(8): this release removes diffie-hellman-group14-sha1
from the default key exchange proposal for both the client and
server.
ssh(1), sshd(8): クライアントとサーバのデフォルトの鍵交換候補から
diffie-hellman-group14-sha1 をこのリリースで除く.
* ssh-keygen(1): the command-line options related to the generation
and screening of safe prime numbers used by the
diffie-hellman-group-exchange-* key exchange algorithms have
changed. Most options have been folded under the -O flag.
ssh-keygen(1): diffie-hellman-group-exchange-* 鍵交換アルゴリズムで
用いられる安全な素数の生成と選別に関連するコマンドラインオプションが
変更される. たいがいのオプションが -O フラグの下に畳み込まれる.
* sshd(8): the sshd listener process title visible to ps(1) has
changed to include information about the number of connections that
are currently attempting authentication and the limits configured
by MaxStartups.
sshd(8): ps(1) で見れるsshd のリスナープロセスのタイトルが
変更され, 現在認証を試行している接続の数と MaxStartups
で設定された制限の情報を含むようになる.
Changes since OpenSSH 8.1
=========================
OpenSSH 8.1 からの変更点
This release contains some significant new features.
このリリースはいくつかの重大な新機能を含んでいる.
FIDO/U2F Support
----------------
FIDO/U2F サポート
This release adds support for FIDO/U2F hardware authenticators to
OpenSSH. U2F/FIDO are open standards for inexpensive two-factor
authentication hardware that are widely used for website
authentication. In OpenSSH FIDO devices are supported by new public
key types "ecdsa-sk" and "ed25519-sk", along with corresponding
certificate types.
このリリースでは OpenSSH に FIDO/U2F ハードウェア認証器のサポートを
追加する. U2F/FIDO は ウェブサイトの認証に広く用いられている
安価な 2 要素認証ハードウェアのオープンな標準だ. OpenSSH では
FIDO デバイスは新しい "ecdsa-sk" と "ed25519-sk" 公開鍵鍵タイプと
関連する証明書のタイプをサポートする.
ssh-keygen(1) may be used to generate a FIDO token-backed key, after
which they may be used much like any other key type supported by
OpenSSH, so long as the hardware token is attached when the keys are
used. FIDO tokens also generally require the user explicitly authorise
operations by touching or tapping them.
ssh-keygen(1) は, FIDO のトークンに支援された鍵を生成するに使われるようになる.
これらの鍵が利用される際にハードウェアトークンが取り付けられているならば,
OpenSSH でサポートされた他の鍵タイプのように利用できる.
FIDO トークンはさらに, トークンに触れたり押したりすることでの
ユーザの明示的な許可を一般的に要求する.
Generating a FIDO key requires the token be attached, and will usually
require the user tap the token to confirm the operation:
FIDO キーの生成にはトークンが取り付けられていることが必要で,
ユーザがトークンをタップしての操作の確認が通常要求される.
$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your security key to authorize key generation.
Enter file in which to save the key (/home/djm/.ssh/id_ecdsa_sk):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/djm/.ssh/id_ecdsa_sk
Your public key has been saved in /home/djm/.ssh/id_ecdsa_sk.pub
This will yield a public and private key-pair. The private key file
should be useless to an attacker who does not have access to the
physical token. After generation, this key may be used like any other
supported key in OpenSSH and may be listed in authorized_keys, added
to ssh-agent(1), etc. The only additional stipulation is that the FIDO
token that the key belongs to must be attached when the key is used.
公開鍵と秘密鍵のペアが生成される. 秘密鍵ファイルは物理トークンにアクセス
できない攻撃者には利用できないはずだ. 生成のあと, この鍵は OpenSSH の
他のサポートされた鍵のように利用できる. authorized_keys ファイルに列挙でき,
ssh-agent(1) に追加できる, などなど. 唯一の追加の条件は,
鍵を利用する際に鍵が属している FIDO トークンが取り付けられていなければならない
ことだ.
FIDO tokens are most commonly connected via USB but may be attached
via other means such as Bluetooth or NFC. In OpenSSH, communication
with the token is managed via a middleware library, specified by the
SecurityKeyProvider directive in ssh/sshd_config(5) or the
$SSH_SK_PROVIDER environment variable for ssh-keygen(1) and
ssh-add(1). The API for this middleware is documented in the sk-api.h
and PROTOCOL.u2f files in the source distribution.
FIDO トークンは たいがい USB を用いて接続されるが, Bluetooth や
NFC といった手段でも取り付けられる. OpenSSH では, トークンとの通信は
ssh/sshd_config(5) の SecurityKeyProvider 設定項目
もしくは ssh-keygen(1) と ssh-add(1) に対する $SSH_SK_PROVIDER
環境変数で指定された ミドルウェアライブラリで管理される.
OpenSSH includes a middleware ("SecurityKeyProvider=internal") with
support for USB tokens. It is automatically enabled in OpenBSD and may
be enabled in portable OpenSSH via the configure flag
--with-security-key-builtin. If the internal middleware is enabled
then it is automatically used by default. This internal middleware
requires that libfido2 (https://github.com/Yubico/libfido2) and its
dependencies be installed. We recommend that packagers of portable
OpenSSH enable the built-in middleware, as it provides the
lowest-friction experience for users.
OpenSSH は USB トークンのサポートのためのミドルウェア
("SecurityKeyProvider=internal")
を含んでいる. これは, OpenBSD では自動的に有効で
移植版 OpenSSH では --with-security-key-builtin configure
オプションで有効となる. この内部ミドルウェアが有効ならば,
デフォルトで自動的に利用される.
この内部ミドルウェアは, libfido2(https://github.com/Yubico/libfido2) と
このライブラリが依存するものがインストールされていることを要求する.
移植版 OpenSSH のパッケージ作成者がこのビルトインミドルウェアを有効にして
ユーザが容易に経験できるようにすることを我々は推奨する.
Note: FIDO/U2F tokens are required to implement the ECDSA-P256
"ecdsa-sk" key type, but hardware support for Ed25519 "ed25519-sk" is
less common. Similarly, not all hardware tokens support some of the
optional features such as resident keys.
注意: FIDO/U2F トークンは ECDSA-P256 "ecdsa-sk" 鍵タイプの実装が要求されている
が, Ed25519 "ed25519-sk" のハードウェアサポートはより一般的ではない.
同様に, すべてのハードウェアトークンが resident key のような
追加の特徴をサポートしているわけではない.
The protocol-level changes to support FIDO/U2F keys in SSH are
documented in the PROTOCOL.u2f file in the OpenSSH source
distribution.
SSH での FIDO/U2F 鍵のサポートのためのプロトコルレベルでの変更は
OpenSSH ソース配布の PROTOCOL.u2f ファイルに文書化されている.
There are a number of supporting changes to this feature:
この特徴のための変更は次だ:
* ssh-keygen(1): add a "no-touch-required" option when generating
FIDO-hosted keys, that disables their default behaviour of
requiring a physical touch/tap on the token during authentication.
Note: not all tokens support disabling the touch requirement.
ssh-keygen(1): FIDOに支援された鍵を生成する "no-touch-required"
オプションを追加する. 認証の間にトークン上で物理的な タッチ/タップ
を要求するデフォルトの振舞いを無効にする.
注意: すべてのトークンがタッチ要求の無効をサポートするわけではない.
* sshd(8): add a sshd_config PubkeyAuthOptions directive that
collects miscellaneous public key authentication-related options
for sshd(8). At present it supports only a single option
"no-touch-required". This causes sshd to skip its default check for
FIDO/U2F keys that the signature was authorised by a touch or press
event on the token hardware.
sshd(8): sshd_config に PubkeyAuthOptions 設定項目を追加する.
sshd(8) に対するいろいろな公開鍵認証に関連したオプションを集める.
現在唯一のオプション "no-touch-required" のみをサポートする.
これは, sshd に対してトークンハードウェアのFIDO/U2F 鍵のデフォルトのチェック
(署名がトークンハードウェア上でのタッチやプレスによって
認証されたかどうか) をスキップする.
* ssh(1), sshd(8), ssh-keygen(1): add a "no-touch-required" option
for authorized_keys and a similar extension for certificates. This
option disables the default requirement that FIDO key signatures
attest that the user touched their key to authorize them, mirroring
the similar PubkeyAuthOptions sshd_config option.
ssh(1), sshd(8), ssh-keygen(1): authorized_keys に対する
"no-touch-required" オプションと, 証明書に対する同様の拡張を追加する.
このオプションは ユーザが署名を認証するために鍵に触れたかを証明する
FIDO 鍵署名に対するデフォルトの要求を無効にする.
同様に PubkeyAuthOptions sshd_config 設定項目と対になっている.
* ssh-keygen(1): add support for the writing the FIDO attestation
information that is returned when new keys are generated via the
"-O write-attestation=/path" option. FIDO attestation certificates
may be used to verify that a FIDO key is hosted in trusted
hardware. OpenSSH does not currently make use of this information,
beyond optionally writing it to disk.
ssh-keygen(1): "-O write-attestation=/path" オプションよって新しい鍵が
生成された際に返ってくる FIDO 認証情報を書き込みのサポートを追加する.
FIDO 認証証明書は FIDO 鍵が信頼されたハードウェア上にあるかを検証するのに
用いられることがある OpenSSH は現在オプションでディスクに書き込む以外では
この情報は利用しない.
FIDO2 resident keys
-------------------
FIDO2 resident keys
FIDO/U2F OpenSSH keys consist of two parts: a "key handle" part stored
in the private key file on disk, and a per-device private key that is
unique to each FIDO/U2F token and that cannot be exported from the
token hardware. These are combined by the hardware at authentication
time to derive the real key that is used to sign authentication
challenges.
FIDO/U2F OpenSSH 鍵は 2つの部分から構成される: "key handle" 部は
ディスク上に秘密鍵ファイル内に保存される.
デバイスごとの秘密鍵は それぞれの FIDO/U2F トークンについて唯一で
トークンハードウェアから取り出すことができない.
これらをハードウェアで組み合わせて認証時に
署名認証の挑戦に用いる実際の鍵を導出する.
For tokens that are required to move between computers, it can be
cumbersome to have to move the private key file first. To avoid this
requirement, tokens implementing the newer FIDO2 standard support
"resident keys", where it is possible to effectively retrieve the key
handle part of the key from the hardware.
コンピュータ間で移動する必要のあるトークンにとっては, 秘密鍵をまず
移動する必要があるのはやっかいとなりうる. この要求を避けるため,
より新しい FIDO2 標準がサポートする "resident keys" を実装したトークンは
ハードウェアから鍵の key handle 部分を効率的に取り出すことができる.
OpenSSH supports this feature, allowing resident keys to be generated
using the ssh-keygen(1) "-O resident" flag. This will produce a
public/private key pair as usual, but it will be possible to retrieve
the private key part from the token later. This may be done using
"ssh-keygen -K", which will download all available resident keys from
the tokens attached to the host and write public/private key files
for them. It is also possible to download and add resident keys
directly to ssh-agent(1) without writing files to the file-system
using "ssh-add -K".
OpenSSH はこの特徴をサポートする. ssh-keygen(1) の "-O resident"
を用いて resident keys を生成できる. これは 公開鍵/秘密鍵のペアを
通常のように生成するが, 後でトークンから秘密鍵の部分を取り出せる.
"ssh-keygen -K" を用いると, ホストに取り付けられたトークンから
すべての resident keys を ダウンロードし
公開鍵/秘密鍵ファイルに書き込む. "ssh-add -K" を用いると
ファイルシステムへファイルを書き込むことなく ssh-agent(1) に直接
resident keys をダウンロードできる.
Resident keys are indexed on the token by the application string and
user ID. By default, OpenSSH uses an application string of "ssh:" and
an empty user ID. If multiple resident keys on a single token are
desired then it may be necessary to override one or both of these
defaults using the ssh-keygen(1) "-O application=" or "-O user="
options. Note: OpenSSH will only download and use resident keys whose
application string begins with "ssh:"
resident keys は アプリケーション文字列とユーザIDにてトークン上で
インデックスされる. デフォルトで OpenSSH は アプリケーション文字列として
"ssh:" を利用する. ユーザID は利用しない(空). 1つのトークン上に複数の
resident keys を配置したいなら, ssh-keygen(1) の "-O application=" か
"-O user=" オプションを用いて デフォルトの1つないし両方を上書きする
必要がある. 注意： OpenSSH は "ssh:" で始まるアプリケーション文字列を
持つ resident keys のみをダウンロード/使用する.
Storing both parts of a key on a FIDO token increases the likelihood
of an attacker being able to use a stolen token device. For this
reason, tokens should enforce PIN authentication before allowing
download of keys, and users should set a PIN on their tokens before
creating any resident keys.
FIDO トークン上に鍵の両方の部分を保持するのは, 攻撃者が盗んだトークン
デバイスを利用できる蓋然性を増やす. このため, 鍵のダウンロードの前に
PIN 認証をトークンは強制すべきで, ユーザは resident keys を作成する前に
トークンに PIN を設定すべきだ.
Other New Features
------------------
他の新機能
* sshd(8): add an Include sshd_config keyword that allows including
additional configuration files via glob(3) patterns. bz2468
sshd(8): Include sshd_config キーワードを追加する. glob(3)
のパターンで追加の設定ファイルを含むことができる. bz2468
* ssh(1)/sshd(8): make the LE (low effort) DSCP code point available
via the IPQoS directive; bz2986,
ssh(1)/sshd(8): IPQoS 設定項目で LE(low effort) DSCP コードポイント
が利用できる. bz2986
* ssh(1): when AddKeysToAgent=yes is set and the key contains no
comment, add the key to the agent with the key's path as the
comment. bz2564
ssh(1): AddKeysToAgent=yes が設定されていて鍵にコメントがない場合,
エージェントへの鍵の追加時に鍵のパスがコメントとなる. bz2564
* ssh-keygen(1), ssh-agent(1): expose PKCS#11 key labels and X.509
subjects as key comments, rather than simply listing the PKCS#11
provider library path. PR138
ssh-keygen(1), ssh-agent(1): PKCS#11 のプロバイダライブラリ
パスを単純に列挙するのではなく, 鍵のコメントとして PKCS#11 鍵ラベルと
X.509 subject を露出する. PR138
* ssh-keygen(1): allow PEM export of DSA and ECDSA keys; bz3091
ssh-keygen(1): DSA と ECDSA 鍵の PEM エキスポートが可能になる; bz3091
* ssh(1), sshd(8): make zlib compile-time optional, available via the
Makefile.inc ZLIB flag on OpenBSD or via the --with-zlib configure
option for OpenSSH portable.
ssh(1), sshd(8): zlib がコンパイル時に選択可能になった(なしでもコンパイルできるようになった).
OpenBSD の Makefile.inc ZLIB フラグか 移植版 OpenSSH の --with-zlib configure
オプションで利用可能.
* sshd(8): when clients get denied by MaxStartups, send a
notification prior to the SSH2 protocol banner according to
RFC4253 section 4.2.
sshd(8): MaxStartups の制限でクライアントが接続できなかった場合
RFC4253 4.2 節に従い SSH2 のプロトコルバナーより前に通知を送る.
* ssh(1), ssh-agent(1): when invoking the $SSH_ASKPASS prompt
program, pass a hint to the program to describe the type of
desired prompt. The possible values are "confirm" (indicating
that a yes/no confirmation dialog with no text entry should be
shown), "none" (to indicate an informational message only), or
blank for the original ssh-askpass behaviour of requesting a
password/phrase.
ssh(1), ssh-agent(1): $SSH_ASKPASS プロンプトプログラムを起動する際
望まれるプロンプトの種類を記述するヒントをプログラムに渡す.
可能な値は "confirm" (テキストエントリが表示されない yes/no
確認ダイアログを指定), "none" (情報メッセージのみを指定), もしくは
元々のパスワード/パスフレーズを要求する ssh-askpass の振舞いのための
ブランクだ.
* ssh(1): allow forwarding a different agent socket to the path
specified by $SSH_AUTH_SOCK, by extending the existing ForwardAgent
option to accepting an explicit path or the name of an environment
variable in addition to yes/no.
ssh(1): $SSH_AUTH_SOCK で指定されたパスとは異なるエージェントソケットの
転送を可能にする. 既存の ForwardAgent 設定項目を拡張し, yes/no
だけではなく 明示的なパスや環境変数の名前を受け入れる.
* ssh-keygen(1): add a new signature operations "find-principals" to
look up the principal associated with a signature from an allowed-
signers file.
ssh-keygen(1): 新しい署名の操作 "find-principals" を追加する.
許可された署名者のファイルから署名に基づく principal を検索する.
* sshd(8): expose the number of currently-authenticating connections
along with the MaxStartups limit in the process title visible to
"ps".
sshd(8): "ps" で見えるプロセスタイトルに 現在認証中の接続数と
MaxStartups の制限を露出する.
Bugfixes
--------
バグ修正
* sshd(8): make ClientAliveCountMax=0 have sensible semantics: it
will now disable connection killing entirely rather than the
current behaviour of instantly killing the connection after the
first liveness test regardless of success. bz2627
sshd(8): ClientAliveCountMax=0 にちゃんとした意味を持たせる:
完全に接続を切断するようになる. 現在の振舞いは,
最初の生存テストのあとで成功/失敗にかかわらず接続を単に切断する.
bz2627
* sshd(8): clarify order of AllowUsers / DenyUsers vs AllowGroups /
DenyGroups in the sshd(8) manual page. bz1690
sshd(8): sshd(8) のマニュアルで, AllowUsers / DenyUsers と
AllowGroups / DenyGroups の順序を明確にする. bz1690
* sshd(8): better describe HashKnownHosts in the manual page. bz2560
sshd(8): マニュアルでの HashKnownHosts の記述を改善する. bz2560
* sshd(8): clarify that that permitopen=/PermitOpen do no name or
address translation in the manual page. bz3099
sshd(8): マニュアルでの permitopen=/PermitOpen の記述で,
名前やアドレスの変換をしないことを明確にする. bz3009
* sshd(8): allow the UpdateHostKeys feature to function when
multiple known_hosts files are in use. When updating host keys,
ssh will now search subsequent known_hosts files, but will add
updated host keys to the first specified file only. bz2738
ssh(1) な気がする.
sshd(8): 複数の known_hosts ファイルを利用する際に
UpdateHostKeys が機能するようにする. ホスト鍵を更新する際
ssh は最初以外のknown_hosts 鍵も検索するようになるが
最初に指定されたファイルにのみ更新されたホスト鍵を追加する.
bz2738
* All: replace all calls to signal(2) with a wrapper around
sigaction(2). This wrapper blocks all other signals during the
handler preventing races between handlers, and sets SA_RESTART
which should reduce the potential for short read/write operations.
すべて: sigaction(2) の wrapper で signal(2) のすべての呼び出しを
更新する. この wrapper は ハンドラ内で他のすべてのシグナルをブロックして
ハンドラ間の競合を防止し, 短い read/write 操作の可能性を減らす
SA_RESTART を指定する.
* sftp(1): fix a race condition in the SIGCHILD handler that could
turn in to a kill(-1); bz3084
sftp(1): kill(-1) で発生する SIGCHILD ハンドラの競合状態を修正する.
bz3084
* sshd(8): fix a case where valid (but extremely large) SSH channel
IDs were being incorrectly rejected. bz3098
sshd(8): 正当な(ただし非常に大きい) SSH チャンネル ID が
不正に拒否されている場合を修正する. bz3098
* ssh(1): when checking host key fingerprints as answers to new
hostkey prompts, ignore whitespace surrounding the fingerprint
itself.
ssh(1): 新しいホストキーのプロンプトの回答としてホスト鍵指紋を
チェックする際, 指紋自体の周りの空白を無視する.
* All: wait for file descriptors to be readable or writeable during
non-blocking connect, not just readable. Prevents a timeout when
the server doesn't immediately send a banner (e.g. multiplexers
like sslh)
すべて: ノンブロッキングの接続で, 読み込み可能だけではなく
読み込み可能か書き込み可能になるまでファイルデスクリプタを待つ.
サーバがすぐにバナーを送ってこない場合
(たとえば sslh のようなマルチプレクサ) のタイムアウトを防ぐ.
* sshd_config(5): document the sntrup4591761x25519-sha512@tinyssh.org
key exchange algorithm. PR#151
sshd_config(5): sntrup4591761x25519-sha512@tinyssh.org
鍵交換アルゴリズムについて記述する. PR#151
Portability
-----------
移植性
* sshd(8): multiple adjustments to the Linux seccomp sandbox:
- Non-fatally deny IPC syscalls in sandbox
- Allow clock_gettime64() in sandbox (MIPS / glibc >= 2.31)
- Allow clock_nanosleep_time64 in sandbox (ARM) bz3100
- Allow clock_nanosleep() in sandbox (recent glibc) bz3093
* sshd(8): Linux seccomp サンドボックスへの複数の調整:
- サンドボックスで IPC syscalls を致命的ではなく否定する
- サンドボックスで clock_gettime64() を許可する (MIPS / glibc >= 2.31)
- サンドボックスで clock_nanosleep_time64 を許可する (ARM) bz3100
- サンドボックスで clock_nanosleep() を許可する (recent glibc) bz3093
* Explicit check for memmem declaration and fix up declaration if the
system headers lack it. bz3102
* memmem 宣言の明示的なチェックとシステムヘッダで宣言がない場合に宣言を修正する.
bz3102