Jak rozwiązać problem „sign_and_send_pubkey: podpisywanie nie powiodło się: agent odmówił operacji”?

Konfigurowanie nowej dropletu Digital Ocean z kluczami SSH. Kiedy biegnę ssh-copy-id, otrzymuję to:

ssh-copy-id user@012.345.67.89
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.

Jednak, gdy następnie spróbuję wejść przez ssh, dzieje się tak:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Po wprowadzeniu hasła jestem zalogowany w porządku, ale to oczywiście mija się z celem stworzenia klucza SSH w pierwszej kolejności. Postanowiłem rzucić okiem na serwer ssh-agent i oto co otrzymałem:

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

user / .ssh / authorised_keys również zawiera wpis klucza ssh-rsa, ale find -name "keynamehere"nic nie zwraca.

Uruchom ssh-addna komputerze klienta, który doda klucz SSH do agenta.

Potwierdź za pomocą ssh-add -l(ponownie na kliencie), że rzeczywiście został dodany.

Po aktualizacji Fedory 26 do 28 napotkałem ten sam problem. Brakowało następujących dzienników

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

KWESTIA:

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

komunikat o błędzie nie wskazuje na rzeczywisty problem. Problem rozwiązany przez

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

Miałem ten sam problem w Linuksie Ubuntu 18 . Po aktualizacji z Ubuntu 17.10 każde polecenie git powodowało wyświetlenie tego komunikatu.

Sposobem na rozwiązanie tego problemu jest upewnienie się, że masz odpowiednie uprawnienia do id_rsai id_rsa.pub.

Sprawdź aktualny numer chmod za pomocą stat --format '%a' <file>. Powinien wynosić 600 dla id_rsa i 644 dla id_rsa.pub.

Aby zmienić uprawnienia do plików, użyj

chmod 600 id_rsa
chmod 644 id_rsa.pub

To rozwiązało mój problem z aktualizacją.

Uruchom poniższe polecenie, aby rozwiązać ten problem.

U mnie to zadziałało.

chmod 600 ~/.ssh/id_rsa

Wystąpił błąd podczas używania gpg-agent jako mojego agenta ssh i używania podklucza gpg jako mojego klucza ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Podejrzewam, że problem był spowodowany błędnym wpisem pin tty dla gpg spowodowanym przez moje polecenie sleep + lock użyte w mojej konfiguracji sway

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

lub po prostu uśpienie / zawieszenie

Zresetuj pin wpis tty, aby rozwiązać problem

gpg-connect-agent updatestartuptty /bye > /dev/null

i poprawka dla mojego polecenia sway sleep + lock:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"

Do tego błędu:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Zweryfikuj lub dodaj ponownie klucz publiczny na koncie Github> profil> ssh.

Rozwiązałem tak:

# chmod 400 ~/.ssh/id_rsa

# ls  ~/.ssh/id_rsa -ls  
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26  2017 /home/reinaldo/.ssh/id_rsa

# git pull                                 
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.

Dziękuję Ci.

Może istnieć wiele powodów wystąpienia błędu SSH:

sign_and_send_pubkey: podpisanie nie powiodło się: agent odmówił operacji

Niektóre z nich mogą być związane z kwestiami, na które zwracają uwagę inne odpowiedzi (zobacz odpowiedzi w tym wątku), niektóre z nich mogą być ukryte i wymagałyby dokładniejszego zbadania.

W moim przypadku otrzymałem następujący komunikat o błędzie:

sign_and_send_pubkey: podpisanie nie powiodło się: agent odmówił operacji

user@website.domain.com: Permission denied (publickey, gssapi-keyex, gssapi-with-mic)

Jedynym sposobem znalezienia prawdziwego problemu było wywołanie opcji -v verbose, która spowodowała wydrukowanie wielu informacji debugujących:

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

Zwróć uwagę, że wiersz mówiący key_load_public: No such file or directoryodnosi się do następnego wiersza, a nie do poprzedniego.

Tak naprawdę SSH mówi, że nie może znaleźć pliku klucza publicznego o nazwie id_rsa.website.domain.com-certi wydawało się, że jest to problem w moim przypadku, ponieważ mój plik klucza publicznego nie zawiera -certsufiksu.

Krótko mówiąc: poprawka w moim przypadku polegała na upewnieniu się, że plik klucza publicznego został nazwany zgodnie z oczekiwaniami. Nigdy bym tego nie podejrzewał bez debugowania połączenia.

Najważniejsze jest UŻYJ TRYBU WERBOSE SSH (opcja -v), aby dowiedzieć się, co jest nie tak, mogą być różne przyczyny, których nie można znaleźć w tym / innym wątku.

To powinno być raczej pytanie SuperUser.

Tak, mam dokładnie ten sam błąd w MacOSX SourceTree, jednak w terminalu iTerm2 wszystko działa po prostu elegancko.

Jednak problem wyglądał na to, że mam uruchomione dwa ssh-agent ; (

Pierwsza istota /usr/bin/ssh-agent(aka MacOSX), a następnie zainstalowana HomeBrew /usr/local/bin/ssh-agent.

Uruchomienie terminala z SourceTree, pozwoliło mi zobaczyć różnice w SSH_AUTH_SOCK, używając lsofznalazłem dwa różne ssh-agents, a następnie mogłem załadować klucze (używając ssh-add) do domyślnego systemu ssh-agent(tj. /usr/bin/ssh-agent), SourceTree znów działało.

Tak. Uruchom ssh-add na komputerze klienta. Następnie powtórz polecenie ssh-copy-id userserver@012.345.67.89

Dla mnie problemem było złe skopiowanie / wklejenie klucza publicznego do Gitlab. Kopia wygenerowała dodatkowy zwrot. Upewnij się, że wklejasz klawisz jednowierszowy.

Mam również sign_and_send_pubkey: signing failed: agent refused operationbłąd. Ale w moim przypadku problem był złą pinentrydrogą.

W moim ${HOME}/.gnupg/gpg-agent.confdo pinentry-programobiektu wskazując na starą ścieżkę pinentry. Poprawienie tam ścieżki i ponowne uruchomienie gpg-agentnaprawiło to dla mnie.

Odkryłem to, śledząc dzienniki z journalctl -f. Tam, gdzie wiersze dziennika, takie jak poniższe, zawierają złą ścieżkę:

Jul 02 08:37:50 my-host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed

Muszę się podzielić, ponieważ spędziłem zbyt dużo czasu na poszukiwaniu rozwiązania

Oto rozwiązanie: https://unix.stackexchange.com/a/351742/215375

Użyłem tego polecenia:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyring nie obsługuje wygenerowanego klucza.

Usunięcie -oargumentu rozwiązało problem.

W moim przypadku problem polegał na tym, że plik kluczy GNOME przechował nieprawidłowe hasło do klucza ssh. Po spędzeniu nieprzyzwoitej ilości czasu na rozwiązywaniu tego problemu uruchomiłem seahorsei znalazłem wpis zawierający pusty ciąg. Mogę się tylko domyślać, że było to spowodowane błędnym wpisaniem hasła przy pierwszym użyciu jakiś czas wcześniej, a następnie prawdopodobnie anulowaniem requestera, aby wrócić do wiersza poleceń. Zaktualizowanie wpisu za pomocą prawidłowego hasła natychmiast rozwiązało problem. Usunięcie tego wpisu (z zestawu kluczy „login”) i ponowne wprowadzenie hasła przy pierwszym monicie (i zaznaczenie odpowiedniego pola wyboru) również rozwiązuje ten problem. Teraz agent otrzymuje poprawne hasło z odblokowanego przy logowaniu zestawu kluczy o nazwie „login” i nie pyta już o hasło ani nie „odmawia operacji”. Oczywiście YMMV.

Co tu zadziałało: na kliencie

1) ssh-add

2) ssh-copy-id użytkownik @ serwer

Klucze zostały utworzone jakiś czas temu za pomocą zwykłego "ssh-keygen -t rsa", zmieniłem komunikat o błędzie, ponieważ skopiowałem klucz publiczny ssh z klienta na serwer (z ssh-id-copy) bez uruchamiania najpierw ssh-add, ponieważ błędnie założyłem, że dodałem je jakiś czas wcześniej.

krótka uwaga dla tych, którzy niedawno dokonali aktualizacji do "nowoczesnej" wersji ssh [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 września 2019 r.] - dostarczane z fedorą 31, wydaje się, że nie akceptują już starych kluczy DSA SHA256 (moje są datowane na 2006 rok!) - utworzyłem nowy klucz rsa, publiczny dodany do autoryzowanego, prywatny na kliencie i wszystko działa idealnie.

dzięki za wcześniejsze sugestie, szczególnie ssh -v okazał się bardzo przydatny