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.
ssh
remote-access
digital-ocean
ssh-keys
user968270
źródło
źródło
gpg-agent
funkcji SSH. Mam jużenable-ssh-support
wgpg-agent.conf
ale nadal ten sam komunikat o błędzie. Znalazłem na liście mailingowej, aby uruchomić togpg-connect-agent updatestartuptty /bye
:: bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394ssh-add
należy go wywołać, aby program rozpoznałssh-agent
nowy klucz prywatny (na linux.die.net/man/1/ssh-agent ).ssh-add
tym, jak zadziałało! Dzięki.Po aktualizacji Fedory 26 do 28 napotkałem ten sam problem. Brakowało następujących dzienników
KWESTIA:
komunikat o błędzie nie wskazuje na rzeczywisty problem. Problem rozwiązany przez
źródło
.ssh/
nie miał wymaganych uprawnień, ponieważ utworzyłem go samodzielnie.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_rsa
iid_rsa.pub
.Sprawdź aktualny numer chmod za pomocą
stat --format '%a' <file>
. Powinien wynosić 600 dlaid_rsa
i 644 dlaid_rsa.pub
.Aby zmienić uprawnienia do plików, użyj
To rozwiązało mój problem z aktualizacją.
źródło
id_rsa.pub
jest używane w procesie uwierzytelniania klienta?~/.ssh
:chmod 600 id_*
Uruchom poniższe polecenie, aby rozwiązać ten problem.
U mnie to zadziałało.
źródło
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'"
źródło
gpg-connect-agent updaterstartuptty /bye > /dev/null
mój ~ / .zshrc, odkomentowanie tej linii rozwiązało mój problem.Do tego błędu:
Rozwiązałem tak:
Dziękuję Ci.
źródło
Może istnieć wiele powodów wystąpienia błędu SSH:
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:
Jedynym sposobem znalezienia prawdziwego problemu było wywołanie opcji -v verbose, która spowodowała wydrukowanie wielu informacji debugujących:
Zwróć uwagę, że wiersz mówiący
key_load_public: No such file or directory
odnosi 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-cert
i wydawało się, że jest to problem w moim przypadku, ponieważ mój plik klucza publicznego nie zawiera-cert
sufiksu.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.
źródło
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ąclsof
znalazłem dwa różnessh-agent
s, a następnie mogłem załadować klucze (używającssh-add
) do domyślnego systemussh-agent
(tj./usr/bin/ssh-agent
), SourceTree znów działało.źródło
Tak. Uruchom ssh-add na komputerze klienta. Następnie powtórz polecenie ssh-copy-id [email protected]
źródło
Dla mnie problemem było złe skopiowanie / wklejenie klucza publicznego do Gitlab. Kopia wygenerowała dodatkowy zwrot. Upewnij się, że wklejasz klawisz jednowierszowy.
źródło
Mam również
sign_and_send_pubkey: signing failed: agent refused operation
błąd. Ale w moim przypadku problem był złąpinentry
drogą.W moim
${HOME}/.gnupg/gpg-agent.conf
dopinentry-program
obiektu wskazując na starą ścieżkę pinentry. Poprawienie tam ścieżki i ponowne uruchomieniegpg-agent
naprawił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ę:źródło
Muszę się podzielić, ponieważ spędziłem zbyt dużo czasu na poszukiwaniu rozwiązania
Użyłem tego polecenia:
gnome-keyring nie obsługuje wygenerowanego klucza.
Usunięcie
-o
argumentu rozwiązało problem.źródło
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
seahorse
i 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.źródło
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.
źródło
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
źródło