passwortloses ssh funktioniert nicht

35

Ich habe versucht, ein passwortloses ssh s / w Azu Bund Bzu Aauch einzurichten . Generierte den öffentlichen und privaten Schlüssel ssh-keygen -trsaauf beiden Computern. Verwendete das ssh-copy-idDienstprogramm, um die öffentlichen Schlüssel von Anach Bsowie Bnach zu kopieren A.

Das passwortlose ssh funktioniert von Abis Baber notvon Bbis A. Ich habe die Berechtigungen des Ordners ~ / ssh / überprüft und scheint normal zu sein.

A's .ssh Ordnerberechtigungen:

-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 Ordnerberechtigungen:

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

Aist ein Ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25. März 2009) Bist ein Debian-Rechner (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19. Oktober 2007)

Von A:

#ssh B

funktioniert gut.

Von 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: 

Dies bedeutet im Wesentlichen, dass keine Authentifizierung mithilfe der Datei erfolgt /root/id_rsa. Ich habe den ssh-addBefehl auch auf beiden Rechnern ausgeführt.

Der Authentifizierungsteil der /etc/ssh/sshd_configDatei lautet

# 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

Mir gehen die Ideen aus. Jede Hilfe wäre dankbar.

Cuurious
quelle
Was ist die Einstellung von PermitRootLoginin /etc/ssh/sshd_configauf A?
Taneli
@taneli: yesAndernfalls wird der Benutzer nicht zur Eingabe eines Kennworts aufgefordert.
Lekensteyn
In meinem Fall musste ich "IgnoreUserKnownHosts yes" in der Datei "/ etc / ssh / sshd_config" auf Ubuntu 12.04
Martin Magakian 19.09.13

Antworten:

24

Stellen Sie einfach sicher, dass Sie das folgende Verfahren befolgt haben:

Auf Maschine A

öffne ein Terminal und gib die Befehle wie folgt ein:

root@aneesh-pc:~# id

Nur um sicherzustellen, dass wir root sind.

Wenn der obige Befehl so etwas wie unten ausgibt, sind wir root, ansonsten wechseln Sie mit dem suBefehl zu root

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

1) Erstellen Sie die Schlüssel.

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        |
|                 |
|                 |
|                 |
|                 |
+-----------------+

Ich habe keine Passphrase verwendet. Wenn Sie einen brauchen, können Sie ihn verwenden.

2) Kopieren Sie den öffentlichen Schlüssel in die .ssh/authorized_keysDatei von Computer B

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

Versuchen Sie nun, sich mit auf dem Computer anzumelden ssh 'root@mylap', und checken Sie ein:

~/.ssh/authorized_keys

um sicherzustellen, dass wir keine zusätzlichen Schlüssel hinzugefügt haben, die Sie nicht erwartet haben.

Ersetzen Sie mylap durch den Hostnamen oder die IP-Adresse des Computers, auf dem Sie sich anmelden möchten (z. B. Computer B).

3) Melden Sie sich bei B ohne Passwort an

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:~$

Auf Maschine B

4) Erstellen Sie die Schlüssel, um sich wieder bei Computer A anzumelden

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) Kopieren Sie den öffentlichen Schlüssel in die .ssh/authorized_keysDatei von Computer 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: 

Versuchen Sie nun, sich mit auf dem Computer anzumelden ssh 'root@aneesh-pc', und checken Sie ein:

.ssh/authorized_keys

um sicherzustellen, dass wir keine zusätzlichen Schlüssel hinzugefügt haben, die Sie nicht erwartet haben.

6) Melden Sie sich bei A ohne Passwort an

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

Wenn Sie diese Schritte ausführen können, sind Sie fertig. Jetzt haben Sie zwei Computer mit aktiviertem SSH-Schlüssel (öffentlicher Schlüssel).

aneeshep
quelle
habe alle 6 Schritte wie angegeben ausgeführt, alle Dinge überprüft, bis Schritt 5, aber irgendwie funktioniert Schritt 6 nicht
Cuurious
Können Sie die Ausgabe dieses Befehls bereitstellen: 'ssh -v root @ aneesh-pc'. Ersetzen Sie den Benutzernamen und den Hostnamen durch Ihren.
Aneeshep
15
fand heraus, dass der Täter die Berechtigungen des /root(770) drwxrwx--- 70 root root 4096 2011-07-27 00:37 .. zu offen hatte. Die Berechtigungen wurden in geändert drwxr-xr-xund jetzt funktioniert es. Konnte mir nicht vorstellen, dass die Berechtigung des übergeordneten Verzeichnisses die ssh.
Cuurious
1
@Cuurious Guter Fang, mein Homeverzeichnis hatte 770sich auch eingestellt, auf a geändert 750und alles ist in Ordnung mit der Welt :) Ich scheine immer zu vergessen, dass Linux-Prems umgekehrt so funktionieren können.
Komplizierter
1
Fehler in Schritt 3. ssh-copy-id wird ausgeführt, nachdem ich ein Kennwort eingegeben habe. Ich kann mich jedoch immer noch nicht anmelden, ohne zur Eingabe eines Kennworts aufgefordert zu werden. Meine authorized_keys-Datei enthält den Text meiner .pub-Datei und ich biete den Schlüssel beim Anmelden an . Kein Erfolg Die Berechtigungen für alle Verzeichnisse sind korrekt.
Matt Clark
44

Nachdem ich passwortloses ssh eingerichtet hatte , wurde ich immer noch nach meinem Benutzerpasswort gefragt. Ein Blick /var/log/auth.logauf die Remote-Maschine wies auf das Problem hin:

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

So stellen Sie sicher, dass es richtig ist:

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

Das Verbot, dass andere Benutzer über Ihren .sshOrdner schreiben, liegt auf der Hand, aber es war schwieriger, die gleichen Anforderungen an Ihren Basisordner zu stellen.

Stellen Sie außerdem /etc/ssh/ssd_configsicher, dass RSAAuthenticationund PubkeyAuthenticationOptionen nicht deaktiviert sind. Standardmäßig yessollte das also kein Problem sein.

Maxime R.
quelle
Stellen Sie
Ich bin in diese Situation geraten, indem ich ein schlecht erstelltes Realtek-Treiberarchiv entpackt habe. Es hat den Besitzer des Verzeichnisses geändert, in das ich es entpackt habe.
Paul McMillan
2
Ihr privater Ordner kann nicht beschreibbar sein, da ich ihn ~/.sshin einen anderen Ordner umbenennen und dann einen neuen mit meinem eigenen Schlüssel erstellen könnte.
Kevin Panko
2
genial! Ich hatte nicht daran gedacht, in den Protokollen auf dem Hostcomputer nachzuschauen. Vielen Dank!
user3099609
14

Wahrscheinlich nur ein höheres Berechtigungsproblem. Sie müssen Schreibberechtigungen von der Gruppe und anderen in Ihrem Ausgangsverzeichnis und im SSH-Verzeichnis entfernen. Führen Sie chmod 755 ~ ~/.sshoder aus, um diese Berechtigungen zu korrigieren chmod go-w ~ ~/.ssh.

Wenn Sie weiterhin Probleme haben, geben Sie das folgende grep in Ihrem Protokoll ein:

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

(durch LOCAL_USER_NAMEIhren lokalen Benutzernamen ersetzen ...)

Das sollte Ihnen hoffentlich mehr über Ihr Problem erzählen, vorausgesetzt, die sshd-Authentifizierungsinformationen werden im sicheren Protokoll protokolliert, das standardmäßig sein sollte. Wenn Sie Fehler sehen, die so aussehen:

DATE HOSTNAME sshd [1317]: Authentifizierung abgelehnt: Falscher Besitz oder Modi für Verzeichnis / Pfad / zu / einigen / Verzeichnissen

Es ist das oben beschriebene Problem und Sie müssen das betreffende Verzeichnis finden und die Schreibberechtigungen von der Gruppe und anderen entfernen.

Aus dem Grund, dass Sie die Schreibberechtigungen für Ihr Basisverzeichnis einschränken müssten (obwohl die Berechtigungen für Ihr .ssh-Verzeichnis und nachfolgende Verzeichnisse bereits eingeschränkt sind), können andere Benutzer Ihr .ssh-Verzeichnis umbenennen und ein neues erstellen - obwohl dies der Fall ist wäre unbrauchbar, da dies (aufgrund falscher Berechtigungen) für die meisten Benutzer wahrscheinlich darin besteht, die Berechtigungen zu ändern, anstatt den Inhalt des Verzeichnisses zu überprüfen ...

TLDNR : Wenn Sie Gruppen- und / oder anderen Benutzern Schreibzugriff auf Ihr Home-Verzeichnis gewähren, erzwingt ssh die Kennwortanmeldung.

KTBiz
quelle
2

Verwenden Sie das Root-Konto auf jedem Computer? Normalerweise verwenden Sie unter Ubuntu ein Benutzerkonto und geben ihm die erforderlichen Sudo-Berechtigungen.

Wenn Sie einen Benutzer ohne Rootberechtigung verwenden, sudo chown $USER -R ~/.sshkann das Problem möglicherweise behoben werden

Andere Dinge zu überprüfen:

Überprüfen Sie, ob B id_rsa.pubin A ist authorized_keys.

check A's /etc/ssh/sshd_configenthält

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
Smithamax
quelle
Ja, ich habe das Root-Konto auf dem Ubuntu-Rechner aktiviert und bin daher auf beiden Systemen als Root-Benutzer aktiv
Cuurious
Ja, ich dachte mir, ich fügte ein paar andere Vorschläge hinzu, die Sie vielleicht übersehen haben. Diese Ausgabe ist wirklich nutzlos, nicht wahr? Nichts darüber, warum RSA nicht akzeptiert wurde.
Smithamax
1
Sie sind wahr, der Grund, warum der RSA-Schlüssel nicht akzeptiert wurde, ist das wesentliche Element hier, denke ich :). Die sshd_config enthält die oben genannten Elemente. Ich habe die Frage bearbeitet, um den Inhalt der /etc/ssh/sshd_configDatei zu integrieren
Cuurious
-3

in / etc / ssh / sshd_config bei der Zieländerung

PermitRootLogin Nr

zu

PermitRootLogin ja

dann töte -HUP deine sshd PID:

root @ dzone2 # ps -ef | grep ssh root 28075 27576 0 17. November? 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
quelle
1
Das wird nicht helfen. Das Problem ist, dass die passwortlose SSH-Anmeldung (Authentifizierung mit einem RSA-Schlüsselpaar) nicht funktioniert. Die Anweisungen, die Sie angegeben haben, dienen dazu, die rootSSH-Anmeldung zum Laufen zu bringen. Das hat überhaupt nichts mit dieser Frage zu tun. Wenn das rootKonto aktiviert ist (dies ist in Ubuntu nicht die Standardeinstellung), kann das Aktivieren von rootSSH-Anmeldungen sehr gefährlich sein.
Eliah Kagan,