ssh sans mot de passe ne fonctionne pas

35

J'ai essayé de configurer un ssh sans mot de passe b / w Aà Bet Bà Aainsi. Généré la clé publique et privée en utilisant ssh-keygen -trsasur les deux machines. Utilisé l' ssh-copy-idutilitaire pour copier les clés publique-de Apour Bainsi que Bpour A.

Le SSH sans mot de passe fonctionne de Aà Bmais notde Bà A. J'ai vérifié les autorisations du dossier ~ / ssh / et semble être normal.

A's .ssh autorisations de dossier:

-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 autorisations de dossier:

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

Aest une machine ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009) Best une machine Debian (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 oct 2007)

De A:

#ssh B

fonctionne bien.

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

Ce qui signifie essentiellement que ce n'est pas l'authentification à l'aide du fichier /root/id_rsa. J'ai aussi exécuté la ssh-addcommande dans les deux machines.

La partie authentification du /etc/ssh/sshd_configfichier est

# 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

Je manque d'idées. Toute aide serait appréciée.

Cuurious
la source
Quel est le réglage PermitRootLogindans /etc/ssh/sshd_configle A?
Taneli
@taneli:, yessinon l'utilisateur ne sera pas invité à entrer un mot de passe.
Lekensteyn le
Dans mon cas, j'ai dû supprimer le commentaire "IgnoreUserKnownHosts yes" dans le fichier "/ etc / ssh / sshd_config" sur Ubuntu le 12.04
Martin Magakian le

Réponses:

24

Assurez-vous simplement que vous avez suivi la procédure suivante:

Sur la machine A

ouvrez un terminal et entrez les commandes comme suit:

root@aneesh-pc:~# id

Juste pour nous assurer que nous sommes root.

Si la commande ci-dessus produit quelque chose comme ci-dessous, nous sommes root, sinon passez à root en utilisant la sucommande

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

1) Créez les clés.

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

Je n'ai utilisé aucun mot de passe. Si vous en avez besoin, vous pouvez l'utiliser.

2) Copier la clé publique dans le .ssh/authorized_keysfichier de la machine B

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

Maintenant, essayez de vous connecter à la machine, avec ssh 'root@mylap', et enregistrez:

~/.ssh/authorized_keys

pour vous assurer que nous n'avons pas ajouté de clés supplémentaires auxquelles vous ne vous attendiez pas.

Remplacez mylap par le nom d'hôte ou l'adresse IP de la machine à laquelle vous souhaitez vous connecter (c'est-à-dire la machine B)

3) Connectez-vous à B sans mot de passe

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

Sur la machine B

4) Créez les clés pour vous reconnecter à la machine 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) Copier la clé publique dans le .ssh/authorized_keysfichier de la machine 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: 

Maintenant, essayez de vous connecter à la machine, avec ssh 'root@aneesh-pc', et enregistrez:

.ssh/authorized_keys

pour vous assurer que nous n'avons pas ajouté de clés supplémentaires auxquelles vous ne vous attendiez pas.

6) Connectez-vous à A sans mot de passe

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

Si vous pouvez suivre ces étapes, vous avez terminé. Vous avez maintenant deux machines avec la connexion activée par ssh-key (clé publique).

aneeshep
la source
fait toutes les 6 étapes comme spécifié, vérifié toutes les choses liées jusqu'à l'étape 5, mais en quelque sorte l'étape 6 ne fonctionne pas
Cuurious
Pouvez-vous fournir le résultat de cette commande: 'ssh -v root @ aneesh-pc'. remplacez le nom d'utilisateur et le nom d'hôte par le vôtre.
aneeshep
15
découvert le coupable les autorisations de la /root(770) drwxrwx--- 70 root root 4096 2011-07-27 00:37 .. était trop ouverte. Changé les permissions drwxr-xr-xet maintenant ça marche. Impossible d'imaginer le fait que l'autorisation du répertoire parent affecte le ssh.
Cuurious
1
@Cuurious Good catch, mon répertoire personnel a 770également été défini, a été remplacé par a 750et tout va bien pour le monde :) Il semble que j'oublie toujours que les prems de Linux peuvent fonctionner en sens inverse.
Compliste
1
Echec à l'étape 3. ssh-copy-id s'exécute après la saisie d'un mot de passe. Toutefois, je ne parviens toujours pas à me connecter sans qu'un mot de passe ne soit demandé. Mon fichier allowed_keys contient le texte de mon fichier .pub et j'offre la clé lors de la connexion. . Aucun résultat. Les autorisations sur tous les répertoires sont correctes.
Matt Clark
44

Après avoir configuré ssh sans mot de passe , mon mot de passe utilisateur m’était toujours demandé. Regarder /var/log/auth.logsur la machine distante a souligné le problème:

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

Alors, assurez-vous de bien le faire:

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

Il .sshest évident qu’il est interdit d’interdire à d’autres utilisateurs d’écrire sur votre dossier, mais il était plus difficile d’avoir la même exigence pour votre dossier personnel.

Vérifiez également /etc/ssh/ssd_configque les options RSAAuthenticationet les PubkeyAuthenticationoptions ne sont pas désactivées. Par défaut yes, cela ne devrait pas poser de problème.

Maxime R.
la source
Assurez-vous également que les dossiers énumérés ci-dessus appartiennent au bon utilisateur.
GoalBased
Je suis entré dans cette situation en démêlant une archive de pilotes Realtek mal créée. Cela a changé le propriétaire du répertoire dans lequel je le décompressais.
Paul McMillan
2
Votre dossier de départ ne peut pas être inscriptible, car s'il l'était, je pourrais simplement renommer votre ~/.sshautre nom, puis en créer un nouveau avec ma propre clé.
Kevin Panko
2
impressionnant! n'avait pas pensé à regarder dans les journaux sur la machine hôte. Merci!
user3099609
14

Probablement juste un problème d'autorisations de niveau supérieur. Vous devez supprimer les autorisations d'écriture du groupe et des autres sur votre répertoire personnel et votre répertoire .ssh. Pour corriger ces autorisations, exécutez chmod 755 ~ ~/.sshou chmod go-w ~ ~/.ssh.

Si vous rencontrez toujours des problèmes, indiquez le grep suivant dans votre journal:

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

(remplacez LOCAL_USER_NAMEpar votre nom d'utilisateur local ...)

J'espère que cela vous en dira plus sur votre problème, en supposant que les informations d'authentification sshd soient consignées dans le journal sécurisé, qui devrait l'être par défaut. Si vous voyez des erreurs qui ressemblent à ceci:

DATE HOSTNAME sshd [1317]: Authentification refusée: mauvaise propriété ou modes pour répertoire / chemin / vers / un / répertoire

C'est le problème décrit ci-dessus et vous devez trouver le répertoire en question et supprimer les autorisations d'écriture du groupe et autre.

En ce qui concerne la raison pour laquelle vous auriez besoin de restreindre les autorisations en écriture sur votre répertoire de base (même si les autorisations sont déjà limitées sur votre .ssh et les répertoires suivants), cela permettra à d’autres utilisateurs de renommer votre répertoire .ssh et d’en créer un nouveau. serait inutilisable tel quel (en raison d'autorisations incorrectes), le correctif pour la plupart des utilisateurs serait probablement de modifier les autorisations plutôt que de vérifier le contenu du répertoire ...

TLDNR : Si vous autorisez un accès en écriture pour le groupe et / ou d’autres personnes à votre répertoire de base, ssh forcera la connexion par mot de passe.

KTBiz
la source
2

utilisez-vous le compte root sur chaque machine? Généralement, sur Ubuntu, vous utiliserez un compte utilisateur et lui accorderez les privilèges sudo requis.

Si vous utilisez un utilisateur non root sudo chown $USER -R ~/.sshpeut résoudre votre problème

Autres choses à vérifier:

vérifiez que B id_rsa.pubest en question dans un authorized_keys.

chèque A /etc/ssh/sshd_configcontient

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
Smithamax
la source
Oui, j'ai activé le compte root sur la machine Ubuntu, fonctionnant ainsi en tant qu'utilisateur root dans les deux systèmes
Cuurious
Oui, j'ai pensé, ajouté quelques autres suggestions que vous pourriez avoir négligées. Cette sortie est vraiment inutile, n'est-ce pas, rien sur la raison pour laquelle la RSA n'a pas été acceptée.
Smithamax
1
vous êtes vrai, la raison pour laquelle la clé RSA n'a pas été acceptée est l'élément essentiel ici, je suppose :). sshd_config contient les éléments ci-dessus, j'ai modifié la question pour incorporer le contenu du contenu du /etc/ssh/sshd_configfichier
Cuurious
-3

dans / etc / ssh / sshd_config sur le changement de cible

PermitRootLogin no

à

PermitRootLogin oui

puis tuez -HUP votre PID sshd:

root @ dzone2 # ps -ef | grep ssh root 28075 27576 0 17 novembre? 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
la source
1
Cela ne va pas aider. Le problème est que la connexion SSH sans mot de passe (authentification avec une paire de clés RSA) ne fonctionne pas. Les instructions que vous avez fournies sont pour que la rootconnexion SSH fonctionne. Cela n'a rien à voir avec le sujet de cette question. De plus, si le rootcompte est activé (il ne l’est pas par défaut dans Ubuntu), l’activation de rootconnexions SSH peut être assez dangereuse.
Eliah Kagan