☰

SSHパスワードなしのログインは、2番目のボックスのサービスアカウントを除いてほとんどうまく機能します。

tag-icon • tag-icon ssh password certificates
SSHパスワードなしのログインは、2番目のボックスのサービスアカウントを除いてほとんどうまく機能します。

数ヶ月前、私は小さなLinuxボックスを設定し、プライベートユーザーIDとサービスアカウントIDに対してパスワードのないSSHログインを設定しました。これは両側に良いです。個人ユーザーIDのキーを保存する場所と同じ場所にあるクライアントボックスに、サービスアカウントの秘密鍵/公開鍵ファイルを保存します。

私は以下を基本ガイドとして使用します。http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/。

今日は、2番目のボックスを設定し、同じ方法で構成する予定です。私の個人的なユーザー名として機能することに問題はありませんでした。ただし、サービスアカウントではまだ機能しておらず、その理由を理解していません。サービスアカウントを使用して2番目のボックスにSSHとして接続しようとすると、パスワードの入力を求められ、次に入力できます。

サービスアカウントの公開鍵が両方のボックスの~/.ssh/authorized_keysファイルに挿入され、キー値が両方のボックスと同じであることが確認されました。

~/.ssh に 700 の権限があり、 ~/.ssh/authorized_keys に 600 の権限があることを確認しました (また、640 でテストしたところ推奨される内容を読んだのです)。サービスアカウントホームディレクトリの両方のボックスでこれを確認しました。

両方のボックスにあるサービスアカウントの数値ユーザーIDは異なります。私はそれが違いをもたらすとは思わない。

また、サービスアカウントを使用して2つのボックスのうちの1つにSSHでアクセスし、サービスアカウントを使用してそのボックスから別のボックスにSSHを試みると、パスワードの入力を求められます。

「known_hosts」で何かをするべきですか、それとも別のことをする必要がありますか？

修正する:

提案したように、「-v」を使用してsshを実行し、ssh試行の出力を確認しました。

以下は、一部の省略を含む出力です。

%  ssh -v [email protected]
OpenSSH_7.2p2, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /home/myuserid/.ssh/config
debug1: /home/myuserid/.ssh/config line 2: Applying options for *
debug1: Connecting to targethost.com [...] port 22.
debug1: Connection established.
debug1: identity file /home/myuserid/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to targethost.com:22 as 'serviceaccountid'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:...
debug1: Host 'targethost.com' is known and matches the ECDSA host key.
debug1: Found key in /home/myuserid/.ssh/known_hosts:18
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuserid/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/myuserid/.ssh/id_dsa
debug1: Trying private key: /home/myuserid/.ssh/id_ecdsa
debug1: Trying private key: /home/myuserid/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password:

私が奇妙に思うのは、「次の認証方法：公開鍵」の後の最後の数行で、ファイルパス参照が「/home/serviceaccountid」の代わりに「/home/myuserid」ということです。これは大きな手がかりのようです。

ベストアンサー1

アカウントを使用してコメントを追加することはできませんが、トラブルシューティングに役立つように、より多くの情報を入手しようとしています。

ローカルコンピュータ1台、リモートコンピュータ2台など3台のコンピュータがあるようです。彼らはそれぞれあなたが使用する2つのアカウントを持っていますか？

ローカルコンピュータに個人アカウントとサービスアカウントがあり、ローカルssh service@remote-2コンピュータのプライベートアカウントで実行している場合は、サービスアカウントではなくローカルプライベートアカウントのSSHキーのみを探します。リモートサービスアカウントの認証されたキーファイルにローカルプライベート公開鍵を追加した場合。

私が奇妙に思うのは、「次の認証方法：公開鍵」の後の最後の数行で、ファイルパス参照が「/home/serviceaccountid」の代わりに「/home/myuserid」ということです。これは大きな手がかりのようです。

これがSSHがローカルアカウントでキーを見つける方法です。これはsshを呼び出すアカウントのホームディレクトリでなければなりません。パスをサービス アカウントのホーム ディレクトリとして指定するには、サービス アカウントにログインし、それからSSHを実行してください。

おすすめ記事