Jak usunąć klucz SSH?

Obecnie mam przesłany na serwer stary klucz SSH. Problem polega na tym, że zgubiłem ~/.sshkatalog (z oryginałem id_rsai id_rsa.pubplikami).

W związku z tym chcę usunąć stary klucz SSH bezpośrednio na serwerze i przesłać nowy.

Bez powodzenia wypróbowałem następujące polecenie:

$> ssh-add -D

Czy istnieje sposób na całkowite usunięcie klucza SSH?

Należy pamiętać, że istnieje co najmniej dwa raport o błędzie do ssh-add -d/-D nie usuwania klawiszy:

• „ Raport błędu Debiana nr 472477: ssh-add -Dnie usuwa klucza SSH z gnome-keyring-daemonpamięci ”
• „ Ubuntu: ssh-add -Dusuwanie wszystkich tożsamości nie działa. Dlaczego wszystkie tożsamości są dodawane automatycznie? ”

Dokładny problem to:

ssh-add -d/-Dusuwa tylko ręcznie dodane klucze z gnome-keyring.
Nie ma możliwości usunięcia automatycznie dodanych kluczy.
To jest oryginalny błąd i nadal jest obecny.

Na przykład, jeśli masz dwie różne automatycznie ładowane tożsamości ssh powiązane z dwoma różnymi kontami GitHub - powiedzmy do pracy i do domu - nie ma możliwości przełączania się między nimi. GitHub wybiera pierwszy, który pasuje, więc zawsze pojawia się jako użytkownik „domowy” na GitHub, bez możliwości przesyłania rzeczy do projektów roboczych.

Zezwolenie ssh-add -dna zastosowanie do kluczy ładowanych automatycznie (i ssh-add -t Xzmiana czasu życia kluczy ładowanych automatycznie) przywróciłoby zachowanie oczekiwane przez większość użytkowników.

A dokładniej, o problemie:

Winowajcą jest gpg-keyring-daemon:

• Unieważnia to normalne działanie ssh-agent, głównie po to, aby wyświetlić ładne okno, w którym można wpisać hasło do zaszyfrowanego klucza ssh.
• Przeszukuje twój .sshkatalog i automatycznie dodaje wszystkie znalezione klucze do twojego agenta.
• I nie pozwoli ci usunąć tych kluczy.

Jak tego nienawidzimy? Nie liczmy dróg - życie jest za krótkie.

Niepowodzenie jest potęgowane, ponieważ nowsi klienci ssh automatycznie próbują wszystkich kluczy w ssh-agent podczas łączenia się z hostem.
Jeśli jest ich zbyt wiele, serwer odrzuci połączenie.
A ponieważ gnome-keyring-daemon sam zdecydował, ile kluczy ma mieć twój ssh-agent, i załadował je automatycznie I NIE POZWALA CI JE USUNĄĆ, jesteś wzniesiony.

Ten błąd jest nadal potwierdzony w Ubuntu 14.04.4, jeszcze dwa dni temu (21 sierpnia 2014)

Możliwe obejście:

• Zrób, ssh-add -Daby usunąć wszystkie ręcznie dodane klucze. To również blokuje automatycznie dodane klucze, ale nie jest to zbyt użyteczne, ponieważ gnome-keyringpoprosi cię o ich odblokowanie i tak, gdy spróbujesz zrobić git push.
• Przejdź do swojego ~/.sshfolderu i przenieś wszystkie kluczowe pliki z wyjątkiem tego, z którym chcesz się identyfikować, do oddzielnego folderu o nazwie kopia zapasowa. W razie potrzeby możesz również otworzyć konika morskiego i usunąć stamtąd klucze.
• Teraz powinieneś git pushsobie poradzić bez problemu.

Inne obejście:

To, co naprawdę chcesz zrobić, to gpg-keyring-daemoncałkowicie wyłączyć .
Przejdź do System --> Preferences --> Startup Applicationsi usuń zaznaczenie pola „ SSH Key Agent (Gnome Keyring SSH Agent)” - aby je znaleźć, musisz przewinąć w dół.

Nadal będziesz mieć ssh-agent, tylko teraz będzie zachowywał się normalnie: żadne klucze nie są ładowane automatycznie, uruchamiasz ssh-add, aby je dodać, a jeśli chcesz usunąć klucze, możesz. Wyobraź sobie, że.

Ten komentarz faktycznie sugeruje:

Rozwiązaniem jest zapobieganie gnome-keyring-manageruruchamianiu się, co było dziwnie trudne, gdy ostatecznie osiągnięto to poprzez usunięcie uprawnień do wykonywania pliku programu.

Ryan Lue dodaje w komentarzach kolejny interesujący przypadek narożny :

W przypadku, gdy pomaga nikomu: Próbowałem nawet usunięciem id_rsai id_rsa.pubpliki całkowicie, a klucz był nadal wyświetlane.

Okazało się, że gpg-agentbuforował je w ~/.gnupg/sshcontrolpliku ; Musiałem je stamtąd ręcznie usunąć.

Ma to miejsce wówczas, gdy został dodany jak tu .keygrip

Jeśli próbujesz wykonać operację związaną z ssh i pojawia się następujący błąd:

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

Możesz usunąć brakujący klucz ssh z agenta ssh w następujący sposób:

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

Chyba że źle zrozumiałem, zgubiłeś .sshkatalog zawierający klucz prywatny na komputerze lokalnym, więc chcesz usunąć klucz publiczny, który był na serwerze i który pozwalał na logowanie za pomocą klucza. W takim przypadku zostanie on zapisany w .ssh/authorized_keyspliku w Twoim katalogu domowym na serwerze. Możesz po prostu edytować ten plik za pomocą edytora tekstu i usunąć odpowiednią linię, jeśli możesz ją zidentyfikować (nawet łatwiej, jeśli jest to jedyny wpis!). Mam nadzieję, że ten klucz nie był Twoją jedyną metodą dostępu do serwera i masz inny sposób logowania się i edycji pliku. Możesz ręcznie dodać nowy klucz publiczny do authorised_keyspliku lub użyć go ssh-copy-id. Tak czy inaczej, musisz skonfigurować uwierzytelnianie hasłem dla swojego konta na serwerze lub inną tożsamość lub metodę dostępu, aby dostać się do authorized_keyspliku na serwerze.

ssh-adddodaje tożsamości do twojego agenta ssh, który obsługuje zarządzanie twoimi tożsamościami lokalnie, a „połączenie z agentem jest przekazywane przez zdalne logowanie SSH, dzięki czemu użytkownik może w bezpieczny sposób korzystać z uprawnień nadanych przez tożsamości w dowolnym miejscu w sieci”. (strona podręcznika), więc nie sądzę, że tego chcesz w tym przypadku. O ile wiem, nie ma sposobu, aby uzyskać klucz publiczny na serwerze bez dostępu do tego serwera przez login ssh.

Otworzyłem aplikację "Hasła i klucze" w moim Unity i usunąłem niechciane klucze z Secure Keys -> OpenSSH keys. Zostały one również automatycznie usunięte z ssh-agent -l .

Mogę potwierdzić, że ten błąd jest nadal obecny w Ubuntu 19.04. Obejście sugerowane przez @VonC działało idealnie, podsumowując dla mojej wersji:

• Kliknij kartę Działania w lewym górnym rogu
• W wyświetlonym polu wyszukiwania zacznij wpisywać „aplikacje startowe”
• Kliknij ikonę „Aplikacje startowe”
• W oknie, które się pojawi, wybierz aplikację gnome key ring manager (nie pamiętam dokładnej nazwy w GUI, ale jest wystarczająco charakterystyczna) i usuń ją.

Następnie spróbowałem ssh-add -Dponownie, a po ponownym uruchomieniu ssh-add -lpowiedział mi, że agent nie ma tożsamości. Potwierdziłem, że nadal mam ssh-agenturuchomionego demona ps aux | grep agent. Więc dodałem klucz, którego najczęściej używam z GitHub ( ssh-add ~/.ssh/id_ecdsa) i wszystko jest w porządku!

Teraz mogę wykonywać normalne operacje z moim najczęściej używanym repozytorium, a jeśli czasami potrzebuję dostępu do innego repozytorium, które używa klucza RSA, po prostu przeznaczam dla niego jeden terminal z export GIT_SSH_COMMAND="ssh -i /home/me/.ssh/id_rsa.pub". Rozwiązany! Podziękowania dla @VonC za wskazanie błędu i rozwiązania.

Sprawdź klucz .ssh, czy nie ma go w systemie

1. Przejdź do folderu -> /Users/administrator/.ssh/id_ed25519.pub

Jeśli nie, to

2. Otwórz Terminal.

Przeszłość w terminalu

3. Sprawdź użytkownika -> ssh -T [email protected]

Usuń istniejący klucz .ssh

4. Usuń istniejący klucz .ssh -> rm ~ / .ssh / github_rsa.pub

Tworzyć nowe

5. Utwórz nowy klucz .ssh -> ssh-keygen -t rsa -b 4096 -C "[email protected]"

6. Klucz publiczny został zapisany w „/Users/administrator/.ssh/id_ed25519.pub”.

7. Otwórz zapisaną ścieżkę klucza publicznego.
8. Skopiuj klucz .ssh -> Konto GitLab -> Ustawienia -> Klucz SSH -> Dodaj klucz
9. Przetestuj ponownie z terminala -> ssh -T [email protected]

Rozwiązaniem dla mnie (OpenSuse Leap 42.3, KDE) była zmiana nazwy folderu, ~/.gnupgktóry najwyraźniej zawierał buforowane klucze i profile. Po wylogowaniu / zalogowaniu się z KDE ssh-add / agent jest ponownie uruchomiony i folder jest tworzony od podstaw, ale stare klucze zniknęły.

Nie odniosłem sukcesu przy innych podejściach.