SSH sin contraseña (sin contraseña) en Synology DSM 5 como otro usuario (no root)

24

Estoy intentando ingresar a mi estación de disco Synology sin una contraseña (autenticación de clave pública), pero como no root.

Cuando trato de ssh como root sin contraseña, funciona. Seguir exactamente los mismos pasos para otro usuario no funciona. Siempre pide contraseña (también, usar una contraseña también funciona).

He seguido todas las guías para esto, pero creo que todas son para DSM 4.x en lugar de para la nueva versión 5.0.

Registro de depuración SSH

Aquí está el registro de depuración cuando intento con la bandera -vvv:

aether@aether-desktop:~$ ssh -vvv aether@aether-ds.local
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: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,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: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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,rijndael-cbc@lysator.liu.se
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,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
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
aether@aether-ds.local's password:

Cualquier ayuda apreciada.

Cosas que he probado hasta ahora

  • Verifique / etc / ssh / sshd_config (RSAAuthentication, PubkeyAuthentication, AuthorizedKeysFile).
  • Compruebe .ssh / * permisos y propiedad. Probé varias combinaciones.
  • Verifique HOME var en ~ / .profile.
  • Reinició sshd a través de synoservicectl - reinicie sshd y reiniciando todo el NAS.
linux  ssh  nas  synology 
— Vlad A Ionescu
fuente
¿Por qué quieres hacer esto? ¿No sería suficiente la autenticación de clave pública con una clave desprotegida?
— Daniel B
Hola Daniel, eso es exactamente lo que estoy tratando de lograr, pero no funciona para usuarios no root.
— Vlad A Ionescu
¿La clave pública de su cliente está presente en el authorized_keys archivo del usuario ?
— Daniel B
Sí, lo copié con ssh-copy-id. Y es exactamente el mismo archivo autorizado_keys (pero con permisos correctos) del usuario root, que funciona cuando es root.
— Vlad A Ionescu
¿Su cuenta tiene una contraseña ahora? Dependiendo de las políticas de seguridad de su sistema, los usuarios sin contraseña pueden tener prohibido iniciar sesión.
— Daniel B

Respuestas:

49

Yo tuve el mismo problema. Ejecuté una instancia de sshd en modo de depuración en DiskStation usando "/ usr / syno / sbin / sshd -d", luego me conecté usando "ssh user @ DiskSation -vvv" y obtuve la información de depuración en el servidor:

......

depuración1: temporalmente_uso_usuario: 1026/100 (e = 0/0)

debug1: probando el archivo de clave pública /var/services/homes/user/.ssh/authorized_keys

debug1: fd 5 borrando O_NONBLOCK

Autenticación rechazada: mala propiedad o modos para el directorio / volumen1 / hogares / usuario

......

Me di cuenta de que la carpeta de inicio también necesita los permisos correctos:

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

Y reemplace con el nombre de usuario real, como "usuario".

¡Finalmente, el problema está resuelto!

— usuario334026
fuente
2
Al igual que para ti, ejecutar chmod 755en mi directorio personal me resolvió esto en DSM 6.
— David Pärsson
Siempre es la solución correcta para obtener registros de depuración. ¡Gracias! Solo una adición: llame /usr/bin/sshd -p 2222(y conéctese ssh -p 2222) para que se ejecute en un puerto diferente para la depuración; de lo contrario, corre el riesgo de perder el acceso si abandona el demonio ssh
— Alex
16

necesita cambiar su directorio de inicio a 755 (synology lo tiene en 777 por defecto)

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
— datos espurios
fuente
Esto no muestra que chmod 755 /home/adminrealmente haya cambiado los permisos.
— user20342
Si eso es verdad. Sin embargo, lo hice, improvisé el ejemplo pegado y me lo perdí. Editaré la respuesta.
— spuriousdata
5

Como sus permisos .sshy claves_autorizadas están configurados correctamente, solo verifique que los permisos para su directorio de inicio ( /home/aether/) estén configurados correctamente ( chmod 755 /home/aether/).

No pude iniciar sesión con los permisos predeterminados ( 711) y funcionó después de cambiar los permisos.

Saludos Stephan

— Stephan
fuente
2

Tuve el mismo problema, doble y triple comprobando todo lo anterior y todavía no funcionaba. Finalmente, me di cuenta de que el demonio ssh estaba buscando el archivo autorizado_claves en el lugar incorrecto, ya que no hay un directorio / home / nonrootuser.

Debería crear la ruta o hacer un enlace simbólico (esas dos opciones no funcionaron para mí), o lo que finalmente funcionó fue agregar esas dos líneas en el archivo sshd_config:

Match User nonrootuser
AuthorizedKeysFile      /var/services/homes/nonrootuser/.ssh/authorized_keys

De esta manera, se asegura de que la clave que está agregando a través de ssh-copy-id del cliente sea la misma que el servidor (synology) ofrece para establecer la conexión para el usuario no root.

— usuario334008
fuente
2

El mismo problema aquí con dsm 6.0, resuelto gracias a este hilo en los foros de Synology

Parece que el permiso de inicio del usuario es demasiado permisivo ¿? ¿?? ¿¿? 

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

... y ahora funciona!

— Gonzalo Cao
fuente
1

Se ve muy similar a esa pregunta:

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

Sospecho que su directorio o archivos .ssh no tienen los atributos adecuados.

Aquí están los míos:

-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

Además, verifique el contenido de los /etc/pam.d/sshdcuales puede poner algunas restricciones en la no raíz. Por si acaso. Este enlace explica PAM en caso de RHEL. Puede ayudar: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/PAM_Configuration_Files.html

Aquí es donde el problema muestra su cabeza fea:

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

No acepta id_rsa y continúa:

debug1: Trying private key: /home/aether/.ssh/id_dsa
debug1: Trying private key: /home/aether/.ssh/id_ecdsa

Se da por vencido y se basa en la contraseña

debug1: Next authentication method: password

Entonces, la pregunta es ¿por qué no le gusta id_rsa?

— Grzegorz
fuente
Hola Grzegorz, el directorio .ssh tiene la permanente 700 y .ssh / autorizado_claves tiene las permanentes 600.
— Vlad A Ionescu
@VladAlexandruIonescu: He actualizado mi respuesta mostrando otros atributos e información sobre PAM que puede darle más área para probar.
— Grzegorz
Gracias, Grzegorz, pero todavía no tuve suerte. He probado exactamente los mismos permisos que los tuyos. También eché un vistazo a /etc/pam.d/sshd, pero no parece que nada discrimine al usuario root: gist.github.com/vlad-alexandru-ionescu/e6a2ee6133c7e9e45273 .
— Vlad A Ionescu
@VladAlexandruIonescu: ¿Es este problema para todos los usuarios? Usted escribió "para otro usuario" que puede indicar solo uno. ¿Puedes usar masilla usando este inicio de sesión de usuario o estás iniciando sesión como root y luego sumas?
— Grzegorz
Sí, para todos los usuarios no root. Puedo ssh / putty como cualquier usuario (root o no root). Pero solicita una contraseña cuando no es root, a pesar de que agregué la clave pública de mi cliente a autorizado_keys en el servidor.
— Vlad A Ionescu
1

Yo tuve el mísmo problema. Después de configurar los permisos correctos en mis directorios autorizados_claves, archivo de inicio y .ssh, todavía no podía enviar SSH a mi Diskstation.

Después de leer la información en techanic.net descubrí que también tenía que configurar mi shell de inicio de sesión en mi /etc/passwdarchivo. Estaba configurado /sbin/nologinpor defecto. Después de cambiarlo, /bin/shpude SSH en mi Diskstation con éxito.

— Rob Szumlakowski
fuente
0

Acabo de tener este mismo problema con DSM 5.1 en lugar de 5.0. Ninguna de las soluciones enumeradas resolvió el problema. En mi caso, los permisos para /var/services/homes/<user>/.ssh/authorized_keysno eran correctos. Ejecutar lo siguiente solucionó el problema

chmod 600 /var/servieces/homes/<user>/.ssh/authorized_keys
— Steven C. Howell
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.