J'ai essayé de configurer un ssh sans mot de passe b / w A
à B
et B
à A
ainsi. Généré la clé publique et privée en utilisant ssh-keygen -trsa
sur les deux machines. Utilisé l' ssh-copy-id
utilitaire pour copier les clés publique-de A
pour B
ainsi que B
pour A
.
Le SSH sans mot de passe fonctionne de A
à B
mais not
de 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 .
A
est une machine ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009) B
est 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-add
commande dans les deux machines.
La partie authentification du /etc/ssh/sshd_config
fichier 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.
PermitRootLogin
dans/etc/ssh/sshd_config
le A?yes
sinon l'utilisateur ne sera pas invité à entrer un mot de passe.Réponses:
Assurez-vous simplement que vous avez suivi la procédure suivante:
Sur la machine A
ouvrez un terminal et entrez les commandes comme suit:
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
su
commande1) Créez les clé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_keys
fichier de la machine BMaintenant, essayez de vous connecter à la machine, avec
ssh 'root@mylap'
, et enregistrez: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
Sur la machine B
4) Créez les clés pour vous reconnecter à la machine A
5) Copier la clé publique dans le
.ssh/authorized_keys
fichier de la machine AMaintenant, essayez de vous connecter à la machine, avec
ssh 'root@aneesh-pc'
, et enregistrez: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
Si vous pouvez suivre ces étapes, vous avez terminé. Vous avez maintenant deux machines avec la connexion activée par ssh-key (clé publique).
la source
/root
(770)drwxrwx--- 70 root root 4096 2011-07-27 00:37 ..
était trop ouverte. Changé les permissionsdrwxr-xr-x
et maintenant ça marche. Impossible d'imaginer le fait que l'autorisation du répertoire parent affecte lessh
.770
également été défini, a été remplacé par a750
et tout va bien pour le monde :) Il semble que j'oublie toujours que les prems de Linux peuvent fonctionner en sens inverse.Après avoir configuré ssh sans mot de passe , mon mot de passe utilisateur m’était toujours demandé. Regarder
/var/log/auth.log
sur la machine distante a souligné le problème:Alors, assurez-vous de bien le faire:
Il
.ssh
est é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_config
que les optionsRSAAuthentication
et lesPubkeyAuthentication
options ne sont pas désactivées. Par défautyes
, cela ne devrait pas poser de problème.la source
~/.ssh
autre nom, puis en créer un nouveau avec ma propre clé.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 ~ ~/.ssh
ouchmod go-w ~ ~/.ssh
.Si vous rencontrez toujours des problèmes, indiquez le grep suivant dans votre journal:
(remplacez
LOCAL_USER_NAME
par 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:
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.
la source
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 ~/.ssh
peut résoudre votre problèmeAutres choses à vérifier:
vérifiez que B
id_rsa.pub
est en question dans unauthorized_keys
.chèque A
/etc/ssh/sshd_config
contientla source
/etc/ssh/sshd_config
fichierdans / etc / ssh / sshd_config sur le changement de cible
à
puis tuez -HUP votre PID sshd:
la source
root
connexion SSH fonctionne. Cela n'a rien à voir avec le sujet de cette question. De plus, si leroot
compte est activé (il ne l’est pas par défaut dans Ubuntu), l’activation deroot
connexions SSH peut être assez dangereuse.