web-dev-qa-db-ja.com

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

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

Ubuntu 16.04をインストールした後、バックアップを忘れたためsshキーを再作成しましたが、sshを使用しようとするとsign_and_send_pubkey: signing failed: agent refused operationが表示されます。 sshを使用したコード。

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

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

ssh16.04
168
Gamerb

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

ssh-add

その後、sshをサーバーに挿入できます。

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

ssh-add -l
311
Ron

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

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

$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation

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

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

chmod 600 ~/.ssh/id_rsa
53
Antonio Feitosa

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

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

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

問題はGNOME-KEYRINGの使用に起因していました。解決策に関する投稿は here と読むことができます。

要するに：

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

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

52
sam

複数のサーバーにログインするときにsign_and_send_pubkey: signing failed: agent refused operationを取得していました。関連するバグの詳細については、 VonCのStack Overflowの回答 を読んでください。エージェントと再起動。

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

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

UPDATE：

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

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 [email protected]

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

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

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

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

18
Mike

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

14
matthias

私のシステム（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*（それらはもう必要ありませんでした。以前のテストからのものでした）すべてが再びうまくいきました。

8
Daniel Alder

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

7
qwertzguy

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

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

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

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

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

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

ssh -T [email protected]

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

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

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

killall gnome-keyring-daemon

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

gnome-keyring-daemon

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

4
neiltheory

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
  • 利益!!
2
Matt

ssh-add

私のために働く。しかし、必ず

ssh-agent

が走っています。

1
kst

それは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=5767

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

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

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

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

Image

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

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

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

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

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

1
Lubo Diakov

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

0
possumkeys

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

0
Fazliddin Juraev

私の場合、この問題はGNOME Keyringが原因でした。 disablegnome-keyringのSSH機能を完全に削除せずにremoving多くのこと）、 これらの指示 に従ってください：

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

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

0
Norrius

いくつかのことを試してみましたが、特にssh-add、SSHのリセット（サーバー上の.ssh /の削除などがありましたが、運はありませんでした。そのため、1晩寝なければならなかったことがわかりました。 ？サーバーで実行されている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! :)
0
untill

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

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

0
Sam Brightman