Klucz publiczny SSH nie będzie wysyłany na serwer


33

Walczyłem z tym od kilku godzin, więc każda pomoc jest bardzo mile widziana ...

Mam 2x serwery, z których oba mogę sshz kluczami publicznymi z OSX, żadnych problemów, więc jestem pewien, że wszystko jest w porządku sshd_config.

Próbuję skonfigurować zadanie CRON rsyncdo synchronizacji dwóch serwerów i potrzebuję serwera B (kopia zapasowa) do sshserwera A za pomocą klucza publicznego.

Nie mogę przez całe życie dowiedzieć się, dlaczego nie znajduje moich kluczy publicznych - są w ~/.ssh/(tj. /root/.ssh) I wszystkie uprawnienia do plików są poprawne w punktach A i B.

To jest wynik:

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Pamiętaj też, że szuka kluczy prywatnych, które nie istnieją ...

drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root  403 May 25 01:37 authorized_keys
-rw-------. 1 root root    0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root  405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root  395 May 25 02:36 known_hosts

2
proszę podać dane wyjściowels -la /root/.ssh/
mreithub

@mreithub Dziękujemy za szybką odpowiedź - dodano powyżej.
Danny

3
spróbuj usunąć _tm1z kluczowych nazw plików (tj. mv id_rsa_tm1 id_rsai mv id_rsa_tm1.pub id_rsa.pub)
mreithub

@mreithub To działało! Dziękuję bardzo, ale nie rozumiem, dlaczego nie mogę dołączyć innych ciągów do nazwy pliku. Robię to na moim komputerze iMac, aby łączyć się z serwerami bez żadnych problemów ... tzn. Mogę bez problemu używać id_rsa.tm1.imac.pub. Co jeśli chcę kilka kluczy?
Danny

Odpowiedzi:


22

Spójrz na swoją stronę man ssh:

   -i identity_file
          Selects a file from which the identity (private key) for public
          key authentication is read.  The default is ~/.ssh/identity for
          protocol   version   1,   and  ~/.ssh/id_dsa,  ~/.ssh/id_ecdsa,
          ~/.ssh/id_ed25519 and ~/.ssh/id_rsa  for  protocol  version  2.
          Identity files may also be specified on a per-host basis in the
          configuration file.  It is possible to have multiple -i options
          (and  multiple  identities  specified  in configuration files).

lub strona man ssh_config:

   IdentityFile
          Specifies a file from which the user's DSA, ECDSA,  ED25519  or
          RSA   authentication   identity   is   read.   The  default  is
          ~/.ssh/identity for  protocol  version  1,  and  ~/.ssh/id_dsa,
          ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
          col version 2.  Additionally, any identities represented by the
          authentication  agent  will  be  used for authentication unless
          IdentitiesOnly is set.

Widzisz, istnieje kilka specjalnych nazw plików, które są wypróbowywane, jeśli nie określisz klucza. Są to również pliki widoczne w danych wyjściowych dziennika.

Aby użyć klucza w pliku o innej nazwie, masz trzy opcje:

  • podaj plik jawnie, korzystając z powyższej -iopcji.
  • skonfiguruj plik w konfiguracji klienta za pomocą powyższej IdentityFileopcji.
  • dodaj klucz do swojego agenta za pomocą ssh-add.

W przypadku sesji interaktywnych agent jest najbardziej elastyczny. Dla twojego zadania crona -iopcja jest prawdopodobnie najłatwiejsza.


26

Zniekształcony plik kluczy autoryzowanych na hoście docelowym to kolejny powód, dla którego ssh wyświetla komunikat „nie wysłaliśmy pakietu” i prosi o hasło zamiast używania uwierzytelniania pubkey: -

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method

Problem w tym konkretnym przypadku polegał na tym, że dane klucza publicznego, które zostały wklejone .ssh/authorized_keysna hoście docelowym, nie miały swojego pierwszego znaku:

sh-rsa AAAA...

Rozwiązaniem było po prostu dodanie brakujących „s”.

ssh-rsa AAAA...

A więc:-

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).

2
dziękuję, za każdym razem, gdy pojawia się ten błąd, to dlatego, że mój plik autoryzowanych_kluczy na zdalnym hoście (serwerze) jest zniekształcony. Chciałbym, żeby błąd nie sprawiał, że pojawił się problem z klientem.
tamale

3
Wklejanie do vima bez uprzedniego naciśnięcia „i”!
Jordan Davidson

Dla mnie nie wyglądało to na zniekształcone, ale usunąłem plik iz komputera źródłowego ponownie wykonałem ssh-copy-id, aby go odtworzyć. Problem rozwiązany.
alvarez

14

Dokładny ciąg komunikatów o błędach w pytaniu może również wystąpić w przypadku niedopasowanej pary kluczy prywatny / publiczny po stronie lokalnej . Nie, to nie ma sensu, ale po prostu oderwałem włosy przez długi czas, próbując dowiedzieć się, co się dzieje.

  • Zdalny system A został .ssh/mykey.pubskopiowany .ssh/authorized_keys.
  • System lokalny B ma .ssh/mykeyprawidłowy klucz prywatny, który pasuje do klucza publicznego systemu A, ale ma również .ssh/mykey.pubplik, który nie pasuje, być może poprzednia wersja zamienionego klucza.

SSH z B do A ( ssh -i mykey A) nie powiedzie się z komunikatami w pytaniu, szczególnie jeśli włączysz -vvz klienta ssh zobaczysz:

Próbując klucza prywatnego: .ssh / mykey
nie wysłaliśmy pakietu, wyłącz metodę

To kłamstwo, ponieważ rzeczywisty klucz nie został wypróbowany, najwyraźniej użył lokalnego pliku klucza publicznego o pasującej nazwie, aby dowiedzieć się, czy prawdopodobnie zadziała, a następnie nie zrobił nic, gdy były niezgodne. Żadna ilość informacji debugowania po żadnej ze stron tak naprawdę nie wskazuje na problem.


Łał! Ten też zabił dla mnie sporo czasu! Straciłem trochę włosów! Tak więc w moim przypadku tak też było, tylko mój klucz pub był rzeczywiście w pliku autoryzowanych_kluczy po stronie klienta, z tym wyjątkiem, że zawierał on nazwę @ host na samym końcu, gdzie mój host sshd nie. Nie zdawałem sobie sprawy, że musisz dopasować klucze autoryzowane na każdym końcu, w rzeczywistości nie sądzę, żebym kiedykolwiek wcześniej je dopasowywał. Był to problem tylko wtedy, gdy moim klientem był CentOS 7, łączący się z Ubuntu 12.04. Przejście z MacOS lub innych systemów Ubuntu działało dobrze.
gregthegeek

Jak więc rozwiązać ten problem? Opisałeś mój problem T. T. Mój problem jest jeszcze bardziej zaostrzony, ponieważ przeskakuję między różnymi systemami. Właściwie określenie pliku nie działa dla mnie
Madivad

@Madivad Rozwiązuje się ten problem, lokalnie dopasowując klucze publiczne / prywatne (lub w ogóle nie ma kluczy publicznych).
Caleb

@Caleb To brzmi prościej niż jest, chyba że (i myślę, że grosz spadł) oznacza to, że powinienem kopiować klucze publiczne i prywatne do każdego systemu, którego chcę używać jako klienta SSH? Próbowałem utworzyć plik tożsamości, ale najwyraźniej źle go
używam

Usunięcie osieroconego pliku id_rsa.pub na kliencie rozwiązało to dla mnie. Właśnie napotkałem ten problem po raz kolejny na nowym kliencie Centos 7 łączącym się z serwerem Ubuntu 12.04. Klawisze autoryzowane nazwa / host nie rozwiązały problemu. Dopasowałem katalogi, perms, dokładnie ten sam plik klucza id_rsa, ale był dodatkowy id_rsa.pub (po stronie klienta). Usunięte, teraz działa. Uruchomiłem ssh-keygen, aby szybko utworzyć katalogi, a następnie rsync ze znanego dobrego systemu. Ale pozostawiło to dodatkowy plik pubu niepasujący do żadnego klucza prywatnego (nie było go w źródłowym rsync). Ponownie dodałem niedopasowany plik publikacji w celu weryfikacji. Upewnij się, że są dopasowane lub usunięte.
gregthegeek

5

Domyślne nazwy plików, których szuka ssh, to id_rsai id_rsa.pub.

Jeśli chcesz użyć innych nazw plików, musisz podać je w ssh_config(używając IdentityFileustawienia) lub za pomocą parametru wiersza polecenia ssh -i.


4

Miałem ten sam problem na RedHat; sprawdził dzienniki i stwierdził, że katalog domowy ma niepoprawne prawa użytkownika.

sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user

Naprawienie praw do katalogu domowego rozwiązało to.


4
Witamy na stronie wymiany stosów U + L. Możesz uczynić swoją odpowiedź bardziej przydatną dla innych, podając przykład, jak powinny wyglądać prawidłowe uprawnienia.
Erathiel,

Miałem bardzo podobny problem z wyjątkiem ~/.sshreż. Przynajmniej na Fedorze 28, gdy ~/.sshuprawnienia były na poziomie 0775, nie mogłem połączyć się z kluczami publicznymi / prywatnymi. Zmieniłem więc uprawnienia na 0755 i
działałem

3

Prostym sposobem debugowania w Debian / Ubuntu jest: Połącz się hasłem i ogonuj dziennik

tail -f /var/log/auth.log

Spróbuj połączyć się z innego terminala, a zobaczysz błąd ...

W moim przypadku katalog / root miał wartość 770, a nie 700, co jest wartością domyślną. Błąd brzmiał: „Odmowa uwierzytelnienia: złe prawo własności lub tryby katalogu / root”

Napraw to i gotowe.


dziękuję bardzo, stary! uratowałeś mi dzień!
Anthony

To pomogło to wyjaśnić. Mój mówił, że użytkownik taki jak 123.123.123.123 jest niedozwolony, ponieważ nie jest wymieniony w AllowUsers . Dziękuję bardzo!
aexl


0

Po bieganiu

ssh-copy-id user@remote-host

normalnie powinno działać. Ale jeśli się nie powiedzie, spróbuj tego: zaloguj się do zdalnego hosta jako użytkownik, którego chcesz się zalogować w przyszłości i uruchom:

ssh-keygen

Pomogło mi to.


0

Tak więc stało się dla mnie, że mam 2 maszyny wirtualne, do których mam dostęp z mojego komputera lokalnego (2 klucze id_rsa.pub i id_rsa2.pub). Zrozumiałem, że moje połączenie ssh domyślnie używa id_rsa.pub dla każdego połączenia ssh użytkownik@xx.xx.xx.xx. Rozwiązałem problem, dodając plik konfiguracyjny i określając tożsamość, która ma być używana dla każdego hosta, w następujący sposób:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2

-2

klient:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.