私はセキュリティ分野の初心者なので、次のようなエラーについて理解したいです:
com.jcraft.jsch.JSchException: UnknownHostKey: 127.0.0.1。RSA キーのフィンガープリントは、com.jcraft.jsch.Session.checkHost(Session.java:797)、com.jcraft.jsch.Session.connect(Session.java:342)、com.jcraft.jsch.Session.connect(Session.java:183)、FileTransfer.main(FileTransfer.java:37) の a2:39:3f:44:88:e9:1f:d7:d1:71:f4:85:98:fb:90:dc です。プロセスは終了コード 0 で終了しました。
「unknownHostKey: 127.0.0.1. RSAキー」の意味
指紋はa2:39:3f:44:88:e9:1f:d7:d1:71:f4:85:98:fb:90:dc`です
known_hosts
このエラーを修正するには、ファイルと呼ばれるファイルを設定する必要があります :
次のように設定してみました:
127.0.0.1
しかし、これは機能しません。ファイルの意味を誤解しているのでしょうか known_hosts
?
答え1
この回答の功績はジルからStackExchange セキュリティ サイト、彼/彼女の役職known_hosts
SSH/SFTP のこのコンポーネントを理解するには、ファイルの説明がauthorized_keys
よい出発点となります。
以下を参照してください:
このknown_hosts
ファイルにより、クライアントはサーバーを認証して、なりすまし者に接続していないことを確認できます。このauthorized_keys
ファイルにより、サーバーはユーザーを認証できます。
サーバー認証
SSH接続が確立されるときに最初に起こることの1つは、サーバーがクライアントに公開鍵を送信し、(公開鍵暗号) をクライアントに送り、関連する秘密鍵を知っていることを伝えます。これによりサーバーが認証されます。プロトコルのこの部分が成功すると、クライアントはサーバーが主張するとおりのサーバーであることを認識します。
クライアントは、サーバーが既知のサーバーであり、正しいサーバーを装っている不正なサーバーではないことを確認できます。SSH は、サーバーの正当性を検証するための単純なメカニズムのみを提供します。クライアント~/.ssh/known_hosts
マシンのファイル (システム全体のファイルもあります/etc/ssh/known_hosts
) に、すでに接続したサーバーを記憶します。サーバーに初めて接続するときは、サーバーが提示した公開キーが実際に接続したいサーバーの公開キーであるかどうかを他の方法で確認する必要があります。接続しようとしているサーバーの公開キーがある場合は、~/.ssh/known_hosts
クライアントに手動で追加できます。
ちなみに、known_hosts
DSA だけでなく (RSA や ECDSA も)、SSH 実装でサポートされている任意のタイプの公開キーを含めることができます。
機密データをサーバーに送信する前に、サーバーの認証を行う必要があります。特に、ユーザー認証にパスワードが含まれる場合、認証されていないサーバーにパスワードを送信してはなりません。
ユーザ認証
サーバーは、リモート ユーザーがそのアカウントにアクセスする権限があることを証明できる場合にのみ、そのユーザーのログインを許可します。サーバーの構成とユーザーの選択に応じて、ユーザーは複数の形式の資格情報のいずれかを提示できます (以下のリストはすべてを網羅しているわけではありません)。
- ユーザーはログインしようとしているアカウントのパスワードを提示し、サーバーはパスワードが正しいかどうかを確認します。
- ユーザーは公開鍵を提示し、その公開鍵に関連付けられた秘密鍵を所有していることを証明できます。これは、サーバーの認証に使用される方法とまったく同じですが、ユーザーが自分の ID を証明しようとし、サーバーがそれを検証します。ユーザーが秘密鍵を知っており、公開鍵がアカウントの承認リスト (
~/.ssh/authorized_keys
サーバー上)にあることを証明すると、ログイン試行は受け入れられます。 - 別の方法としては、ユーザー認証の作業の一部をクライアント マシンに委任する方法があります。これは、企業などの管理された環境で、多くのマシンが同じアカウントを共有する場合に発生します。サーバーは、逆の場合と同じメカニズムを使用してクライアント マシンを認証し、その後、クライアントにユーザー認証を任せます。