SSH sans mot de passe (sans mot de passe) sur Synology DSM 5 en tant qu'autre utilisateur (non root)
J'essaie de faire entrer SSH sur mon disque Synology sans mot de passe (authentification par clé publique), mais en tant qu'utilisateur non root.
Quand j'essaie de ssh en tant que root sans mot de passe, cela fonctionne. Suivre exactement les mêmes étapes pour un autre utilisateur ne fonctionne pas. Il demande toujours un mot de passe (aussi, utiliser un mot de passe fonctionne aussi).
J'ai suivi tous les guides pour cela, mais je pense qu'ils sont tous destinés à DSM 4.x plutôt qu'à la nouvelle version 5.0.
Journal de débogage SSH
Voici le journal de débogage lorsque j'essaie avec l'option -vvv:
aether@aether-desktop:~$ ssh -vvv [email protected]
OpenSSH_6.2p2 Ubuntu-6ubuntu0.2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to aether-ds.local [192.168.2.149] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/aether/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/aether/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/aether/.ssh/id_rsa-cert type -1
debug1: identity file /home/aether/.ssh/id_dsa type -1
debug1: identity file /home/aether/.ssh/id_dsa-cert type -1
debug1: identity file /home/aether/.ssh/id_ecdsa type -1
debug1: identity file /home/aether/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for Host "aether-ds.local" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server Host key: RSA f1:57:47:37:47:d4:5c:cd:a7:a4:5a:9c:a3:e8:1d:13
debug3: load_hostkeys: loading entries for Host "aether-ds.local" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for Host "192.168.2.149" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'aether-ds.local' is known and matches the RSA Host key.
debug1: Found key in /home/aether/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/aether/.ssh/id_rsa (0x7f4ee2f47200),
debug2: key: /home/aether/.ssh/id_dsa ((nil)),
debug2: key: /home/aether/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,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: Offering RSA public key: /home/aether/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/aether/.ssh/id_dsa
debug3: no such identity: /home/aether/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/aether/.ssh/id_ecdsa
debug3: no such identity: /home/aether/.ssh/id_ecdsa: No such file or directory
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:
Toute aide appréciée.
Choses que j'ai essayées jusqu'à présent
- Vérifiez/etc/ssh/sshd_config (RSAAuthentication, PubkeyAuthentication, AuthorizedKeysFile).
- Vérifiez .ssh/* perms et la propriété. J'ai essayé plusieurs combinaisons.
- Vérifiez HOME var dans ~/.profile.
- Sshd redémarré via synoservicectl --restart sshd et en redémarrant l’ensemble du NAS.
J'ai eu le même problème. Je lance une instance de sshd en mode débogage sur le DiskStation avec "/ usr/syno/sbin/sshd -d", puis je me connecte via "ssh user @ DiskSation -vvv" et j'ai reçu les informations de débogage sur le serveur:
......
debug1: timing_use_uid: 1026/100 (e = 0/0)
debug1: essai du fichier de clé publique /var/services/homes/user/.ssh/authorized_keys
debug1: fd 5 effaçant O_NONBLOCK
Authentification refusée: mauvaise propriété ou modes de répertoire/volume1/homes/user
......
J'ai réalisé que le dossier de base a également besoin des autorisations appropriées:
cd /var/services/homes/
chown <username> <username>
chmod 755 <username>
Et remplacez-le par le nom d'utilisateur actuel, comme "utilisateur".
Enfin, le problème est résolu!
vous devez chmod votre répertoire personnel à 755 (Synology l'a 777 par défaut)
nas> ls -al
total 28
drwxrwxrwx 6 root root 4096 2014-07-13 03:00 .
drwxr-xr-x 13 root root 4096 2014-07-13 03:00 ..
drwxrwxrwx 3 admin users 4096 2014-07-13 03:00 admin
...
nas> chmod 755 /home/admin
nas> ls -al
total 28
drwxrwxrwx 6 root root 4096 2014-07-13 03:00 .
drwxr-xr-x 13 root root 4096 2014-07-13 03:00 ..
drwxr-xr-x 3 admin users 4096 2014-07-13 03:00 admin
Comme vos autorisations pour .ssh et allowed_keys sont définies correctement, vérifiez simplement que les autorisations de votre répertoire de base (/home/aether/) sont correctement définies (chmod 755 /home/aether/).
Je ne pouvais pas me connecter avec les autorisations par défaut (711) et cela a fonctionné après la modification des autorisations.
A bientôt Stephan
Même problème ici avec dsm 6.0, résolu grâce à ce fil sur les forums Synology
Il semble que la permission à la maison de l’utilisateur soit trop permissive.
chmod 755 /var/services/homes/[username]
... et maintenant ça marche!
J'ai eu le même problème, double et triple vérification tout ce qui précède et n'a toujours pas fonctionné. Enfin, j'ai réalisé que le démon ssh cherchait le fichier registered_keys au mauvais endroit car il n'y a pas de répertoire/home/nonrootuser.
Vous devez créer le chemin ou créer un lien symbolique (ces deux options ne m'ont pas fonctionné), ou ce qui a finalement fonctionné a été d'ajouter ces deux lignes dans le fichier sshd_config:
Match User nonrootuser
AuthorizedKeysFile /var/services/homes/nonrootuser/.ssh/authorized_keys
De cette façon, vous vous assurez que la clé que vous ajoutez via ssh-copy-id à partir du client est la même que celle proposée par le serveur (Synology) pour établir la connexion pour le non-utilisateur root.
J'ai eu le même problème. Après avoir configuré les autorisations correctes sur les répertoires home et .ssh de authorised_keys, je ne pouvais toujours pas utiliser SSH sur mon Diskstation.
Après avoir lu les informations sur techanic.net , j’ai découvert que je devais aussi définir mon identifiant de connexion Shell dans mon fichier /etc/passwd. Il a été défini sur /sbin/nologin par défaut. Après l'avoir changé en /bin/sh, j'ai pu passer à SSH sur mon Diskstation avec succès.
Cela ressemble beaucoup à cette question:
Je suspecte que votre répertoire ou vos fichiers .ssh ne possèdent pas les attributs appropriés.
Voici les miens:
-rw-r--r-- 1 root root 393 Aug 13 2012 if_rsa.pub
-rw------- 1 root root 1675 Aug 13 2012 if_rsa
-rw-r--r-- 1 root root 393 Aug 20 2012 id_rsa.pub
-rw------- 1 root root 1675 Aug 20 2012 id_rsa
-rw------- 1 root root 4606 Aug 7 2013 authorized_keys
drwx------ 2 root root 4096 Feb 24 09:59 .
-rw-r--r-- 1 root root 11354 Mar 25 17:28 known_hosts
Consultez également le contenu de /etc/pam.d/sshd, qui peut imposer certaines restrictions aux utilisateurs non root. Au cas où. Ce lien explique PAM dans le cas de RHEL. Cela peut aider: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/PAM_Configuration_Files.html
Voici où la question montre sa tête laide:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/aether/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
Il n'accepte pas id_rsa et continue:
debug1: Trying private key: /home/aether/.ssh/id_dsa
debug1: Trying private key: /home/aether/.ssh/id_ecdsa
Il abandonne et s'appuie sur le mot de passe
debug1: Next authentication method: password
Alors maintenant, la question est pourquoi il n’aime pas id_rsa?
Je viens d'avoir ce même problème avec DSM 5.1 au lieu de 5.0. Aucune des solutions énumérées n'a résolu le problème. Dans mon cas, les autorisations pour /var/services/homes/<user>/.ssh/authorized_keys étaient incorrectes. Exécuter le suivant a résolu le problème
chmod 600 /var/servieces/homes/<user>/.ssh/authorized_keys