web-dev-qa-db-ja.com

パスワードなしのSSHは1回だけ機能します

パスワードを記述する必要なくSSHを使用するようにSSHを構成します。 Windows 10でUbuntu 18.04 LTSを使用しています。Hadoop3.1.1の実行に必要です（ https://hadoop.Apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-common/ SingleCluster.html＃Standalone_Operation ）疑似分散モードを使用します。

私は多くの異なるソリューションを試しましたが、結果はありませんでした。コマンドssh localhostを初めて使用したとき、パスフレーズを書く必要はありませんが、もう一度書くときはパスフレーズを書かなければならないことに気付きました。

私が使用したさまざまな手順を説明します。

  1. Ssh-keygen -t rsaを使用してキーを作成しました
  2. Authorized_keysファイルに公開キーを追加します：cat〜/ .ssh/id_rsa.pub >>〜/ .ssh/authorized_keys
  3. 実行キーを追加します：exec ssh-agent bashおよびssh-add id_rsa（数年前、この時点で時々異なる問題があり、異なるソリューションを使用しました： https://superuser.com/questions/1147145/ sshエージェントの使用方法の違い ）
  4. 実行します：ssh localhost

この時点ですべては正しいですが、ssh localhostを再度実行すると、パスフレーズを書く必要があります。これらの手順は3年前のAWSのUbuntuで正常に機能していました。

私はポイント3でこの他の方法を試しました： https://www.ssh.com/ssh/copy-id

私が見つけたすべての可能な解決策は、ポイント3で試したのと同じことを言った、または私はそれを思う。他のソリューションでも見つかったように、authorized_keysと.sshの権限を変更しようとしましたが、成功しませんでした。

18.04sshconfigurationopensshhadoop
1
CGG

この回答 をご覧ください。これは、ユーザーのsshの構成（~/.ssh/configの編集）およびその他の詳細を説明しています。

手順は次のとおりです。

  1. sshキーを生成します。
  2. ホストを~/.ssh/configファイルに追加します。
  3. Public（.pub）キーをリモートユーザーの~/.ssh/authorized_keys に追加します。
    • これは、ssh-copy-idコマンドで最も簡単に実行できます。
    • sshは、very~/.ssh/のパーミッションとその中にあるファイルに特化しています。 ssh-copy-idがすべてを処理します。
  4. ホストに接続してみてください：
    • ssh Host
    • ssh Host -vvv # Verbose output for troubleshooting

キーがパスワードで保護されているため、ssh-agentを使用しようとしていますか？ ssh-agentを使用せずに手動で接続して作業することをお勧めします。キーを機能させたら、ssh-agent固有の問題の解決に取り組むことができます。

トラブルシューティングを行うには、必ずsshを冗長モードで使用し、リモートサーバーのtail -fファイルを監視（/var/log/auth.log）してください。新しいシステムでは、journalctl（journalctl -u sshd | tail -f）を使用する必要があります。

キーが一般的に機能するようになったら、 このセットアップ手順のセット などのssh-agentドキュメントを確認できます。通常、手順は次のとおりです。

  1. キーを生成します（すでに行っているように）。
  2. キーをインストールします（すでに行っているように）。
  3. ssh-agent を開始します。
    • eval ssh-agent
    • 各接続などではなく、一度だけ。
    • これは、いつどのユーザーに応じて自動的に行われます。
  4. キーをssh-agent：に追加します。
    • ssh-add ~/.ssh/private_key

キーのロックが解除されない期間など、他のssh-agent設定オプションを必ず確認してください。

少しまとめると、問題は次のいずれかである可能性があります。

  1. ssh-agentの開始とid_rsaキーの追加（過去）を追加したと言いますが、新しいキーを生成したので、そのキーもssh-add 'dである必要があります。
    • キーを追加した後に問題が発生した場合は、ssh-agentが実際にシステムで実行されていることを確認してください。
    • ps aux | ssh-agent
  2. リモートユーザーのファイルではなく、ローカルファイルにキーを追加しています。
    • パスワードを追加するように考えてください。そのため、パスワードを受け入れるシステムにパスワードを追加する必要があります。
    • あなたのリモートホストはローカルホストですが、これはあなたが将来リモートホストで作業できるようになることを前提としています。ただし、正しいユーザーの正しい$HOMEディレクトリにある必要があります。
  3. あなたはそれが一度だけ働くと言いますか？短い時間枠で、たとえば1分間で2回試行すると、2回動作しますか？ ssh-agentが、テストしたよりも短い時間でキーをロックするように設定されているかどうかを理解しようとしています。
  4. ~/.ssh/authorized_keysファイル（>>）に追加するときは、最初にファイルを作成しましたが、これには不正なアクセス許可があります。
    • アクセスを保護し、リモートファイルへのバックアップを作成せずに、次のことを行わないでください。
    • 「リモートホスト」がlocalhostの場合、それはキーなど、保持したいファイルがあり、削除する前にバックアップする必要があります。
    • リモートの~/.ssh/ディレクトリ全体を削除し、ssh-copy-idを使用して、リモートホスト上のユーザーを適切にキー設定します。
    • これは、リモートホストのauth.logに表示され、ファイルのアクセス許可が正しくないことを指定します。
    • ssh-copy-idを使用してディレクトリとファイルを作成した後も引き続き問題が発生する場合は、~/.sshおよび生成されたキーファイルの権限を投稿してください。
  5. sshをリモートホストに挿入すると、ssh-agentを構成していない限り、ssh-agentを失い、~/.ssh/configを介してForwardAgent yesにsshを失います。 ssh-agentを転送したい場合は、それを許可するように設定し、その決定がセキュリティに与える影響を理解する必要があります。また、ForwardAgentは異なるマシンで実行するように設計されている可能性があります。また、ssh-agentが既に実行されているため、ローカルで転送を実行できない場合があります。
3
earthmeLon