現在、古い SSH キーをサーバーにアップロードしています。~/.ssh問題は、ディレクトリを失ったことです(元のファイルid_rsaとid_rsa.pubファイルを含む)。
したがって、古い SSH キーをサーバー上で直接削除し、新しいものをアップロードしたいと考えています。
次のコマンドを試しましたが成功しませんでした:
$> ssh-add -D

SSH キーを完全に削除する方法はありますか?
現在、古い SSH キーをサーバーにアップロードしています。~/.ssh問題は、ディレクトリを失ったことです(元のファイルid_rsaとid_rsa.pubファイルを含む)。
したがって、古い SSH キーをサーバー上で直接削除し、新しいものをアップロードしたいと考えています。
次のコマンドを試しましたが成功しませんでした:
$> ssh-add -D

SSH キーを完全に削除する方法はありますか?
キーを削除しssh-add -d/-D ないことについて、少なくとも 2 つのバグ レポートがあることに注意してください。
ssh-add -Dから削除しないgnome-keyring-daemon"ssh-add -Dすべての ID を削除しても機能しません。また、すべての ID が自動追加されるのはなぜですか?」正確な問題は次のとおりです。
ssh-add -d/-Dgnome-keyring から手動で追加されたキーのみを削除します。
自動的に追加されたキーを削除する方法はありません。
これは元のバグであり、まだ確実に存在しています。したがって、たとえば、2 つの異なる GitHub アカウント (職場用と自宅用など) に関連付けられた、自動的に読み込まれる 2 つの異なる ssh ID がある場合、それらを切り替える方法はありません。GitHub は最初に一致したものを取得するため、GitHub では常に「ホーム」ユーザーとして表示され、作業プロジェクトにアップロードする方法はありません。
自動的に読み込まれる
ssh-add -dキーに適用できるようにする(および自動的に読み込まれるキーの有効期間を変更する) と、ほとんどのユーザーが期待する動作が復元されます。ssh-add -t X
より正確には、問題について:
犯人は
gpg-keyring-daemon次のとおりです。
- これは ssh-agent の通常の操作を妨害します。ほとんどの場合、暗号化された ssh キーのパスフレーズを入力できるきれいなボックスをポップアップできるようにするためです。
- そして、
.sshディレクトリを調べて、見つかったキーをエージェントに自動的に追加します。- そして、それらのキーを削除することはできません。
どうやってこれを嫌うのですか?方法を数えないようにしましょう。人生は短すぎます。
新しい ssh クライアントは、ホストに接続するときに ssh-agent 内のすべてのキーを自動的に試行するため、失敗はさらに複雑になります。
数が多すぎると、サーバーは接続を拒否します。
また、gnome-keyring-daemon は、ssh-agent に必要なキーの数を自分で決定し、それらを自動ロードし、それらを削除させないので、乾杯します。
このバグは、2 日前 (2014 年 8 月 21 日) まで、Ubuntu 14.04.4 でも確認されています。
考えられる回避策:
- 手動で追加
ssh-add -Dしたすべてのキーを削除します。これにより、自動的に追加されたキーもロックされますが、.gnome-keyringgit push- フォルダー
~/.sshに移動し、識別したいファイルを除くすべての重要なファイルをバックアップと呼ばれる別のフォルダーに移動します。必要に応じて、seahorse を開いてそこからキーを削除することもできます。git pushこれで、問題なく実行できるはずです。
別の回避策:
gpg-keyring-daemonあなたが本当にやりたいことは、完全にオフにすることです。
に移動しSystem --> Preferences --> Startup Applications、「SSH Key Agent (Gnome Keyring SSH Agent)」ボックスの選択を解除します。見つけるには、下にスクロールする必要があります。
ssh-agentキーは自動ロードされず、ssh-add を実行してキーを追加します。キーを削除したい場合は削除できます。想像してみろ。
このコメントは実際には次のことを示唆しています。
解決策は
gnome-keyring-manager起動しないようにすることですが、これはプログラム ファイルの実行権限を削除することによって最終的に達成されたことで、妙に困難でした。
Ryan Lueは、別の興味深いコーナー ケースをコメントに追加しています。
これが誰かに役立つ場合:ファイル
id_rsaとid_rsa.pubファイルを完全に削除しようとしましたが、キーはまだ表示されていました。それらをファイル
gpg-agentにキャッシュしていた~/.gnupg/sshcontrolことが判明しました。そこから手動で削除する必要がありました。
私の誤解でない限り.ssh、ローカル マシン上の秘密鍵を含むディレクトリを紛失したため、サーバー上にあり、鍵ベースのログインを許可していた公開鍵を削除したいと考えています。
その場合、.ssh/authorized_keysサーバー上のホーム ディレクトリ内のファイルに保存されます。このファイルをテキスト エディターで編集し、関連する行を特定できる場合は削除するだけです (エントリが 1 つしかない場合はさらに簡単です)。
キーがサーバーにアクセスする唯一の方法ではなく、ログインしてファイルを編集する別の方法があることを願っています。新しい公開鍵を手動でauthorised_keysファイルに追加するか、 ssh-copy-id. いずれにせよ、サーバー上のアカウントにパスワード認証を設定するか、authorized_keysサーバー上のファイルにアクセスするためのその他の ID またはアクセス方法が必要です。
ssh-addローカルでアイデンティティの管理を処理するSSHエージェントにアイデンティティを追加し、「エージェントへの接続はSSHリモートログインを介して転送されるため、ユーザーはネットワーク内のどこでもアイデンティティによって与えられた特権を安全に使用できます。」(マニュアルページ)なので、この場合はそれが必要だとは思いません。私の知る限り、SSHログインを介してサーバーにアクセスせずに公開鍵をサーバーに取得する方法はありません。