web-dev-qa-db-ja.com

MITM攻撃に対するサーバーssh証明書チェーン？

Sshを介したサーバーとの最初の接触時に、選択されたキーアルゴリズムのサーバーの公開キーがユーザーに提示され、検証されます。検証後、結果は通常、後のMITM攻撃に対抗するために~/.ssh/known_hostsファイルに保存されます。

$ ssh Host.example.com
The authenticity of Host 'Host.example.com (1.2.3.4)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)?

これは明らかに最初の接続でのMITM攻撃に対しては役に立たず、問題をユーザーに移すだけです。ユーザーは、提示された公開鍵を検証するための何らかのプロセスを実施する必要があります。これがどのように終了するかは誰もが知っています。

企業CAで署名されたsshサーバーキーを配布して、最初の接触時のMITM攻撃に対抗することは可能ですか？証明書チェーンを備えた公開鍵と秘密鍵のインフラストラクチャは、これを一般的にサポートしていますが、企業環境でsshサーバーを保護するために使用されるのを見たことがありません。

一般的な考え方は、一連のホストのCAキーを信頼することです。

trust *.example.com SHA256:<fingerprint(public key(corporate-ca))>

そして、これをこぶし、CAによって署名されたすべてのホストは信頼されています。

ca.example.com
+- Host.example.com

これはHTTPSの保護方法に似ており、sshは同じ基盤技術を使用しているため、OpenSSHにすでに実装されているようなもので、見つかりませんでしたか？

sshssl-certificatecertificate-authoritypki
3
Lars

これは可能です。

引用 ドキュメント ：

AUTHORIZED_KEYS FILE FORMAT
[...]
     cert-authority
             Specifies that the listed key is a certification authority (CA)
             that is trusted to validate signed certificates for user authentication.

             Certificates may encode access restrictions similar to these key options.
             If both certificate restrictions and key options are present, the most
             restrictive union of the two is applied.

これを達成するためのステップ：

  • SSHサーバーCAキーを生成します。
ssh-keygen -f server_ca
  • SSHサーバーのホストキーを生成します。
ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key
  • CAキーを使用してホストキーに署名します。
ssh-keygen -s server_ca -I somehost.example.com -h -n 'somehost.example.com,somehost,<list of SANs>,<list of IPv4>,<list of IPv6>' -V +3650d ssh-ecdsa.key
  • SSHサーバーにホストキーと証明書を展開します（証明書とキーを/etc/sshにコピーし、/etc/ssh/sshd_configを編集します）。
HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
HostKey /etc/ssh/ssh-ecdsa.key
  • ホストを識別するためにCAキーを信頼するようにクライアントを設定します（〜/ .ssh/unknown_hosts）
@cert-authority example.com ssh-rsa AAAA[...]

メモ：

  • 通常のX.509PKIとは互換性がありません。
  • 鍵失効リスト（KRL）を維持（および消費）する必要があります。詳細については、 OpenSSHクックブック を参照してください。
  • 面倒ですが、 Vault のようなものと構成管理ツールを使用してこれを自動化することを検討してください。
  • Monkeysphere プロジェクトを見て、「SSHの信頼のウェブ」のアイデアを取り入れてください。

以下のリンクで詳細を確認してください。特に、ユーザーのキーに署名するようにこれを設定する方法については、こちらをご覧ください。

リンク：

4
fuero

別のアプローチは、SSHキーフィンガープリントをSHFPレコードとしてDNSに公開することです。
RFC 4255を参照 https://tools.ietf.org/html/rfc4255

これにより、（グローバル）sshクライアントのデフォルトで VerifyHostKeyDNS をyesに設定すると、公開鍵の検証が自動化されます。

3
HBruijn

企業環境にある場合は、すべてのマシンのSSHキーの集中管理リストを作成して、お気に入りの構成管理ツールを使用してすべてのクライアントの/etc/ssh/ssh_known_hostsに展開することもできます。これは、マシン間の直接ホストベースの認証にも使用できます。 （SSHホストキーを一元的に管理することは、サーバーが再インストールされたときに不要なホストキーの変更を防ぐのにも役立ちます。）

もちろん、このアプローチは、クライアントとサーバーの両方が制御下にある「内部」SSHアクセスに対してのみ機能します。 SSHインする任意の外部ユーザーが必要な場合（そして、それらにknown_hostsファイルを与えることはできません）、DNSSECで保護されたDNSのSSHFPレコードがおそらく最適な方法です。

2
TooTea