2012-12-09 27 views
7

Próbuję połączyć się z serwerem Centos 6.3 przy użyciu klucza SSH, więc mogę zdalnie uruchomić skrypt bez pytania o hasło za każdym razem. Śledzę następujące czynności:Łączenie się ze zdalnym serwerem Centos przy użyciu kluczy SSH

  1. Logowanie do serwera przy użyciu zwykłe polecenie ssh i hasło jednorazowe więc serwer dodaje komputer do znanych hostów
  2. W komputerze z wykorzystaniem Cygwin-końcowy wygenerować klucze i pozostawić puste hasło: ssh-keygen -t rsa
  3. teraz ustawić uprawnienia na klucz prywatny i ssh folderu: chmod 700 ~/.ssh & chmod 600 ~/.ssh/id_rsa
  4. skopiować klucz publiczny (id_rsa.pub) do serwera, zaloguj się do serwera i dodać klucz publiczny do listy authorized_keys : cat id_rsa.pub >> ~/.ssh/authorized_keys
  5. Po zaimportowaniu klucza publicznego można go usunąć z serwera. Ustaw uprawnienia do pliku na serwerze: chmod 700 ~/.ssh & chmod 600 ~/.ssh/authorized_keys
  6. Retart demon ssh na serwerze: service sshd restart
  7. przetestować połączenie z komputerem: ssh [email protected]

Ale gdy próbuję ssh do serwera zdalnego Jest jeszcze prosząc mnie o hasło. Folder .ssh nie został utworzony na serwerze, więc musiałem go sam utworzyć. Jakieś pomysły na to, co może się wydarzyć? przegapiłem coś? Czy istnieje inny sposób konfiguracji kluczy?

+1

kiedy mówisz ~, o czym mówisz? Również ponowne uruchomienie sshd nie jest konieczne do zmiany kluczy ... – Blaskovicz

+0

@guillermog proszę zadbać o formatowanie w przyszłych pytaniach. Powinno być jasne i łatwe do odczytania, w przeciwnym razie jest tylko ścianą tekstu i wyłącza. – Siddharth

+0

@Blaskovicz Używam użytkownika root. – guillermog

Odpowiedz

3

Cóż okazuje się, ja głupio zmienił właściciela katalogu /root kiedy zachodziło w górę tak, ponieważ katalog /.ssh był dla użytkownika, który próbowałem zalogować (root), odmawiał dostępu do tego katalogu, ponieważ należał do innego użytkownika.

Dec 10 16:25:49 thyme sshd[9121]: Authentication refused: bad ownership or modes for directory /root 

Zmieniłem właściciela z powrotem na root i to się udało.

chown root /root 

Dzięki chłopaki za pomoc.

4

Podobno jest to znany bug. Proponowane rozwiązanie faktycznie nie działa, ale stwierdzone, że w systemie CentOS 6.2 w pracy:

chmod 600 .ssh/authorized_keys 
chmod 700 .ssh 
+0

Próbowałem tego, ale wciąż nie miałem szczęścia. – guillermog

1

Althogh OP znalazł rozwiązanie, chciałbym nagrać moje rozwiązanie podobnego problemu w nadziei, że będzie pomocne dla tych, którzy google podobny problem i osiągnąć tę odpowiedź.

Powodem mojego problemu jest to, że katalog .ssh w folderze domowym użytkownika na serwerze CentOS nie został ustawiony prawidłowym trybem po utworzeniu przez polecenie useradd.

Ponadto muszę ręcznie ustawić tryb folderu .ssh przez następujące polecenia:

chmod g-w /home/user

chmod 700 /home/user/.ssh

chmod 600 /home/user/.ssh/authorized_keys

+0

kluczowym elementem dla mnie był 'chmod g-w/home/user' – djangodude

1

Inne odpowiedzi są uniwersalne, a pamiętać, że Centos 6 wykorzystuje SELinux .SELinux może odmówić dostępu do pliku authorised_keys mimo poprawnych uprawnień i własności

ze znanych problemów w Centos 6 Release Notes:

  • Upewnij się, że poprawnie ustawiony kontekst SELinux z kluczem publicznym jeśli prześlij go na serwer CentOS 6 z włączoną obsługą selinux . W przeciwnym razie selinux może zabronić dostępu do pliku ~/.ssh/authorized_keys, a uwierzytelnianie nie będzie działać z powodu klucza klucza . W celu konfiguracji prawidłowy kontekst można użyć:

    restorecon -R -v /home/user/.ssh

  • ssh-copy-id z CentOS 6 jest świadomy kontekstach SELinux i poprzedniego obejścia nie jest potrzebne.

Powiązane problemy