SSH sans mot de passe (sans mot de passe) sur Synology DSM 5 en tant qu'autre utilisateur (non root)

24

J'essaie de ssh dans ma station de disque Synology sans mot de passe (authentification par clé publique), mais en tant que non root.

Lorsque j'essaie de ssh en tant que root sans mot de passe, cela fonctionne. Suivre les mêmes étapes exactes pour un autre utilisateur ne fonctionne pas. Il demande toujours un mot de passe (également, l'utilisation d'un mot de passe fonctionne aussi).

J'ai suivi tous les guides pour cela, mais je pense qu'ils sont tous pour DSM 4.x plutôt que pour la nouvelle version 5.0.

Journal de débogage SSH

Voici le journal de débogage lorsque j'essaie avec l'indicateur -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.

Ce que j'ai essayé jusqu'à présent

  • Vérifiez / etc / ssh / sshd_config (RSAAuthentication, PubkeyAuthentication, AuthorizedKeysFile).
  • Vérifiez les autorisations et la propriété .ssh / *. J'ai essayé plusieurs combinaisons.
  • Vérifiez HOME var dans ~ / .profile.
  • Redémarrer sshd via synoservicectl --restart sshd et en redémarrant le NAS entier.
linux ssh nas synology Vlad A Ionescu
la source
Pourquoi veux-tu faire cela? Une authentification par clé publique avec une clé non protégée ne suffirait-elle pas?
Daniel B
Salut Daniel, c'est exactement ce que j'essaie de réaliser, mais cela ne fonctionne pas pour les utilisateurs non root.
Vlad A Ionescu
La clé publique de votre client est-elle présente dans le authorized_keys fichier de l'utilisateur ?
Daniel B
Ouais, je l'ai copié avec ssh-copy-id. Et c'est exactement le même fichier authorized_keys (mais avec les bonnes autorisations) de l'utilisateur root, qui fonctionne lorsque root.
Vlad A Ionescu
Votre compte a-t-il un mot de passe maintenant? Selon les politiques de sécurité de votre système, les utilisateurs sans mot de passe peuvent se voir interdire de se connecter.
Daniel B

Réponses:

49

J'ai eu le même problème. J'exécute une instance de sshd en mode débogage sur le DiskStation en utilisant "/ usr / syno / sbin / sshd -d", puis je me connecte avec "ssh user @ DiskSation -vvv" et j'ai obtenu les informations de débogage sur le serveur:

......

debug1: temporairement_use_uid: 1026/100 (e = 0/0)

debug1: essai du fichier de clé publique /var/services/homes/user/.ssh/authorized_keys

debug1: fd 5 effacement O_NONBLOCK

Authentification refusée: mauvaise propriété ou modes pour le répertoire / volume1 / homes / user

......

J'ai réalisé que le dossier de base avait également besoin des bonnes autorisations:

cd /var/services/homes/
chown <username> <username>
chmod 755 <username>

Et remplacez-le par le nom d'utilisateur réel, comme "utilisateur".

Enfin, le problème est résolu!

user334026
la source
2
Tout comme pour vous, l'exécution chmod 755sur mon répertoire personnel a résolu cela pour moi sur DSM 6.
David Pärsson
C'est toujours la bonne solution pour obtenir des journaux de débogage. Merci! Un seul ajout: appelez /usr/bin/sshd -p 2222(et connectez-vous ssh -p 2222) pour qu'il s'exécute sur un port différent pour le débogage - sinon vous risquez de perdre l'accès si vous quittez le démon ssh
Alex
16

vous devez modifier votre répertoire personnel à 755 (la synologie 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
données parasites
la source
Cela ne montre pas que chmod 755 /home/adminréellement changé les autorisations.
user20342
Ouais c'est vrai. Il l'a fait cependant, j'ai juste bricolé l'exemple collé et je l'ai raté. Je vais modifier la réponse.
spuriousdata
5

Comme vos autorisations pour .sshet authorized_keys sont définies correctement, vérifiez simplement que les autorisations pour votre répertoire personnel ( /home/aether/) sont définies correctement ( chmod 755 /home/aether/).

Je n'ai pas pu me connecter avec les autorisations par défaut ( 711) et cela a fonctionné après avoir modifié les autorisations.

Cheers stephan

Stephan
la source
2

J'ai eu le même problème, en vérifiant deux ou trois fois tout ce qui précède et je n'ai toujours pas fonctionné. Enfin, j'ai réalisé que le démon ssh cherchait le fichier authorized_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 fonctionnaient pas pour moi), 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 racine.

user334008
la source
2

Même problème ici avec dsm 6.0, résolu grâce à ce fil sur les forums Synology

Il semble que la permission de l'utilisateur à la maison soit trop permissive ¿? ¿?? ¿¿? 

chmod 755 /var/services/homes/[username]

... et maintenant ça marche!

Gonzalo Cao
la source
1

Cela ressemble beaucoup à cette question:

/programming/12839106/scp-between-2-remote-hosts-without-password/12945060#12945060

Je soupçonne que votre répertoire ou vos fichiers .ssh n'ont pas d'attributs appropriés.

Voici les miennes:

-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

De plus, veuillez vérifier le contenu /etc/pam.d/sshdqui peut imposer des restrictions sur les non-root. Au cas où. Ce lien explique PAM en 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ù le problème 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 un mot de passe

debug1: Next authentication method: password

Alors maintenant, la question est pourquoi il n'aime pas id_rsa?

Grzegorz
la source
Salut Grzegorz, le dir .ssh a une perm 700 et .ssh / authorized_keys a une perm 600.
Vlad A Ionescu
@VladAlexandruIonescu: J'ai mis à jour ma réponse en montrant d'autres attributs et des informations concernant PAM qui peuvent vous donner plus d'espace pour tester.
Grzegorz
Merci, Grzegorz, mais toujours pas de chance. J'ai essayé exactement les mêmes perms que les vôtres. A également regardé autour de /etc/pam.d/sshd, mais ne semble pas que quoi que ce soit puisse discriminer l'utilisateur root: gist.github.com/vlad-alexandru-ionescu/e6a2ee6133c7e9e45273 .
Vlad A Ionescu
@VladAlexandruIonescu: Ce problème est-il pour tous les utilisateurs? Vous avez écrit "pour un autre utilisateur" qui peut en indiquer un seul. Pouvez-vous mastic en utilisant cette connexion utilisateur ou vous vous connectez en tant que root, puis le su?
Grzegorz
Oui, pour tous les utilisateurs non root. Je peux ssh / putty comme n'importe quel utilisateur (root ou non root). Mais il demande un mot de passe lorsqu'il n'est pas root, même si j'ai ajouté la clé publique de mon client aux clés autorisées sur le serveur.
Vlad A Ionescu
1

J'ai eu le même problème. Après avoir configuré les autorisations correctes sur mes répertoires de clés autorisées, de fichier d'accueil et .ssh, je ne pouvais toujours pas SSH sur mon Diskstation.

Après avoir lu les informations sur techanic.net, j'ai découvert que je devais également définir mon shell de connexion dans mon /etc/passwdfichier. Il a été défini /sbin/nologinpar défaut. Après l'avoir changé en, /bin/shj'ai réussi à SSH sur mon Diskstation avec succès.

Rob Szumlakowski
la source
0

Je viens d'avoir ce même problème avec DSM 5.1 au lieu de 5.0. Aucune des solutions répertoriées n'a résolu le problème. Dans mon cas, les autorisations pour /var/services/homes/<user>/.ssh/authorized_keysn'étaient pas correctes. L'exécution de ce qui suit a résolu le problème

chmod 600 /var/servieces/homes/<user>/.ssh/authorized_keys
Steven C. Howell
la source