システムからUbuntu 15パーティションを完全に消去して、Ubuntuシステムを15.10から16.04にアップグレードしました。

Ubuntu 16.04をインストールした後、バックアップを忘れたためsshキーを再作成しましたが、sshを使用しようとするsign_and_send_pubkey: signing failed: agent refused operationと、sshサーバーにアクセスできますが、gitはsshを使用したコードのプッシュを拒否します。

を使用して、すでにキーをサーバーにプッシュしましたssh-copy-id。

接続しているサーバーは、do-release-upgradeコマンドを使用してアップグレードされたUbuntu 16.04サーバーです。どんな助けも大歓迎です。

ssh-agentがすでに実行されているように見えますが、接続されているキーが見つかりません。これを解決するには、次のように秘密鍵IDを認証エージェントに追加します。

ssh-add

その後ssh、サーバーにアクセスできます。

さらに、現在追加されているすべてのIDの指紋のリストを表示できます。

ssh-add -l

シンプルなソリューション

Ubuntu 18.04でも同じ問題が発生しました。以上がクライアント側の秘密キーのアクセス許可です。

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

ファイルのアクセス許可が開いていました（0644）。

次のコマンドで解決しました：

chmod 600 ~/.ssh/id_rsa

同じ問題がありました（同じ症状）

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

...しかし、解決策は異なっていました。

問題はGNOME-KEYRINGの使用に起因していました。解決策について言及している記事は、ここで読むことができます。

要するに：

1. sshコマンドの前にSSH_AUTH_SOCK = 0を追加して、問題を検出します。sam @ xxxxx：〜/ .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. 接続に成功した場合。（たとえばデスクトップの検索機能を使用して）アプリケーションStartUp Applicationを開き、gnome-keyringの使用を無効にします。
3. リブート

このページには、別のソリューションで同様の問題が発生した場合のその他の詳細が記載されています。

私はなっていたsign_and_send_pubkey: signing failed: agent refused operationいくつかのサーバーにログインするときに、読んでスタックオーバーフローにVonCの答えを私のためのソリューションは、ssh-agentのとrebootからIDを削除、GNOME-キーリングを削除することでした、関連のバグの詳細については。

sudo apt-get autoremove gnome-keyring
ssh-add -D

その後、すべてのキーが完全に機能し始めました。

更新：

キーリングをアンインストールしない一時的なソリューション

gnome-keyringを保持したいがagent refused operationエラーがある場合は、次を使用します。

eval `ssh-agent -s`
ssh-add

または使用する SSH_AUTH_SOCK=0 ssh your-server

キーリングをアンインストールせずに永続的なソリューション

できれば、gnome-keyringは4096ビットRSAキーと互換性があるため、次のように新しいキーを生成するだけです。

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

公開鍵をサーバーにアップロードします

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

sshキーをエージェントに追加します

ssh-add ~/.ssh/your-key-name

これは追加のハッキングなしで機能し、gnome-keyringはインストールされたままになります。

（-C [ユーザー名]はオプションですが、Google Cloudなどのプロバイダーでは必須です）

Ubuntu 18.04にアップグレードした後、同じエラーが発生しましたsign_and_send_pubkey: signing failed: agent refused operation。sshキーの許可が開きすぎていることが原因であることがわかりました。次のコマンドは私のために問題を修正しました chmod 600 .ssh/id_rsa

私のシステム（githubに接続しようとしているUbuntu 16.04も）では、.sshフォルダーにid_ed25519というファイルがあり、ssh-add失敗しました。

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

ファイルを削除した後~/.ssh/id_ed25519*（それらはもう必要ありませんでした、以前のテストからのものでした）、すべてが再びうまくいきました。

私の秘密鍵にパスフレーズが含まれていたため、私に起こりました。実行する必要がssh-addあり、それからパスフレーズを要求し、正しく追加しました。ただし、マシンにsshするときにパスフレーズを要求しないようになりました。

Ubuntu16.04を新規インストールしましたが、同様の問題が発生しました。公開鍵をgithubにコピーした後（github.comの指示に従って）、次のチェックを実行した後（github.comで推奨）、Githubからリポジトリをクローンしようとしたとき：

ssh -T git@github.com

次のように迎えられました。

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

何かを削除したり、スタートアップ構成を変更したりせずにすばやく修正するには、ターミナルに次のように入力しました。

killall gnome-keyring-daemon

その後、クローンが機能しました。次に、次のように入力して、停止したデーモンを再起動しました。

gnome-keyring-daemon

後で、より永続的な方法で物事を変更するために、私はここのアドバイスに従いました

Fedora 26を28にアップグレードした後、同じ問題に直面しました。ログファイルなし

no /var/log/secure
no /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/*

ed25519キーで同じ問題が発生したため、コメントを追加します。問題は確かにgnome-keyringです。これを修正するために、次のことを行いました。

• 「スタートアップアプリケーション」の未チェックのssh-key-agent（gnome-keyring）
• ssh-agentとgnomeエージェントを強制終了：（killall ssh-agent; killall gnome-keyring-daemon）
• デーモンを再起動しました：（eval ssh-agent -s）
• キーを追加：$ ssh-add id_ed25519 id_ed25519のパスフレーズを入力：追加されたID：id_ed25519
• 利益!!

それは2018年後半であり、このバグまたはそのバリエーションは、Xubuntu 16.04、およびおそらく他のXenialのフレーバーよりも悩んでいます。18.04にも存在していても驚かないでしょう！それは2009年から何らかの形で出回っていて、Karmic Koalaです。Redhat、Debian、Ubuntuに影響を与えました。私の言葉を受け入れないでください、公開バグトラッカーを参照してください：

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

そして、そのバグには、他の3つのリストもあります。

参照：

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

私の場合、最も明らかな症状は、パスフレーズでsshキーを使用できないことでした。誤動作によりsshキーがまったくロードされないため、影響のないものにも影響する可能性があります！そして、許可の問題はありませんでした。それはすべてgnome-keyringでした。私の鍵（異なるSSHサーバーに対してはいくつか拒否しました！）パーミッションはすべて600でした（所有者にはrw、グループやその他には何もありません）。そこで、私はそこで何も変えることができませんでした。

Xubuntuには、スタートアップアイテムを無効にする方法があります。通常、Unity / Gnome / KDEでも可能ですが、これらはインストールされていないため、具体的な手順を説明することはできません。他のデスクトップについてはわかりません。SSHエージェント、GPGエージェント、およびこれを引き起こすGnomeのその他のアイテム、およびその他の関連するバグを無効にするのではなく、すべてのGnomeスタートアップアイテムをオフにしました。やりすぎかもしれませんし、一部の人にとっては選択肢ではないかもしれませんが、SSHは次回の再起動時に問題なく動作するようになりました！

1. Whisker Main Menu-> Settings-> Session and Startupを開きます。
2. 右側の最後の[詳細設定]タブをクリックします。
3. 起動時にGnomeサービスをオフ（オフ）にします。
4. 閉じて再起動します。ログアウトすることもできますが、確実に再起動する必要があります。

上記のGUIのスクリーンショット：

したがって、上記の修正を行ったので、誰かが修正することを願っています。

Ubuntuは、それが修正されたと主張するいくつかのリリースのチケットがたくさんあるので、それを完全につぶすことに失敗したと証明されています。

Debianはおそらくパント（手を洗う）を望んでいるのは、彼らではないからです。上流はGnomeです。

Redhatには、有料のお客様のみが利用できる修正プログラムがあります。歴史的に、Redhatは有料のGnome開発者の最大の雇用主であり、一見寛大だからです。それに気付くまでは、Redhatサブスクリプションの販売を継続するために、無料バージョンにこのような修正を加えない金銭的インセンティブがあることを意味します。

おそらくGnomeは上流で最も簡単に修正できる人であり、他の人はコード行を書かずにテストしてパッケージ化できます。しかし、私が読んだチケットは、公式のメンテナーなしでパッケージが何年も衰退したと言っています！そして、今自発的にそうしている二人（ありがとう）は、代替品の設計にほとんど忙しいです。最初にホイールを再発明するのではなく、1年（10年）かかってもパンクしたタイヤを修理してみませんか？！

ssh-add

私のために働く。しかし、確認してください

ssh-agent

が走っています。

私の場合、この問題はGNOMEキーリングが原因でした。するには無効にあからさまなしのgnome-キーリングのSSH機能を取り除く（たくさんのことを壊した）それを、続く手順に：

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

そしてセッションを再開します。これで、gnome-keyringの干渉なしでssh-agentを実行できます。

いくつかのことを試してみましたが、特にssh-add、SSHのリセット（サーバー上の.ssh /の削除などがありましたが、運はありませんでした。 ？サーバーで実行されているssh-agentのキャッシュに何かあったので、その夜に適切な値に更新されたと思います。とにかく、今では魅力のように動作します。サーバーで14.04）。

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)

最終的に、既知のhostsファイルをドロップし、機能しました。もう一度パスワードを入力する必要がありましたが、最終的に正しいパスワードを受け入れました。新規インストール後です。

sshコマンドが役立つ前にSSH_AUTH_SOCK = 0を追加すると、gnome keyring faultになります。提供されたソリューションと問題を除き、問題はパスフレーズに関連している可能性があります。キーのパスフレーズがある場合、gnome keyringは、初めてログインするときにパスフレーズを要求し、障害または予期せずウィンドウを閉じて空を入力すると、gnomeはそれを空のパスフレーズと見なし、永久に記憶します。パスフレーズの入力を再度求められることはありません。開いているsshキーリングアプリを解決し、[パスワード]カテゴリの[ログイン]セクションに移動します。問題のあるキーに対応するレコードを検索し、プロパティに入力して、正しいパスフレーズを入力します。

この別の原因にはまだ答えがありません。キーファイルのPEM形式は、ssh-keygenUbuntu gnome-keyring-daemonが新しいRFC4716形式をサポートするに移行する前のデフォルトではなくなりました。

新しいキーを生成するか、キーにパスフレーズを追加/削除すると、破損する可能性があります。キーはssh-keygen -m PEM、実行する必要がある他の操作の前に使用します。たとえばssh-keygen -m PEM -p、古いパスフレーズを新しいパスフレーズとして使用して入力することで、古い形式に戻すことができます（パスフレーズがない場合は空になります）。