web-dev-qa-db-ja.com

パスワードなしのキーを使用するとSSHログインが機能しませんか？

エージェントは、キーを使用した署名の失敗を認めました

私はcentos6.5（32ビット）に取り組んでおり、ssh-keygenとssh-copy-idを使用してパスワードなしでsshログインしようとしましたか？私が行ったステップ：

最初にキーを作成しました：

[root@dd ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8f:48:0b:04:3a:e1:90:f4:9f:de:2a:33:63:ea:a8:82 [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
|+o.              |
|+o..             |
|o. ..            |
| . .. .          |
|    .o. S        |
|    .o.o o       |
|.    .o.. .      |
|E  *  .          |
|*oo =.           |
+-----------------+

次に、キーをリモートホストにコピーします。

[root@dd ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub 192.168.1.3
[email protected]'s password: My_Password
Now try logging into the machine, with "ssh '[email protected]'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

次にログインしようとしましたが、失敗します（キーを使用）：

[root@dd ~]# ssh 192.168.1.3
Agent admitted failure to sign using the key.
[email protected]'s password:

そして詳細なログとして：

[root@dd ~]# ssh -v [email protected]
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.3 [192.168.1.3] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.3' is known and matches the RSA Host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information 
Cannot determine realm for numeric Host address

debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric Host address

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric Host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
Agent admitted failure to sign using the key.
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password:
linuxsshcentos
5
Nidal

ローカルマシンでこのコマンドを実行するだけで問題を解決しました（キーを生成した後）。

$ ssh-add
3
Nidal

あなたは次の失敗に苦しんでいました：

エージェントは、キーを使用した署名の失敗を認めました。

これは残念ながら非診断メッセージです。対処できる問題には（少なくとも）2つのクラスがあります。

キーが読み込まれていません

ほとんどの場合、これは、ssh-agentに、ターゲットサーバー上のアカウントで受け入れられるsshキーがロードされていないことを意味します。この場合、この質問に対する @ Networkerの回答 で示されているように、解決策はかなり単純です。キーを追加します。

ssh-add

キーがデフォルト以外の場所にある場合は、それをssh-addに伝える必要があります。

ssh-add /path/to/key

エージェントはキーを理解できません

これは GNOMEバグ754028 であり、Seahorse 3.29.90で解決されました（安定版3.30 released 2018-09- 、 buntu 18.10）に含まれる 、- Fedora 29 、そしておそらくRed Hat/CentOS 9）。 3.29.90より前のSeahorse（したがってGNOMEキーリング）は、 ed25519 のような新しいキータイプやssh-keygen -o -a 100で生成されたキーを作成または追加できませんでした（ Secure Secure Shell）で提案されています チュートリアル）。

この問題の診断：

  • ssh myserverが「sshエージェント承認失敗」で失敗する
  • SSH_AUTH_SOCK= ssh myserverは問題なく動作します
  • 結論：gnome-keyringは複雑なキーを処理できません

このバグの実行可能な回避策を見つけたばかりで、どこにも公開されていないようです（ コメント Ubuntuのバグに追加したばかりです）ので、ここに配置します。

回避策：ssh-agentのソケットと同じソケットを使用して新しいgnome-keyringを起動します。

ssh-agent -a $SSH_AUTH_SOCK

これにより、ssh-agentの新しいインスタンスが起動し（GNOMEの機能の低いインスタンスを上書きします）、キーが含まれなくなります（seahorseが言っていることにもかかわらず、古いエージェントに関連付けられているため）。上記のキーがロードされていませんセクションに記載されているように、ssh-addを介してそれらを追加する必要があります。

ログインするたびにこれを実行する必要があります（または手動でスタートアップスクリプトに追加します）。古いソケットを保持する場合は、最初にmv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.brokenを実行します。

5
Adam Katz

追加した：

Host github.com
  HostName github.com
  User YOURUSERNAME
  IdentityFile ~/.ssh/id_rsa.pub

この問題を回避するために〜/ .ssh/configファイルに移動し、機能しているように見えます。

1
user164804