Właśnie zaktualizowałem swój system Ubuntu z 15.10 do 16.04, całkowicie usuwając partycję Ubuntu 15 z mojego systemu.

Po zainstalowaniu Ubuntu 16.04 odtworzyłem moje klucze ssh, gdy zapomniałem je wykonać, ale za każdym razem, gdy próbuję użyć ssh, dostaję sign_and_send_pubkey: signing failed: agent refused operationto nieco denerwujące, ponieważ pozwala mi przejść do mojego serwera ssh, ale git odmawia wypychania kodu za pomocą ssh.

Już pchnąłem klucze do serwera za pomocą ssh-copy-id.

Serwer, z którym się łączę, to serwer Ubuntu 16.04 uaktualniony za pomocą do-release-upgradepolecenia. Każda pomoc będzie mile widziana.

Wygląda na ssh-agentto, że już działa, ale nie można znaleźć dołączonych kluczy. Aby rozwiązać ten problem, dodaj tożsamość klucza prywatnego do agenta uwierzytelniania w następujący sposób:

ssh-add

Następnie możesz sshwejść na swój serwer.

ponadto możesz zobaczyć listę odcisków palców wszystkich tożsamości dodanych obecnie przez:

ssh-add -l

Proste rozwiązanie

Miałem ten sam problem na Ubuntu 18.04. To wszystko dotyczy uprawnień klucza prywatnego po stronie klienta .

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

Uprawnienia do plików były zbyt otwarte (0644).

Następujące polecenie rozwiązało to:

chmod 600 ~/.ssh/id_rsa

Miałem ten sam problem (te same objawy)

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

... ale rozwiązanie było inne.

Problem pochodził z używania GNOME-KEYRING. Post dotyczący rozwiązania można przeczytać tutaj .

W skrócie:

1. Wykryj problem, dodając SSH_AUTH_SOCK = 0 przed poleceniem ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. W przypadku udanego połączenia. Otwórz aplikację StartUp Application (na przykład używając funkcji wyszukiwania na pulpicie) i wyłącz korzystanie z gnome-keyring.
3. Restart

Strona zawiera inne szczegóły w przypadku podobnego problemu z innym rozwiązaniem.

Dostawałem się sign_and_send_pubkey: signing failed: agent refused operationpodczas logowania na kilka serwerów, przeczytałem odpowiedź VonC na temat Przepełnienia stosu, aby uzyskać więcej informacji na temat powiązanych błędów, rozwiązaniem było dla mnie usunięcie klucza gnome, usunięcie tożsamości z ssh-agent i ponowne uruchomienie.

sudo apt-get autoremove gnome-keyring
ssh-add -D

Potem wszystkie moje klucze zaczęły działać idealnie.

AKTUALIZACJA:

Tymczasowe rozwiązanie bez odinstalowywania kluczy

Jeśli chcesz zachować gnome-keyring i masz agent refused operationbłąd, użyj:

eval `ssh-agent -s`
ssh-add

albo użyj SSH_AUTH_SOCK=0 ssh your-server

Trwałe rozwiązanie bez odinstalowywania kluczy

Jeśli możesz, gnome-keyring jest kompatybilny z 4096-bitowym kluczem RSA, więc po prostu wygeneruj nowy klucz z:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Prześlij klucz publiczny na serwer

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

Dodaj klucz ssh do agenta

ssh-add ~/.ssh/your-key-name

Powinno to działać bez żadnych dodatkowych włamań, a breloczek do gnome może pozostać zainstalowany.

(Opcja -C [nazwa użytkownika] jest opcjonalna, ale wymagana przez dostawców takich jak Google Cloud)

Po aktualizacji do Ubuntu 18.04 otrzymałem ten sam błąd sign_and_send_pubkey: signing failed: agent refused operation. Okazuje się, że było to spowodowane zbyt otwartymi uprawnieniami klucza ssh. Poniższe polecenie naprawiło problem chmod 600 .ssh/id_rsa

W moim systemie (także Ubuntu 16.04, próbującym połączyć się z githubem) miałem plik id_ed25519 w moim folderze .ssh, który spowodował błąd ssh-add:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

Po usunięciu plików ~/.ssh/id_ed25519*(już ich nie potrzebowałem, to z wcześniejszego testu) wszystko poszło dobrze.

Zdarzyło mi się, ponieważ mój klucz prywatny miał hasło. Musiałem uruchomić, ssh-adda następnie poprosił o hasło i dodano poprawnie. Jednak teraz nie prosi o moje hasło podczas wysyłania do komputera.

Mam nową instalację Ubuntu16.04 i napotkałem podobne problemy. Kiedy próbowałem sklonować moje repozytorium z Github po skopiowaniu mojego klucza publicznego do github (zgodnie z instrukcjami na github.com ) i po przeprowadzeniu następującej kontroli ( zalecane na github.com ):

ssh -T git@github.com

Zostałem powitany przez:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

Aby to naprawić szybko, bez usuwania czegokolwiek lub zmiany konfiguracji uruchamiania, po prostu wpisałem w terminalu:

killall gnome-keyring-daemon

Potem klon zadziałał. Następnie ponownie uruchomiłem zatrzymanego demona, wpisując:

gnome-keyring-daemon

Później, aby zmienić rzeczy w bardziej trwały sposób, skorzystałem z porady tutaj

Po aktualizacji Fedory 26 do 28 napotkałem ten sam problem. I żadnych plików dziennika

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

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 rzeczywistego problemu. Problem rozwiązany przez

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

Dodanie komentarza, ponieważ miałem ten sam problem z kluczami ed25519. Problem jest rzeczywiście kluczem do gnoma. Aby to naprawić, wykonałem następujące czynności:

• Niezaznaczony ssh-key-agent (gnome-keyring) w „aplikacjach startowych”
• Zabito agenta ssh i agenta gnome: (killall ssh-agent; killall gnome-keyring-daemon)
• Uruchom ponownie demona: (eval ssh-agent -s)
• Dodaj swój klucz: $ ssh-add id_ed25519 Wprowadź hasło dla id_ed25519: Dodano tożsamość: id_ed25519
• Zysk!!

Jest koniec 2018 roku, a ten błąd lub jego odmiany nadal nękają Xubuntu 16.04 i bardziej niż prawdopodobne inne smaki Xenial. Nie zdziwiłbym się, gdyby istniał również w 18.04! Jest w jakiejś formie od 2009 roku i Karmic Koala. Wpłynął na Redhat, Debian i Ubuntu. Nie wierz mi na słowo, zobacz publiczne narzędzia do śledzenia błędów:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

Przy tym błędzie znajdziesz również listę pozostałych 3:

Bibliografia:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

W moim przypadku najbardziej oczywistym objawem była niemożność użycia kluczy ssh z hasłami. Może to również wpłynąć na te bez nich, ponieważ awaria uniemożliwia ładowanie kluczy SSH! I nie miałem problemów z uprawnieniami, wszystko było kluczem od gnome. Moje klucze (tak, odmówiono kilku, dla różnych serwerów SSH!) Wszystkie miały uprawnienia 600 (rw dla właściciela, nic dla grupy lub inne), jak podano w wielu odpowiedziach na ten temat. Nic więc nie mogłem tam zmienić.

W Xubuntu istnieje sposób na wyłączenie elementów startowych. Zwykle jest to również możliwe w Unity / Gnome / KDE, ale nie mam tych zainstalowanych, więc nie mogę podać konkretnych kroków. Nie jestem pewien innych komputerów stacjonarnych. Zamiast wyłączać agenta SSH, agenta GPG i inne elementy Gnome, które powodują to i inne powiązane błędy, wyłączyłem wszystkie elementy startowe Gnome. Dla niektórych może to być przesada lub nie, ale SSH powraca do bezbłędnego działania przy następnym restarcie!

1. Otwórz menu główne Whisker -> Ustawienia -> Sesja i uruchomienie.
2. Kliknij kartę Zaawansowane, ostatnią po prawej stronie.
3. Odznacz (wyłącz) Uruchom Gnome Services podczas uruchamiania.
4. Zamknij i uruchom ponownie. Wylogowanie też może to zrobić, ale na pewno powinno nastąpić ponowne uruchomienie.

Zrzut ekranu z GUI opisanym powyżej:

Ponieważ więc podałem powyższą poprawkę, mam nadzieję, że ktoś ją naprawi.

Ubuntu okazało się, że nie udało się go zgnieść na dobre, ponieważ istnieje wiele biletów na kilka wydań, które twierdzą, że jest naprawiony, a więcej, które mówią „regresja”, wróciło.

Debian prawdopodobnie chce się obijać (umyć ręce), ponieważ to nie oni, na górze jest Gnome.

Redhat prawdopodobnie ma poprawkę dostępną tylko dla płacących klientów. Ponieważ historycznie Redhat jest największym pracodawcą opłacanych programistów Gnome, co na pierwszy rzut oka jest hojne. Dopóki nie zrozumiesz, że oznacza to, że mają oni motywację finansową, aby nigdy nie umieszczać takich poprawek w darmowych wersjach, aby nadal sprzedawać subskrypcje Redhat.

Gnome jest prawdopodobnie tymi, którzy mogą to naprawić najłatwiej, a następnie inni mogą testować i pakować, bez pisania linii kodu. Ale bilety, które czytam, mówią, że paczka wygasła od lat bez oficjalnego opiekuna! Dwie osoby, które teraz to robią dobrowolnie (dziękuję), są prawie tak samo zajęte projektowaniem zamiennika. Dlaczego nie naprawić płaskiej opony, nawet jeśli zajmuje to rok (minęła dekada!) Zamiast wymyślać najpierw koło ?!

ssh-add

pracuje dla mnie. Ale bądź pewien

ssh-agent

biegnie.

W moim przypadku problem został spowodowany przez GNOME Keyring. Aby wyłączyć możliwości SSH gnome-keyring bez bezpośredniego usuwania go (co psuje wiele rzeczy), postępuj zgodnie z tymi instrukcjami :

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

i zrestartuj sesję. Teraz możesz uruchomić ssh-agent bez ingerencji w gnome-keyring.

Próbowałem kilku rzeczy, między innymi ssh-add, resetowanie SSH (usuwanie .ssh / na serwerze itp.), Ale bez powodzenia. Więc okazało się, że musiałem się nad tym przespać przez jedną noc. Pomogło! Dlaczego? „Wydaje mi się, że ssh-agent działający na serwerze miał coś w pamięci podręcznej, która została odświeżona później tej nocy z właściwymi teraz wartościami. W każdym razie działa teraz jak urok. Podsumowując, zrobiła to (Ubuntu 16.04 na localhost, 14.04 na serwerze).

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)

Skończyło się upuszczanie mojego znanego pliku hosts i zadziałało. Musiałem ponownie wprowadzić hasło, ale w końcu zaakceptowało prawidłowe hasło. To było po nowej instalacji.

Jeśli dodanie SSH_AUTH_SOCK = 0 przed komendą ssh pomaga, oznacza to, że gnome to błąd klucza. Z wyjątkiem dostarczonych rozwiązań i problemów, problem może być związany z hasłem. Jeśli masz hasło do klucza, wówczas gnome keyring pyta o to przy pierwszym logowaniu, a jeśli wprowadzisz puste z winy lub nieoczekiwanie zamykając okno, gnome przyjmuje je jako puste hasło i pamięta je na zawsze. Nic nie pomaga w ponownym monitowaniu o hasło. Aby rozwiązać otwartą aplikację kluczy SSH i przejdź do sekcji Logowanie w kategorii Hasła. Znajdź rekord odpowiadający problematycznemu kluczowi i przejdź do Właściwości i wprowadź poprawne hasło.

Jest jeszcze jedna przyczyna, na którą nie ma jeszcze odpowiedzi: format PEM dla pliku kluczy przestał być domyślny, ssh-keygenzanim Ubuntu przeniósł się do gnome-keyring-daemonformatu obsługującego nowy format RFC4716.

Jeśli wygenerujesz nowy klucz lub dodasz / usuniesz hasło z klucza, może się on złamać. Klawisz jest używany ssh-keygen -m PEMprzed jakąkolwiek inną operacją, którą musisz uruchomić. Na przykład, możesz przekonwertować z powrotem na stary format, używając ssh-keygen -m PEM -pi wprowadzając stare hasło jako nowe hasło (które byłoby puste bez hasła).