web-dev-qa-db-ja.com

「sign_and_send_pubkey:署名に失敗しました:エージェントが操作を拒否しました」の解決方法

SSHキーを使用して新しいデジタルオーシャンドロップレットを構成します。 ssh-copy-idを実行すると、これが得られます:

ssh-copy-id [email protected]
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

ただし、その後sshを試行すると、次のようになります。

ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password: 

パスワードを入力すると、私は正常にログインしますが、当然のことながら、そもそもSSHキーを作成するという目的は無効になります。私はssh-agentサーバー側を見てみることにしました。

[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# ssh-add -l
The agent has no identities.

user/.ssh/authorized_keysにもssh-rsaキーエントリが含まれていますが、find -name "keynamehere"は何も返しません。

63
user968270

クライアントマシンでssh-addを実行すると、SSHキーがエージェントに追加されます。

ssh-add -l(クライアント上)で、それが実際に追加されたことを確認します。

128
Oliver

Fedora 26を28にアップグレードした後、同じ問題に直面しました。そして、次のログが欠落していました

/var/log/secure
/var/log/messages

問題:

[email protected]  ~  ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:

エラーメッセージは実際の問題を示していません。問題は解決されました

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
40
Anto

Linux Ubuntu 18で同じ問題が発生していました。 Ubuntu 17.10からの更新後、すべてのgitコマンドがそのメッセージを表示します。

これを解決する方法は、id_rsaおよびid_rsa.pubに対する正しい権限を持っていることを確認することです。

stat --format '%a' <file>を使用して、現在のchmod番号を確認します。 id_rsaの場合は6であり、id_rsa.pubの場合は644です。

ファイルのアクセス許可を変更するには

chmod 600 id_rsa
chmod 644 id_rsa.pub

これでアップデートの問題が解決しました。

30
Fernando Munoz

Ssh-agentとしてgpg-agentを使用し、sshキーとしてgpgサブキーを使用すると、エラーが発生しました https://wiki.archlinux.org/index.php/GnuPG#gpg-agent

私の問題は、sway configで使用されるsleep + lockコマンドが原因で、gpgの無効なピンエントリttyが原因であると考えられます。

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

または単にスリープ/サスペンド

ピンエントリttyをリセットして問題を修正します

gpg-connect-agent updatestartuptty /bye > /dev/null

そして、私のSwayスリープ+ロックコマンドの修正:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"

2
SultanLegend

このエラーへ:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Githubアカウント>プロファイル> sshで公開鍵を確認または再度追加します。

私はこのように解決しました:

# chmod 400 ~/.ssh/id_rsa

# ls  ~/.ssh/id_rsa -ls  
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26  2017 /home/reinaldo/.ssh/id_rsa

# git pull                                 
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.

ありがとうございました。

2
reinaldo pinto

これはむしろスーパーユーザーの質問であるべきです。

確かにMacOSX SourceTree内でもまったく同じエラーが発生しますが、iTerm2ターミナル内ではうまく動作します。

しかし、問題は、私がtwossh-agentsを実行していることであるように見えました;(

最初は/usr/bin/ssh-agent(別名MacOSX's)で、次にHomeBrewが/usr/local/bin/ssh-agent実行中です。

SourceTreeからターミナルを起動し、lsofを使用してSSH_AUTH_SOCKの違いを確認できました。2つの異なるssh-agentsが見つかり、キーをロードできました(ssh-add)システムのデフォルトのssh-agent(つまり/usr/bin/ssh-agent)に入れると、SourceTreeは再び機能していました。

0
Hvisage

SSHエラーが発生する理由はさまざまです。

sign_and_send_pubkey:署名に失敗しました:エージェントが操作を拒否しました

それらの一部は、他の回答(このスレッドの回答を参照)で強調表示された問題に関連している可能性があり、一部は非表示になっている可能性があるため、詳細な調査が必要です。

私の場合、次のエラーメッセージが表示されます。

sign_and_send_pubkey:署名に失敗しました:エージェントが操作を拒否しました

[email protected]:許可が拒否されました(publickey、gssapi-keyex、gssapi-with-mic)

実際の問題を見つける唯一の方法は、-v verboseオプションを呼び出すことで、これにより多くのデバッグ情報が出力されます。

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

key_load_public: No such file or directoryという行は、前の行ではなく次の行を参照していることに注意してください。

SSHが本当に言うのは、id_rsa.website.domain.com-certという名前の公開鍵ファイルが見つからなかったということです。私の公開鍵ファイルには-cert接尾辞が含まれていなかったため、これが問題のようです。

簡単に言えば、私の場合の修正は、公開鍵ファイルが期待どおりに命名されていることを確認することでした。接続をデバッグすることなく、それを疑うことはできませんでした。

一番下の行はSSH冗長モードを使用(-vオプション)で、何が間違っているかを判断します。さまざまな理由が考えられますが、このスレッドまたは別のスレッドでは見つかりません。

0

私もsign_and_send_pubkey: signing failed: agent refused operationエラーを受け取りました。しかし、私の場合、問題は間違ったpinentryパスでした。

${HOME}/.gnupg/gpg-agent.confでは、pinentry-programプロパティは古いpinentryパスを指していました。そこでパスを修正し、gpg-agentを再起動すると修正されました。

ログをjournalctl -fでたどることで発見しました。間違ったパスを含む次のようなログ行があります:

Jul 02 08:37:50 my-Host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-Host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed
0
h3nrik

私にとって問題は、Gitlabへの公開鍵の間違ったコピー/ペーストでした。コピーは余分なリターンを生成しました。貼り付けるものが1行のキーであることを確認してください。

0
daniel sp

はい。クライアントマシンでssh-addを実行します。次に、コマンドを繰り返しますssh-copy-id [email protected]

0