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 [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:
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.
authorized_keys
archivo del usuario ?Respuestas:
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:
Me di cuenta de que la carpeta de inicio también necesita los permisos correctos:
Y reemplace con el nombre de usuario real, como "usuario".
¡Finalmente, el problema está resuelto!
fuente
chmod 755
en mi directorio personal me resolvió esto en DSM 6./usr/bin/sshd -p 2222
(y conéctesessh -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 sshnecesita cambiar su directorio de inicio a 755 (synology lo tiene en 777 por defecto)
fuente
chmod 755 /home/admin
realmente haya cambiado los permisos.Como sus permisos
.ssh
y 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
fuente
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:
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.
fuente
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 ¿? ¿?? ¿¿?
... y ahora funciona!
fuente
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:
Además, verifique el contenido de los
/etc/pam.d/sshd
cuales 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.htmlAquí es donde el problema muestra su cabeza fea:
No acepta id_rsa y continúa:
Se da por vencido y se basa en la contraseña
Entonces, la pregunta es ¿por qué no le gusta id_rsa?
fuente
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/passwd
archivo. Estaba configurado/sbin/nologin
por defecto. Después de cambiarlo,/bin/sh
pude SSH en mi Diskstation con éxito.fuente
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_keys
no eran correctos. Ejecutar lo siguiente solucionó el problemafuente