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

110

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

ssh-copy-id [email protected]
/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
[email protected]'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
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 [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'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:

[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# 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.

user968270
źródło

Odpowiedzi:

195

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.

Oliver
źródło
7
Jezu, spędziłem dwie godziny próbując to naprawić i to wszystko! Naprawiono połączenia bitbucket i acquia ssh
Ronnie
19
Nie rozwiązało to całkowicie tego tutaj, ponieważ używam gpg-agentfunkcji SSH. Mam już enable-ssh-supportw gpg-agent.confale nadal ten sam komunikat o błędzie. Znalazłem na liście mailingowej, aby uruchomić to gpg-connect-agent updatestartuptty /bye:: bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394
Roland
1
Musiałem tylko zabić agenta gpg, a następnie uruchomić go ponownie.
Subin
3
Podczas generowania nowego klucza SSH ssh-addnależy go wywołać, aby program rozpoznałssh-agent nowy klucz prywatny (na linux.die.net/man/1/ssh-agent ).
Alex
Doskonale! Odtworzyłem swój klucz SSH i zaczęło się to dziać. Po ssh-addtym, jak zadziałało! Dzięki.
hbobenicio
65

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 [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
Anto
źródło
Mój .ssh/nie miał wymaganych uprawnień, ponieważ utworzyłem go samodzielnie.
Brent Bradburn
1
Wygląda na to, że w niektórych wersjach klucze nie są widoczne dla innych użytkowników. Dzięki!
alan ocallaghan
jeśli pliki .ssh / * są tworzone przez tego samego użytkownika (nie root), nie musimy się martwić, ponieważ będą miały wymagane uprawnienia.
Anto
1
Muszę cię docenić. Właśnie napotkałem ten problem. Twoja metoda rozwiązała problem.
Grunt
55

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ą.

Fernando Munoz
źródło
3
Napotkałem ten problem po migracji Ubuntu z 16.04 LTS na 18.04 LTS, to rozwiązanie zadziałało.
Munish Chandel
To samo tutaj, po aktualizacji Ubuntu do 18.04 napotkałem ten problem. To rozwiązanie to naprawi.
Cartucho
Kiedy id_rsa.pubjest używane w procesie uwierzytelniania klienta?
Dimitri Kopriwa
Jeśli masz wiele kluczy, powinieneś użyć czegoś takiego w środku ~/.ssh:chmod 600 id_*
lifeisfoo
10

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

U mnie to zadziałało.

chmod 600 ~/.ssh/id_rsa
krishna
źródło
5

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'"

SultanLegend
źródło
1
Dziękuję Ci. Miałem ten problem kilka dni temu, używam gpg tak jak ty i skomentowałem gpg-connect-agent updaterstartuptty /bye > /dev/nullmój ~ / .zshrc, odkomentowanie tej linii rozwiązało mój problem.
J.Adler
4

Do tego błędu:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: 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.

reinaldo pinto
źródło
2

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

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

Eugen Mihailescu
źródło
0

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.

Hvisage
źródło
0

Tak. Uruchom ssh-add na komputerze klienta. Następnie powtórz polecenie ssh-copy-id [email protected]

Kairat Koibagarov
źródło
0

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

daniel sp
źródło
0

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
0x7d7b
źródło
0

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 protected]"

gnome-keyring nie obsługuje wygenerowanego klucza.

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

Zależność
źródło
0

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.

Silverdr
źródło
0

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.

JPGConnolly
źródło
0

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

hastalapasta
źródło