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

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

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.

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

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.

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.

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.

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.

Próbować

/sbin/restorecon -r /root/.ssh

Możliwy problem z kontekstem sprzedaży

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.

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

klient:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart