SSHホスト検証エラーを処理する最もスムーズなワークフロー？

41

これは私たち全員が直面する単純な問題であり、おそらくあまり考えずに手動で解決します。

サーバーが変更されるか、再プロビジョニングされるか、IPアドレスが再割り当てされると、以下のSSHホスト検証メッセージを受け取ります。これらのssh識別エラーを解決するためのワークフローの合理化に興味があります。

次のメッセージが表示されたら、通常、問題のある行vi /root/.ssh/known_hosts +434を削除します（dd）。

他の組織の開発者/ユーザーが、このメッセージを見ることに不満からファイル全体を 削除するのを見てきましたknown_hosts。私はそこまで行きませんが、これを処理するよりエレガントな方法があることを知っています。

ヒント？

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

— ewwhite
ソース

同じ問題があります。NASAのMesh ti.arc.nasa.gov/opensource/projects/meshの経験はありませんが、レビューするテクノロジのリストにあります。

— アンドリューギルマーティン

1

サーバーを再インストール/再割り当てするときに古いキーをコピーしてみませんか？

— Random832

@ Random832多くのサーバーがある状況ではスケーリングしません...または、IPアドレスを頻繁にリサイクルするラボ/テスト環境がある場合。または別のケース。元のサーバーが利用できない計画外のサーバー交換...

— ewwhite

3

私が抱えている大きな疑問は、どのようにしてこの状況に陥りますか？ホスト名を再利用する場合は、ホストの命名基準（tools.ietf.org/html/rfc1178）を再検討する必要があります。IPアドレスを再利用する場合は、そのIPアドレスで以前のサーバーを廃止するのと同じ手順の一環として、sshキーを廃止する必要があります。IPの再利用が自動化され、無意味なホスト名が必須である「ウェブスケール」環境で作業している場合、sshキーを修正する十分に自動化されたサーバーライフサイクルプロセスが必要です

— Paul Gear

47

このssh-keygenコマンドを使用して、ホストごとに特定のエントリを削除できます。

ssh-keygen -R las-db1

そのコマンドがない場合は、常にsedを使用できます。

sed -i '/las-db1/d' /root/.ssh/known_hosts

— カイル・ブラント
ソース

3

競合するキーの問題を解決するためにssh-keygen -Rを使用することも、Ubuntuのsshクライアントがこの問題が発生したときのエラーメッセージで示唆していることです。

— ケニーラッシャールト

私はそのssh-keygenコマンドへの切り替えを知りませんでした。良い！

— ewwhite

10

誰かが実際に「何か悪いことをしている！」ではないことを確認してください。

— マイケルハンプトン

1

会議でこれをしないでください！

— ポール・ギア

2

@ewwhite /etc/ssh/known_hostsネットワーク上のファイルに適切なホストキー（管理されたw / puppetなど）を入力するか、個人の〜/ .ssh / known_hostsファイルを入力します（これらのいずれかを行うにはssh-keyscan、既知の良好な/安全な上で実行できます）接続）。それがなければ（そして、あなたがセキュリティについてのすべてではない気に仮定して）セットUserKnownHostsFile=/dev/nullし、StrictHostKeyChecking=noあなたの中に ~/.ssh/config file（またはでSSHにオプションを渡す-o）

— voretaq7

25

puppetユーザーとして、これを解決する私の方法は、実際にpuppetサーバーにSSHホストキーを収集させ、SSH接続を行うすべてのシステムに公開することです。

このように、それらを削除することを心配する必要はありません。エージェントが30分ごとに実行されているため、パペットが実行され、キーが更新された時間の99％。私の例外は非常にまれであるため、待機するつもりがない場合は、システム全体のknown_hostsをすばやく編集してもかまいません。

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

— ゾレダチェ
ソース

+1構成管理ツールを組み込むための良い動き。

— ewwhite

4

セキュリティがそれほど重要ではない非常に特定の場合に役立つ提案を追加したいと思います。

頻繁に再インストールされるマシンのあるラボ環境があります。そのたびに、新しいホストキーが生成されます（おそらく、ホストキーをどこかに保存し、インストール後のスクリプトで設定できます）。

このラボ環境ではセキュリティは私にとって問題ではなく、キーは頻繁に変更されるため、.ssh / configファイルには次のものがあります。

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

これにより、ラボマシンに接続してもそのエラーが発生することはなく、sshクライアントはホストキーを確認せずに接続するだけです。

これは、セキュリティがまったく問題にならない場合にのみ行うべきことです。これは、中間者攻撃に対して脆弱な立場に置かれるためです。

— ケニー・ラスチャート
ソース

1

危険なようです。これらの一部は公開システムであるため、ホストの検証を保持したいと思います。

— ewwhite

1

これが、彼がこの方法は「セキュリティがそれほど重要ではない/関心がない」ためだけのものだと言った理由です。プライベートネットワーク/ラボ環境は、この構成に最適です。マルチマシンの自動スケーリング生産/公開システム、それほど多くはありません。

— 恐竜14年

4

openssh 5.6リリースノートによると、ホストキーを使用する必要はもうありません。

ホストベースの認証では、証明書ホストキーを使用できるようになりました。CAキーは、sshd（8）で説明されている@ cert-authorityマーカーを使用して、known_hostsファイルで指定する必要があります。

警告：これまでのところ、本番環境でこの機能を使用している人はいません。ご自身の責任で使用してください（ただし、openssh開発者は、多くのテストとコード監査を行わずに、このようなキラー機能をリリースしないほど妄想的です）。

2

SSHFP DNS ResourceRecordは、sshクライアントがそれをどの程度活用するかによって役立ちます。すべてのssh公開キーフィンガープリントをホスト名とともにそこに保存します。

DNSSECまたはDNS over SSLを事前に実装します。
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.orgは、ホストおよびユーザーキーの管理とPKI証明書を処理します。また、新しいキーが作成されると、SSHFP DNSレコードを自動的にアップロードします。

システムセキュリティサービスデーモン（SSSD）は、ホストSSHキーをキャッシュおよび取得するように構成できるため、アプリケーションとサービスは、ホストキーを1つの場所で探すだけで済みます。SSSDはそのID情報プロバイダーの1つとしてFreeIPAを使用できるため、FreeIPAはユニバーサルで集中化されたキーのリポジトリを提供します。管理者は、ホストSSHキーの配布、更新、検証について心配する必要はありません。

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html

— rjt
ソース