web-dev-qa-db-ja.com

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

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

サーバーの変更、再プロビジョニング、または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.
linuxsshcommand-line-interfacessh-keys
41
ewwhite

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

ssh-keygen -R las-db1

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

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

パペットユーザーとして、これを解決するための私の方法は、パペットサーバーに実際に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,
  }

}
25
Zoredache

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

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

このラボ環境ではセキュリティは問題ではなく、キーは頻繁に変更されるため、.ssh/configファイルに次のように記述します。

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

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

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

4
Kenny Rasschaert

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

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

警告：この機能を本番環境で使用している人は今まで聞いたことがありません。自己責任で使用してください（ただし、openssh開発者は、多くのテストとコード監査を行わずにこのようなキラー機能をリリースしないように偏執的だと思います）。

4
user130370

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はFreeIPAをID情報プロバイダーの1つとして使用できるため、FreeIPAは鍵のユニバーサルで一元化されたリポジトリを提供します。管理者は、ホストSSHキーの配布、更新、または検証について心配する必要はありません。

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

2
rjt