web-dev-qa-db-ja.com

SSHキーを削除する方法？

私は現在、古いSSHキーをサーバーにアップロードしました。問題は、（元の~/.sshおよびid_rsaファイルと共に）id_rsa.pubディレクトリを失ったことです。

そのため、サーバー上で古いSSHキーを直接削除し、新しいものをアップロードする必要があります。

私は成功せずに次のコマンドを試してみました：

$> ssh-add -D

enter image description here

SSHキーを完全に削除する方法はありますか？

gitsshgit-svnssh-keysssh-keygen
106
user1364743

ssh-add -d/-Dnotキーの削除について、少なくとも2つのバグ報告があることに注意してください。

正確な問題は、

ssh-add -d/-Dはgnome-keyringから手動で追加されたキーのみを削除します。
自動的に追加されたキーを削除する方法はありません。
これは最初のバグです。まだ存在しています。

したがって、たとえば、2つの異なるGitHubアカウントに関連付けられた2つの異なる自動ロードされたssh IDがある場合（職場用と自宅用など）、no wayに切り替えます。それらの間の。 GitHubは最初にマッチしたものを取るので、あなたはいつもGitHubにあなたの「ホーム」ユーザーとして現れ、仕事のプロジェクトにものをアップロードする方法はありません。

ssh-add -dをautomatic-loadedkeys（およびssh-add -t Xに自動ロードされたキーの有効期間を変更する）に適用すると、ほとんどのユーザーが期待する動作に戻ります。

より正確には、問題について：

原因はgpg-keyring-daemonです。

  • それはssh-agentの通常の操作を覆します、大抵それはあなたが暗号化されたsshキーのためのパスフレーズをタイプすることができるきれいなボックスをポップアップすることができるようにちょうどそのようにします。
  • そしてそれはあなたの.sshディレクトリを通って進み、見つけたキーをあなたのエージェントに自動的に追加します。
  • そしてそれはあなたがそれらのキーを削除させないでしょう。

どうしてこれが嫌いですか？方法を数えないでください - 人生は短すぎます。

新しいsshクライアントは、ホストに接続するときにssh-agentのすべてのキーを自動的に試すので、失敗は複雑になります。
多すぎる場合、サーバーは接続を拒否します。
そして、gnome-keyring-daemonはあなたが自分のssh-agentに何個の鍵を持たせたいかを決め、それらを自動ロードしたので、それらを削除してはいけません。

このバグはUbuntu 14.04.4でもまだ2日前（2014年8月21日）に確認されています

考えられる回避策：

  • 手動で追加したキーをすべて削除するには、ssh-add -Dを実行します。これは自動的に追加されたキーもロックしますが、gnome-keyringを実行しようとするとgit Pushがキーのロック解除を要求するので、あまり役に立ちません。
  • ~/.sshフォルダに移動して、識別したいもの以外のすべての重要なファイルをbackupという別のフォルダに移動します。必要に応じて、タツノオトシゴを開けてそこから鍵を削除することもできます。
  • これで、問題なくgit Pushを実行できるはずです。

別の回避策：

本当にやりたいことは、gpg-keyring-daemonを完全にオフにすることです。
System --> Preferences --> Startup Applicationsに行き、「SSH Key Agent (Gnome Keyring SSH Agent)」ボックスの選択を解除します - それを見つけるには下にスクロールする必要があります。

それでもssh-agentを取得することができますが、今は正常に動作します。キーの自動ロードはありません。キーを追加するためにssh-addを実行します。キーを削除する場合は可能です。想像してみろ。

このコメント は実際に次のことを示唆しています。

解決策は、gnome-keyring-managerが起動しないようにすることです。これは、プログラムファイルの実行権限を削除することによって最終的に達成されるため、奇妙に困難でした。

94
VonC

私が誤解しない限り、あなたはあなたのローカルマシン上のあなたの秘密鍵を含んでいるあなたの.sshディレクトリを失ったので、あなたはサーバー上にありそして鍵ベースのログインを許可した公開鍵を削除したいです。その場合は、サーバー上のホームディレクトリの.ssh/authorized_keysファイルに保存されます。このファイルをテキストエディタで編集して、識別できる場合は関連する行を削除するだけです（唯一のエントリであればさらに簡単です）。キーがサーバーへの唯一のアクセス方法ではなかったこと、そしてログインしてファイルを編集する方法が他にあることを願います。手動でauthorised_keysファイルに新しい公開鍵を追加するか、ssh-copy-idを使用することができます。どちらの方法でも、サーバー上のアカウントにpassword authを設定するか、サーバー上のauthorized_keysファイルにアクセスするための他のIDまたはアクセス方法が必要になります。

ssh-addはあなたのsshエージェントにあなたのアイデンティティの管理をローカルに処理する「sshエージェント」へのアイデンティティを追加します、そして「エージェントへの接続はSSHリモートログインを通して転送されます。 （manページ）、だから私はそれがこの場合あなたが望むものだとは思わない。私の知る限りではsshログインを介してサーバーにアクセスすることなく公開鍵をサーバーに取得する方法はありません。

6
Tim

Unityで "Passwords and Keys"アプリケーションを開いて、セキュアキー - >OpenSSHキーから不要なキーを削除しましたそしてそれらは自動的にssh-agent -lからも削除されました。

4
Anton Balashov

Ssh関連の操作を実行しようとしていて次のエラーが発生した場合：

$ git fetch
no such identity: <ssh key path>: No such file or directory

次のようにして、不足しているsshキーをsshエージェントから削除できます。

$ eval `ssh-agent -s`  # start ssh agent
$ ssh-add -D <ssh key path>  # delete ssh key
4
Derek Soike

このバグはまだUbuntu 19.04に存在することを確認できます。 @VonCによって提案された回避策は完全に機能し、私のバージョンを要約しています。

  • 左上の[アクティビティ]タブをクリックします
  • 表示される検索ボックスで、「スタートアップアプリケーション」と入力し始めます
  • 「アプリケーションの起動」アイコンをクリックします
  • 表示されたボックスで、gnomeキーリングマネージャーアプリケーションを選択し（GUIで正確な名前を覚えることはできませんが、十分な特徴があるため）、削除します。

次にssh-add -Dを再試行し、再起動後ssh-add -lが私に言ったエージェントにはIDがありません。ssh-agentデーモンがまだあることを確認しましたps aux | grep agentで実行しています。そこで、GitHubで最も頻繁に使用するキー（ssh-add ~/.ssh/id_ecdsa）を追加しましたが、すべてうまくいきました！

これで、最も頻繁に使用するリポジトリで通常の操作を実行できます。RSAキーを使用する他のリポジトリへのアクセスが必要な場合は、export GIT_SSH_COMMAND="ssh -i /home/me/.ssh/id_rsa.pub"で1つのターミナルを専用にします。解決しました！バグと解決策を指摘した功績は@VonCにあります。

1
Nagev