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

SSHキーを使用して新しいDigital Ocean液滴を構成します。私が実行すると、ssh-copy-idこれは私が得るものです：

ssh-copy-id user@012.345.67.89
/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
user@012.345.67.89's password: 

Number of key(s) added: 1

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

しかし、次にsshでログインしようとすると、これが発生します。

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

パスワードを入力すると問題なくログインできますが、これはもちろん、最初にSSHキーを作成する目的に反します。私はサーバー側のssh-agentを確認することにしました。これは私が得たものです：

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

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

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

ssh-add -lそれが本当に追加されたことを（もう一度クライアントで）確認します。

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

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

問題：

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

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

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

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

それを解決する方法は、あなたが正しい権限を持っていることを確認することですid_rsaとid_rsa.pub。

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

ファイルの権限を変更するには

chmod 600 id_rsa
chmod 644 id_rsa.pub

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

この問題を解決するには、以下のコマンドを実行してください。

それは私のために働いた。

chmod 600 ~/.ssh/id_rsa

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

私の問題は、sway設定で使用されている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 sleep + lockコマンドの修正：

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

このエラーには：

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: 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.

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

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

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

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

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

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

user@website.domain.com：権限が拒否されました（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 VERBOSEモード（-vオプション）を使用して何が問題なのかを理解することです。さまざまな理由が考えられ、このスレッドや別のスレッドでは見つかりません。

これは、SuperUserの質問です。

MacOSX SourceTree内でもまったく同じエラーが発生しますが、iTerm2端末内では問題が発生します。

しかし、問題は私が実行している2つ ssh-agentのs を持っていることであるように見えました;（

最初の存在/usr/bin/ssh-agent（別名MacOSX）、次にHomeBrewがインストールされて/usr/local/bin/ssh-agent実行されます。

SourceTreeから端末を起動SSH_AUTH_SOCKするlsofと、2つの異なるを見つけてでの違いを確認ssh-agentできssh-add、システムのデフォルトssh-agent（つまり）にキーをロードでき/usr/bin/ssh-agent、SourceTreeが再び機能していました。

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

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

私が得たsign_and_send_pubkey: signing failed: agent refused operationとしても、エラーを。しかし、私の場合、問題は間違ったpinentry道でした。

私${HOME}/.gnupg/gpg-agent.confのpinentry-program所有物は古い入り口の道を指していた。そこでパスを修正し、再起動して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

解決策を探すのに多くの時間を費やしたので、共有する必要があります

これが解決策でした：https：//unix.stackexchange.com/a/351742/215375

私はこのコマンドを使用していました：

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyringは生成されたキーをサポートしていません。

-o議論を取り除くことで問題は解決した。

私の場合の問題は、GNOMEキーリングが使用するsshキーの無効なパスフレーズを保持していたことでした。この問題のトラブルシューティングにまともな時間を費やした後、私は実行してseahorse、空の文字列を保持するエントリを見つけました。最初の使用でパスフレーズを誤って入力し、コマンドラインにフォールバックするためにおそらくリクエスタなどをキャンセルしたことが原因であると推測できます。正しいパスフレーズでエントリを更新すると、すぐに問題が解決しました。（「ログイン」キーリングから）そのエントリを削除し、最初のプロンプトでパスフレーズを再入力すると（適切なチェックボックスをオンにすると）、これも解決されます。エージェントは、「login」という名前のロックされていないログインキーリングから正しいパスフレーズを取得し、パスフレーズを要求したり、「操作を拒否したり」することはありません。もちろんYMMV。

ここで機能したもの：クライアント

1）ssh-add

2）ssh-copy-id user @ server

しばらく前にプレーンな「ssh-keygen -t rsa」を使用してキーが作成されています。最初にssh-addを実行せずにssh公開キーをクライアントからサーバーに（ssh-id-copyを使用して）コピーしたため、エラーメッセージを表示します。私は誤ってそれらを少し前に追加したと思いました。

最近「最新」のsshバージョンにアップグレードする人のためのクイックノート[OpenSSH_8.1p1、OpenSSL 1.1.1d FIPS 10 Sep 2019]-fedora 31で提供され、古いDSA SHA256キーを受け入れなくなったようです（私の日付は2006年です！）-新しいrsa鍵を作成し、公開を許可に追加し、クライアントで非公開にすると、すべてが完全に機能します。

以前の提案に感謝します、特にssh -vはとても役に立ちました