ssh bez hasła nie działa

35

Próbowałem konfiguracji hasłem mniej ssh / b A, aby Bi Bna Ajak dobrze. Wygenerowano klucz publiczny i prywatny ssh-keygen -trsana obu komputerach. Użył ssh-copy-idnarzędzia do kopiowania publiczno-klucze Ado Bjak również Bdo A.

Bez hasła hasło ssh działa od Ado, Bale notod Bdo A. Sprawdziłem uprawnienia do folderu ~ / ssh / i wydaje się być normalny.

A's .ssh uprawnienia do folderów:

-rw-------  1 root root 13530 2011-07-26 23:00 known_hosts
-rw-------  1 root root   403 2011-07-27 00:35 id_rsa.pub
-rw-------  1 root root  1675 2011-07-27 00:35 id_rsa
-rw-------  1 root root   799 2011-07-27 00:37 authorized_keys
drwxrwx--- 70 root root  4096 2011-07-27 00:37 ..
drwx------  2 root root  4096 2011-07-27 00:38 .

B's .ssh uprawnienia do folderów:

-rw------- 1 root root  884 2011-07-07 13:15 known_hosts
-rw-r--r-- 1 root root  396 2011-07-27 00:15 id_rsa.pub
-rw------- 1 root root 1675 2011-07-27 00:15 id_rsa
-rw------- 1 root root 2545 2011-07-27 00:36 authorized_keys
drwxr-xr-x 8 root root 4096 2011-07-06 19:44 ..
drwx------ 2 root root 4096 2011-07-27 00:15 .

Ajest Ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 marca 2009) Bjest maszyną debianową (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 paź 2007)

Od A:

#ssh B

działa w porządku.

Od B:

#ssh -vvv A 
...
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x7f1581f23a50)
debug2: key: /root/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1127
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
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: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1495
debug1: Authentications that can continue: publickey,password
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
[email protected]'s password: 

Co w zasadzie oznacza, że ​​nie uwierzytelnia się przy użyciu pliku /root/id_rsa. Uruchomiłem ssh-addpolecenie również na obu maszynach.

Część uwierzytelniająca /etc/ssh/sshd_configpliku to

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files

Skończyły mi się pomysły. Każda pomoc będzie mile widziana.

Cuurious
źródło
Jakie jest ustawienie PermitRootLoginw /etc/ssh/sshd_configA?
taneli
@taneli:, w yesprzeciwnym razie użytkownik nie zostanie poproszony o podanie hasła.
Lekensteyn
W moim przypadku musiałem odkomentować „IgnoreUserKnownHosts yes” w pliku „/ etc / ssh / sshd_config” na Ubuntu 12.04
Martin Magakian 19.09.13

Odpowiedzi:

24

Upewnij się, że postępujesz zgodnie z następującą procedurą:

Na komputerze A

otwórz terminal i wprowadź następujące polecenia:

root@aneesh-pc:~# id

Aby upewnić się, że jesteśmy rootem.

Jeśli powyższe polecenie wyprowadza coś takiego jak poniżej, jesteśmy root, przełącz się na root za pomocą supolecenia

uid=0(root) gid=0(root) groups=0(root)

1) Utwórz klucze.

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
49:7d:30:7d:67:db:58:51:42:75:78:9c:06:e1:0c:8d root@aneesh-pc
The key's randomart image is:
+--[ RSA 2048]----+
|          ooo+==B|
|         . E=.o+B|
|        . . .+.*o|
|       . . .  ...|
|        S        |
|                 |
|                 |
|                 |
|                 |
+-----------------+

Nie użyłem żadnego hasła. Jeśli potrzebujesz, możesz go użyć.

2) Skopiuj klucz publiczny do .ssh/authorized_keyspliku komputera B.

root@aneesh-pc:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@mylap
root@mylap's password: 

Teraz spróbuj zalogować się do komputera za pomocą ssh 'root@mylap'i zalogować się :

~/.ssh/authorized_keys

aby upewnić się, że nie dodaliśmy dodatkowych kluczy, których się nie spodziewałeś.

Zamień mylap na nazwę hosta lub adres IP komputera, na który chcesz się zalogować (tj. Komputera B)

3) Zaloguj się do B bez hasła

root@aneesh-pc:~# ssh root@mylap
Warning: Permanently added 'mylap,192.168.1.200' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Wed Jul 27 15:23:58 2011 from streaming-desktop.local
aneesh@mylap:~$

Na komputerze B

4) Utwórz klucze, aby zalogować się ponownie na maszynie A.

root@mylap:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
35:9f:e7:81:ed:02:f9:fd:ad:ef:08:c6:4e:19:76:b1 root@streaming-desktop
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|          o   .  |
|         . + + o |
|        S o * E  |
|           = O . |
|            O +  |
|           + o o.|
|            . o+=|
+-----------------+

5) Skopiuj klucz publiczny do .ssh/authorized_keyspliku komputera A.

root@mylap:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
root@aneesh-pc's password: 

Teraz spróbuj zalogować się do komputera za pomocą ssh 'root@aneesh-pc'i zalogować się :

.ssh/authorized_keys

aby upewnić się, że nie dodaliśmy dodatkowych kluczy, których się nie spodziewałeś.

6) Zaloguj się do A bez hasła

ssh root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/


Last login: Tue Jul 26 18:52:55 2011 from 192.168.1.116

Jeśli jesteś w stanie wykonać te kroki, to koniec. Teraz masz dwa komputery z logowaniem z włączonym kluczem ssh (klucz publiczny).

aneeshep
źródło
wykonałem wszystkie 6 kroków zgodnie ze specyfikacją, zweryfikowałem wszystkie rzeczy powiązane do kroku 5, ale jakoś krok 6 nie działa
Cuurious
Czy możesz podać wynik działania tego polecenia: „ssh -v root @ aneesh-pc”. zamień nazwę użytkownika i nazwę hosta na swoją.
aneeshep
15
dowiedziałem się, że sprawca uprawnień /root(770) drwxrwx--- 70 root root 4096 2011-07-27 00:37 .. był zbyt otwarty. Zmieniono uprawnienia drwxr-xr-xi teraz działa. Nie mogłem sobie wyobrazić, że uprawnienia katalogu nadrzędnego wpływają na ssh.
Cuurious
1
@Cuurious Dobry haczyk, mój katalog domowy 770również ustawił, zmienił się na a 750i wszystko jest w porządku ze światem :) Zawsze wydaje mi się, że zapominam, że linux preams może działać w odwrotny sposób.
komplementuje
1
Błąd w kroku 3. ssh-copy-id uruchamia się po wprowadzeniu hasła, jednak nadal nie mogę się zalogować bez pytania o hasło, plik autoryzowanych kluczy zawiera tekst pliku .pub i oferuję klucz przy logowaniu . Bezskutecznie Uprawnienia do wszystkich katalogów są prawidłowe.
Matt Clark,
44

Po skonfigurowaniu ssh bez hasła nadal byłem proszony o podanie hasła użytkownika. Patrząc /var/log/auth.logna zdalną maszynę, wskazałem na problem:

sshd[4215]: Authentication refused: bad ownership or modes for directory /home/<user>

Więc upewnij się, że masz rację:

chmod o-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Chociaż zabronienie innym użytkownikom pisania nad twoim .sshfolderem jest oczywiste, posiadanie takich samych wymagań dotyczących folderu domowego było trudniejsze.

Należy także sprawdzić /etc/ssh/ssd_config, aby upewnić się, że RSAAuthenticationi PubkeyAuthenticationopcje nie są wyłączone. Domyślnie yesnie powinno to stanowić problemu.

Maxime R.
źródło
upewnij się również, że wyżej wymienione foldery są własnością właściwego użytkownika
GoalBased
Wpadłem w tę sytuację, rozpakowując źle utworzone archiwum sterowników realtek. Zmieniło właściciela katalogu, w którym go rozpakowywałem.
Paul McMillan
2
Twój folder domowy nie może być zapisywalny, ponieważ jeśli tak, to mógłbym po prostu zmienić nazwę ~/.sshna coś innego, a następnie utworzyć nowy z własnym kluczem.
Kevin Panko
2
niesamowite! nie myślał o przejrzeniu dzienników na komputerze-hoście. Dzięki!
user3099609,
14

Prawdopodobnie tylko problem z uprawnieniami wyższego poziomu. Musisz usunąć uprawnienia do zapisu z grupy i innych do katalogu domowego i katalogu .ssh. Aby naprawić te uprawnienia, uruchom chmod 755 ~ ~/.sshlub chmod go-w ~ ~/.ssh.

Jeśli nadal masz problemy, wydaj następujący grep w swoim dzienniku:

sudo egrep -i 'ssh.*LOCAL_USER_NAME' /var/log/secure

(zastąp LOCAL_USER_NAMEswoją lokalną nazwą użytkownika ...)

Mam nadzieję, że powinno to powiedzieć więcej o twoim problemie, zakładając, że informacje o uwierzytelnianiu sshd są rejestrowane w bezpiecznym dzienniku, który powinien być domyślnie. Jeśli zobaczysz błędy, które wyglądają tak:

DATE HOSTNAME sshd [1317]: Odmowa uwierzytelnienia: złe prawo własności lub tryby dla katalogu / path / to / some / directory

Jest to problem opisany powyżej i musisz znaleźć dany katalog i usunąć uprawnienia do zapisu z grupy i innych.

Ponieważ musisz ograniczyć uprawnienia do zapisu w katalogu domowym (mimo że uprawnienia są już ograniczone w twoim .ssh i kolejnych katalogach) pozwoli innym użytkownikom zmienić nazwę twojego katalogu .ssh i utworzyć nowy - chociaż to byłby bezużyteczny, ponieważ jest (z powodu złych uprawnień) poprawką dla większości użytkowników prawdopodobnie byłaby zmiana uprawnień zamiast sprawdzania zawartości katalogu ...

TLDNR : Zezwolenie na dostęp do zapisu dla grupy i / lub innych w twoim katalogu domowym spowoduje, że ssh wymusi hasło logowania.

KTBiz
źródło
2

czy korzystasz z konta root na każdym komputerze? Zwykle na Ubuntu używasz konta użytkownika i nadajesz mu uprawnienia sudo zgodnie z wymaganiami.

Jeśli używasz użytkownika innego niż root, sudo chown $USER -R ~/.sshmożesz rozwiązać problem

Inne rzeczy do sprawdzenia:

dokładnie sprawdzić, że B znajduje id_rsa.pubsię w użytkownika authorized_keys.

sprawdź, czy /etc/ssh/sshd_configzawiera

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
Smithamax
źródło
Tak, włączyłem konto roota na komputerze Ubuntu, dlatego
działam
Tak, pomyślałem, dodałem kilka innych sugestii, które mogłeś przeoczyć. Ten wynik jest naprawdę bezużyteczny, prawda? Nic, dlaczego RSA nie został zaakceptowany.
Smithamax
1
prawda, że ​​powodem, dla którego klucz RSA nie został zaakceptowany, jest tutaj chyba niezbędny element :). sshd_config zawiera wyżej wymienione elementy, zredagowałem pytanie, aby włączyć zawartość zawartości /etc/ssh/sshd_configpliku
Cuurious
-3

w / etc / ssh / sshd_config o zmianie celu

PermitRootLogin no

do

PermitRootLogin tak

następnie zabij -HUP swój sshd PID:

root @ dzone2 # ps -ef | grep ssh root 28075 27576 0 17 listopada? 6:11 / usr / lib / ssh / sshd

root 17708 20618   0 10:09:30 pts/37      0:00 grep ssh root@dzone2 # kill -HUP 28075 root@dzone2 # ps -ef|grep ssh
root 17861 20618   0 10:09:44 pts/37      0:00 grep ssh
root 17852 27576   0 10:09:42 ?           0:00 /usr/lib/ssh/sshd
Duncan
źródło
1
To nie pomoże. Problem polega na tym, że logowanie SSH bez hasła (uwierzytelnianie za pomocą pary kluczy RSA) nie działa. Podane instrukcje dotyczą rootlogowania SSH. To zupełnie nie ma związku z tym, o co chodzi w tym pytaniu. Ponadto, jeśli rootkonto jest włączone (domyślnie nie jest dostępne w Ubuntu), włączenie rootlogowania SSH może być dość niebezpieczne.
Eliah Kagan