Desde DSM 6.2.2, tenemos problemas para conectarnos a un Synology NAS como usuario no administrador a través de ssh. Antes, esto era posible simplemente cambiando el shell de inicio de sesión /etc/passwdde /sbin/nologina /bin/sh. Esto ya no parece funcionar.
Además, intenté editar /etc/ssh/sshd_confexplícitamente AllowUserspero fue en vano. Parece que el cliente realiza una autenticación exitosa pero luego algún módulo PAM (?) cierra la conexión nuevamente.
¿Alguien ha trabajado ssh como no administrador en la última versión de DSM?
Esta es la salida del registro:
2019-05-23T21:55:36+02:00 hostname sshd[13551]: pam_unix(sshd:session): session opened for user test by (uid=0)
2019-05-23T21:55:36+02:00 hostname sshd[13551]: pam_unix(sshd:session): session closed for user test
Respuesta1
En DiskStations que cuentan con Docker, me resultó más fácil usar un contenedor OpenSSH. Fui por linuxserver/openssh-server. De esa manera puedo montar solo los datos relevantes en el contenedor y no tengo que meterme con las configuraciones de Synology.
Respuesta2
Esta es una solución al problema de no poder iniciar sesión en Synology NAS a través de ssh a menos que sea miembro del grupo de Administradores. Al leer varias publicaciones sobre esto en línea, este problema está presente en DSM 6.2.x
Hay muchas razones válidas por las que a un usuario se le puede dar acceso ssh. Al mismo tiempo, no todos los usuarios necesitan acceso de administrador, por lo que parece que Synology Inc. ha tomado una mala decisión al imponer esta regla. No he encontrado una manera de solucionar este problema usando el sshd estándar, así que compilé mi propio sshd.
No asumo ninguna responsabilidad si derrama su café, tropieza en su silla y cae sobre su gato, o si sufre algún daño debido a esta guía. Pero a partir de octubre de 2019, se prueba que todo funciona en mi laboratorio.
Empecemos.
Sistema en el que se probó:
Synology DS418j with DSM 6.2.2-24922 Update 3, Linux hostname 4.4.59+
#24922 aarch64 GNU/Linux synology_rtd1296_ds418j
Qubes release 4.0 (R4.0) with an App-VM running Fedora release 30 (Thirty)
Requisitos previos:
- Un Synology NAS al que puede acceder a través de ssh con un usuario existente que esté en el grupo de administradores.
- Un entorno Linux, esto podría virtualizarse. En Mac, una terminal del sistema debería ser suficiente. Para seguir mi ejemplo textualmente, opte por una instalación de Fedora 30. Si usa Ubuntu, al menos necesita usar apt-get en lugar de dnf, también puede haber otros elementos específicos de la distribución.
Advertencia, si está acostumbrado a utilizar 'make install' al instalar software de Linux. No lo hagas cuando sigas esta guía, a menos que sepas lo que estás haciendo y te desvíes de la guía. Si lo hace, podría dañar su sistema. Además, no es necesario ser nada más que un usuario común y corriente mientras se trabaja en esta guía, desde la perspectiva del host compilador. Sólo ocasionalmente se necesita sudo.
Además, si por cualquier motivo logra dañar su demonio ssh, siempre puede habilitar telnet a través de la interfaz de usuario web de DSM y conectarse a Synology cli a través de telnet para rectificar lo que hizo mal. Además, es aconsejable tomar nota de todo lo que está haciendo y hacer una copia de seguridad de todos los archivos que está reemplazando y de todos los archivos que está modificando antes de hacerlo. Tenga en cuenta que si está realizando esta guía, trabajando con un servidor Synology remoto y no está completamente seguro de lo que está haciendo, existe un peligro posible de que se bloquee del servidor. Al menos, asegúrese de tener una salida, como manos de administrador en el sitio que puedan recuperar el acceso.
Synology y DS (Disk Station) se utilizarán indistintamente en el resto de la guía.
Dado que Synology Inc. aparentemente ha alterado el binario sshd original, lo que esta guía le enseñará a hacer es agregar un binario sshd que dará acceso ssh al cuadro de Synology para usuarios fuera del grupo de administradores.
Curiosamente, es posible hacer algo llamado compilación cruzada, lo que significa que puedes compilar software en una plataforma que se puede ejecutar en otra plataforma.
El código fuente de openssh está disponible, al igual que sus dependencias. Esto significa que podemos compilarlo en un sistema Linux y ejecutarlo en Synology con una CPU ARM.
En primer lugar, obtenga acceso a una máquina Linux. Si no tiene Linux instalado, descargue software de virtualización como vmware o virtualbox e instale o cargue una máquina virtual Linux. También podría funcionar usando cygwin como subsistema en Windows. Consulte la documentación respectiva para esto.
Tenga en cuenta que es posible que ciertos elementos de esta guía no se ajusten a sus circunstancias específicas; ajuste su recorrido a través de esta guía en consecuencia. Esta guía debería brindarle algunos consejos para solucionar el problema de ssh, incluso si no tiene exactamente la misma configuración que yo.
En primer lugar, averigüe qué procesador tiene su DS.
Encuentre su modelo de Synology específico aquí:https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/What_kind_of_CPU_does_my_NAS_have
También verifique una sesión ssh en su terminal Synology, uname -a debería darle algunas pistas.
En mi caso, tanto el enlace del Centro de soporte de Synology como el resultado de uname -a muestran que tengo una CPU Realtek RTD1293, es un procesador ARM, para obtener más información interesante, consultehttps://en.wikichip.org/wiki/arm/aarch64
Por lo tanto, necesitamos obtener las fuentes y realizar una compilación cruzada en la computadora portátil con Linux, para que podamos enviar el binario a Synology y eludir la restricción de inicio de sesión.
Antes de continuar, verifique que puede acceder mediante ssh a su synology; si su ssh-fu es fuerte, es posible que haya configurado una entrada en su ~/.ssh/config con este aspecto:
#My synology
Host DS
Port 22
Hostname 192.168.10.100
User localuser
IdentityFile /home/localuser/.ssh/id_ed25519
Sustituya las variables por lo que dicte su situación local.
Como mínimo, debería poder iniciar sesión en su Synology ejecutando un comando como ssh[correo electrónico protegido]. Si tiene un archivo de identidad no predeterminado o un puerto no predeterminado, agregue esos parámetros. Cómo configurar ssh sin contraseña está fuera del alcance de esta guía. Tenga en cuenta que Synology también es exigente con los permisos de todos los archivos y directorios que pertenecen a un usuario, antes de permitir el inicio de sesión ssh. Hay muchas publicaciones en línea sobre esto. Sin embargo, puede continuar utilizando el inicio de sesión con contraseña, pero si está en una red local y utiliza dispositivos de consumidor final que son privados, es más conveniente usar claves ssh para iniciar sesión en ssh. También puede utilizar frases de contraseña en sus claves privadas. También verifique que cuando inicie sesión con su usuario existente pueda hacer sudo whoami. Esto debería solicitarle su contraseña de sudo, a menos que haya configurado sudo para que no necesite una contraseña para su usuario, y verá "root" después de presionar la tecla Intro.
¡¡Ahora viene la parte divertida!!
En su instancia de Linux (¿fedora?), inicie sesión, inicie una terminal, cree un directorio de proyecto e ingréselo.
mkdir ~/crosscompile ; cd ~/crosscompile
Utilice un navegador web en su instancia de Linux y vaya ahttps://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/, busque la última versión en la parte inferior. Pr. Octubre de 2019, esto es openssh-8.1p1.
Regrese a la terminal de Linux y descárguelo. Usaré 8.1p1, pero use la versión más nueva si ve esta guía cuando se haya realizado una nueva versión.
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz.asc
La segunda línea obtiene la firma PGP del archivo.
Ahora, si aún no está instalado, instale pgpdump:
sudo dnf install pgpdump
Proceder con
pgpdump openssh-8.1p1.tar.gz.asc
Salida de muestra:
Old: Signature Packet(tag 2)(451 bytes)
Ver 4 - new
Sig type - Signature of a binary document(0x00).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA512(hash 10)
Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
v4 - Fingerprint - 59 c2 11 8e d2 06 d9 27 e6 67 eb e3 d3 e5 f5 6b 6d 92 0d 30
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Wed Oct 9 02:39:36 CEST 2019
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xD3E5F56B6D920D30
Hash left 2 bytes - 1c 52
RSA m^d mod n(3195 bits) - ...
-> PKCS-1
Tenga en cuenta el ID de clave, 0xD3E5F56B6D920D30 (puede diferir para una versión más nueva). También tome nota de la huella digital, volveremos a eso.
Ahora, instale gpg2 si no está instalado;
sudo dnf install gpg2.
Obtenga la clave pgp del liberador:
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/DJM-GPG-KEY.asc
Importarlo:
gpg2 --import DJM-GPG-KEY.asc
Obtenga la clave de liberación e impórtela:
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc
gpg2 --import RELEASE_KEY.asc
Ahora verifica la descarga:
gpg2 --verify openssh-8.1p1.tar.gz.asc openssh-8.1p1.tar.gz
Resultado:
gpg: Signature made Wed Oct 9 02:39:36 2019 CEST
gpg: using RSA key 59C2118ED206D927E667EBE3D3E5F56B6D920D30
gpg: Good signature from "Damien Miller <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30
Tenga en cuenta que la huella digital coincide con lo que nos dijo pgpdump a partir de la firma pgp. Todo parece bueno. Si le preocupa que una firma no confíe en la clave, deberá editar la confianza de la clave usted mismo o pedirle a alguien que lo haga. Si tiene una instalación muy crítica, una opción es comunicarse con Damien Miller y pedirle que lea la huella digital. ¡Probablemente deberías compensarlo por eso!
De todos modos, para garantizar que la descarga sea lo más segura posible, deberás verificar con varias fuentes, así que intentémoslo.
Una búsqueda rápida revela lo que aparentemente es el blog de Miller. Y esta publicación da algunos más detalles:
http://blog.djm.net.au/2013/12/pgp-keys-rotated.html
Ahora copie todo ese blob de claves en un archivo en el disco, luego haga un nombre de archivo pgpdump en él.
Esto debería darte un resultado como este:
pgpdump keyblob | grep 0D30 | grep fin
Key fingerprint = 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30
Si tiene curiosidad, copie el resultado completo del comando en un editor de texto y busque '0xD3E5F56B6D920D30' como se mencionó anteriormente en la guía. Luego verá que la clave de liberación es una subclave de la clave personal de Miller.
Bien, en este punto, asumimos que la descarga de openssh es correcta.
Desempaquetar openssh:
tar xvzf openssh-8.1p1.tar.gz
Debes determinar qué cadena de herramientas necesitas:https://originhelp.synology.com/developer-guide/compile_applications/download_dsm_tool_chain.html
En mi caso descargué el que necesitaba con este comando:
wget https://sourceforge.net/projects/dsgpl/files/DSM%206.2.2%20Tool%20Chains/Realtek%20RTD129x%20Linux%204.4.59/rtd1296-gcc494_glibc220_armv8-GPL.txz/download -O rtd1296-gcc494_glibc220_armv8-GPL.txz
Afaik, no hay forma de verificar la descarga. Lo subí a virustotal y no se encontraron motores.
Extraiga la cadena de herramientas:
sudo tar Jxvf rtd1296-gcc494_glibc220_armv8-GPL.txz -C /usr/local
Además necesitamos zlib y openssl.
wget https://zlib.net/zlib-1.2.11.tar.gz
wget https://zlib.net/zlib-1.2.11.tar.gz.asc
(También aquí, busque una versión más reciente)
pgpdump zlib-1.2.11.tar.gz.asc | grep ID
proporciona ID de clave: 0x783FCD8E58BCAFBA
Búscalo e impórtalo:
wget http://pgp.key-server.io/download/0x783FCD8E58BCAFBA
gpg2 --import 0x783FCD8E58BCAFBA
Verificar la descarga:
gpg2 --verify zlib-1.2.11.tar.gz.asc zlib-1.2.11.tar.gz
Esto debería dar una buena firma de Mark Adler.[correo electrónico protegido]
En este punto, puede utilizar la huella digital o la clave DSA para intentar encontrar referencias en otros lugares de la web, si necesita más verificación.
Extract zlib: tar xvzf zlib-1.2.11.tar.gz
También necesitamos openssl:
wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz
wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256
wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.asc
sha256sum openssl-1.1.1d.tar.gz gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2
cat openssl-1.1.1d.tar.gz.sha256 gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2
Ahora hemos verificado la integridad del archivo. Comprobemos la firma también.
pgpdump openssl-1.1.1d.tar.gz.asc | grep -E "Fin|ID"
Resultados:
v4 - Fingerprint - 86 57 ab b2 60 f0 56 b1 e5 19 08 39 d9 c4 d2 6d 0e 60 44 91
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xD9C4D26D0E604491
Obtengamos la clave e importemosla al llavero:
wget http://pgp.key-server.io/download/0xD9C4D26D0E604491
gpg2 --import 0xD9C4D26D0E604491
Resultado:
gpg: key D9C4D26D0E604491: public key "Matt Caswell <[email protected]>" imported
Ahora verificamos la descarga:
gpg2 --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz
gpg: Signature made Tue Sep 10 15:13:14 2019 CEST
gpg: using RSA key 8657ABB260F056B1E5190839D9C4D26D0E604491
gpg: Good signature from "Matt Caswell <[email protected]>" [unknown]
gpg: aka "Matt Caswell <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8657 ABB2 60F0 56B1 E519 0839 D9C4 D26D 0E60 4491
Coincidencia de huellas dactilares, y aquí también se puede encontrar una referencia a la misma huella digital:https://wiki.freebsd.org/OpenSSL/Base/Update111
Debemos asumir en este punto que todo el software que descargamos está verificado y está bien, ¡ahora construyamos el binario ARM sshd!
cd zlib-1.2.11
Configuremos zlib:
CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./configure
Entonces hazlo:
make
Verifiquemos:
ls -l libz*
Ahora debería mostrar algo como esto:
-rw-rw-r-- 1 user user 155378 Oct 20 04:45 libz.a
lrwxrwxrwx 1 user user 14 Oct 20 04:45 libz.so -> libz.so.1.2.11
lrwxrwxrwx 1 user user 14 Oct 20 04:45 libz.so.1 -> libz.so.1.2.11
-rwxrwxr-x 1 user user 133664 Oct 20 04:45 libz.so.1.2.11
¡Excelente usuario de Synology! ¡Compilemos openssl!
Extraigamoslo y cambiemos al directorio de trabajo:
cd .. && tar xvzf openssl-1.1.1d.tar.gz && cd openssl-1.1.1d
Luego lo configuramos:
CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./Configure linux-generic64 shared -DL_ENDIAN --prefix=/home/user0/opensslArm --openssldir=/home/user/opensslArm CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc RANLIB=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ranlib AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld MAKEDEPPROG=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc PROCESSOR=ARM
Ahora hagámoslo:
make
Esto lleva un tiempo, así que tenga paciencia.
Comprobémoslo:
ls lib*so*
deberia dar
libcrypto.so libcrypto.so.1.1 libssl.so libssl.so.1.1
¡Felicitaciones, estás cada vez más cerca de hacer que esto suceda de verdad!
¡Compilemos openssh!
Primero debemos configurarlo:
./configure --host=arm-linux --with-libs --with-zlib=/home/user/crosscompile/zlib-1.2.11 --with-ssl-dir=/home/user/crosscompile/openssl/openssl-1.1.1d --disable-etc-default-login CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar
Ahora, hazlo:
make
Ahora se crean varios binarios ejecutables en ~/crosscompile/openssh-8.1p1
Veamos si podemos iniciar sesión con un usuario normal a través de ssh en DS, utilizando el nuevo binario sshd que hemos creado. A estas alturas debería tener un inicio de sesión sin contraseña en DS con un usuario existente que pertenezca al grupo de administradores.
Copiemos el nuevo sshd y libcrypto al DS:
scp ~/crosscompile/openssh-8.1p1/sshd DS:~/newsshd
scp ~/crosscompile/openssl-1.1.1d/libcrypto.so.1.1 DS:~
Luego hagamos ssh a DS de la manera habitual:
ssh DS
Luego hagamos una copia de sshd_config:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_new
Edite el nuevo archivo de configuración:
vim /etc/ssh/sshd_config_new
Cambie 'UsePAM sí' por '#UsePAM sí'
Descomentar HostKey /etc/ssh/ssh_host_ed25519_key
Guardar y Salir.
Cambie la propiedad del nuevo sshd:
sudo chown root:root newsshd
Ahora necesitamos hacer una ligera edición de un par de archivos. Primero haga una copia de seguridad de los archivos que vamos a editar:
sudo cp /etc/passwd /etc/passwd.org && sudo cp /etc/group /etc/group.org
Inserte esta línea en la parte inferior de /etc/passwd:
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
Asimismo, inserte esta línea al final de /etc/group :
/etc/group:sshd:*:27:
Si no realiza los cambios anteriores, obtendrá el mensaje "El usuario de separación de privilegios sshd no existe" cuando ejecute el binario sshd que acaba de transferir.
¡Ahora hagamos una prueba de conexión!
En DS:
sudo LD_LIBRARY_PATH="/absolutepathtohomedir:$LD_LIBRARY_PATH" /absolutepathtohomedir/newsshd -p 444 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key -d
Esto iniciará el nuevo binario sshd en modo de depuración.
Ahora puede conectarse a esto normalmente desde su instancia de Linux con
ssh -p 444 user@DS
POR FIN - EL GRAN REEMPLAZO.
Asegúrate de tomar nota de todo lo que haces y guárdalo en algún lugar, junto con los archivos que tienes. Synology Inc. es conocido por reemplazar a veces ediciones y archivos al realizar actualizaciones. Si esto sucede, debe habilitar telnet a través de DSM e iniciar sesión a través de telnet en la red local para restaurar la configuración. Posiblemente, podría configurar un cronjob para monitorear el sistema y revertir automáticamente cualquier cambio que venga junto con una actualización. Dependiendo de su configuración, es posible que no necesite actualizar DSM con mucha frecuencia si ya se encuentra en una red muy segura y segmentada.
Los binarios relevantes que hemos compilado para la arquitectura ARM residen en ~/crosscompile/openssh-8.1p1:
- ./ssh-agent (agente de autenticación)
- ./sftp-server (subsistema de servidor SFTP)
- ./ssh (cliente OpenSSH SSH (programa de inicio de sesión remoto))
- ./ssh-keyscan (recopila claves públicas ssh)
- ./ssh-keygen (generación, gestión y conversión de claves de autenticación)
- ./sftp (programa de transferencia segura de archivos)
- ./ssh-keysign (deshabilitado de forma predeterminada)
- ./ssh-add (agrega identidades RSA o DSA al agente de autenticación)
- ./scp (copia segura (programa de copia remota de archivos))
- ./ssh-pkcs11-helper (ssh-agent (programa auxiliar para soporte de PKCS#11)
- ./sshd (demonio OpenSSH SSH)
Debes decidir cuál de estos necesitas. Si sólo va a utilizar sshd y scp, entonces podría ser suficiente reemplazar estos binarios.
En primer lugar, edite el archivo /etc/ssh/sshd_config original, comente 'UsePAM yes' a '#UsePAM yes', luego descomente 'HostKey /etc/ssh/ssh_host_ed25519_key'.
Realmente deberías usar claves ed25519, si usas otros tipos de claves, descomenta en consecuencia.
Asegurémonos de que el soporte de openssl esté disponible.
En mi DS, esto no sobrescribe nada, su kilometraje varía. Compruebe si el objetivo ya existe. Lo he hecho de esta manera, ya que es un método simple para que esto funcione. Posiblemente el archivo de objeto compartido podría colocarse en una ruta personalizada y agregarse a la ruta de búsqueda de archivos de objetos compartidos.
sudo mv ~/libcrypto.so.1.1 /usr/lib/
Busque la ubicación de los archivos que desea reemplazar:
which sshd ; which scp
Resultado:
/bin/sshd
/bin/scp
Haga una copia de seguridad de estos dos archivos.
sudo cp /bin/sshd /bin/sshd.DS.orginal
sudo cp /bin/scp /bin/scp.DS.orginal
Salga a la instancia de Linux y copie el archivo scp recién creado:
scp scp DS:~
Ssh a DS, mueva el archivo scp y establezca la propiedad correcta:
sudo mv ~/scp /bin
sudo chown root:root /bin/scp
Dado que /bin/sshd está activo, no se puede sobrescribir, por lo que debemos eliminarlo. Pero antes de esto necesitamos haber iniciado nuestro sshd recién creado para tener una ruta alternativa al DS.
Inicie una nueva terminal en su instancia de Linux y envíe ssh a DS de la forma habitual:
ssh DS
Luego, genera una instancia de tu nuevo servidor sshd:
sudo /absolutepathtohomedir/newsshd -p 777 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key
Salga de la sesión ssh e intente iniciar sesión en una sesión controlada por el binario ssh recién generado:
ssh -p 777 user@DS
Ahora, elimine el servidor ssh original en el puerto 22.
sudo su
luego edite la configuración ssh
vim /etc/init/sshd.conf
Comente las líneas de reaparición, para que se vean como a continuación:
#respawn
#respawn limit 5 10
Entonces:
netstat -ap | grep ssh
Encuentra la identificación del proceso a la derecha.
La línea debería verse así:
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN 9508/sshd
Detener ssh-shell
synoservice --hard-stop ssh-shell
Mata el proceso sshd.
kill -9 9508
Verifique si el proceso finalizó y no hay nada escuchando en el puerto 22:
netstat -tpa | grep 22
Posiblemente necesite cerrar otras instancias de sshd, si ha experimentado con varios puertos durante esta guía.
Si todo falla, puedes desactivar ssh a través de DSM.
Finalmente:
cp /fullhomepath/newsshd /bin/sshd && chown root:root /bin/sshd
Invierta los comentarios de reaparición realizados anteriormente en /etc/init/sshd.conf
Cree este enlace simbólico ya que el nuevo sshd se queja de que el archivo sshd_config local no existe
ln -s /etc/ssh/sshd_config /usr/local/etc/sshd_config
Vuelva a habilitar sshd:
synoservice --hard-enable ssh-shell
Ahora, verifica que los archivos copiados coincidan con los compilados:
En DS:
sha256sum /bin/sshd /bin/scp
En la instancia de Linux:
sha256sum ~/crosscompile/openssh-8.1p1/sshd ~/crosscompile/openssh-8.1p1/scp
Los hashes de los respectivos binarios deben coincidir entre sistemas.
También podemos comprobar la versión de los archivos nuevos frente a los antiguos:
ash-4.3# /bin/sshd.DS.orginal --version ; /bin/scp.DS.orginal --version
unknown option -- - OpenSSH_7.4p1, OpenSSL 1.0.2r-fips 26 Feb 2019 usage: sshd [-46DdeiqTt] [-C connection_spec] [-c
host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len] unknown
option -- - usage: scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i
identity_file]
[-l limit] [-o ssh_option] [-P port] [-S program]
[[user@]host1:]file1 ... [[user@]host2:]file2
ash-4.3# /bin/sshd --version ; /bin/scp --version
unknown option -- -
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len]
unknown option -- -
usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file]
[-J destination] [-l limit] [-o ssh_option] [-P port]
[-S program] source ... target
Ahora puede intentar conectarse normalmente a Synology nuevamente:
ssh DS
Ahora aparecerá algo como "ADVERTENCIA: ¡LA IDENTIFICACIÓN DEL HOST REMOTO HA CAMBIADO!"
Esto es lo que se espera. Rectifíquelo manualmente editando /home/user/.ssh/known_hosts, debería ser suficiente eliminar las claves antiguas y volver a conectarse, luego acepte la nueva clave.
Finalmente, para verificar si algo se modifica al reiniciar, opcionalmente reinicie el DS.
Para asegurarse de que las líneas personalizadas en /etc/passwd y /etc/group se mantengan, use el siguiente script, guárdelo en /usr/local/bin/pwdgroupfixer.sh, recuerde hacerlo ejecutable con chmod +x.
Haga una entrada en el crontab de raíces:
*/5 * * * * root /bin/sh /usr/local/bin/pwdgroupfixer.sh
Tenga en cuenta que Synology es particular en cuanto al formato de su crontab. Utilice tabulaciones en lugar de espacios; es un buen consejo utilizar una entrada existente, copiarla en una nueva línea y modificarla.
Finalmente reinicie el servicio crontab:
sudo synoservice -restart crond
#!/bin/sh
#pwdgroupfixer.sh
#Entries to support sshd
PASSWORDFILE=/etc/passwd
USERLINE="sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin"
GROUPFILE=/etc/group
GROUPLINE="/etc/group:sshd:*:27:"
itemcheck(){
FILE=$1
ITEM=$2
DATE=`/bin/date +%Y-%m-%d`
TEMPFILE=/tmp/$DATE
/bin/echo '0' > $TEMPFILE
FOUND=0
/bin/sed '/^[ \t\r\n]*$/d' $FILE | while read LINE; do
if [[ ${LINE:0:1} != "#" ]]; then
if [ "$LINE" == "$ITEM" ];
then
let FOUND++
/bin/echo $FOUND > $TEMPFILE
fi
fi
done
FOUND=`/bin/cat $TEMPFILE`
if [ "$FOUND" -eq "0" ]; then
/bin/cp $FILE $FILE.`/bin/date +%Y-%m-%d`
/bin/echo $ITEM >> $FILE
fi
}
itemcheck $PASSWORDFILE "$USERLINE"
itemcheck $GROUPFILE $GROUPLINE
#end pwdgroupfixer.sh
Respuesta3
Probé el siguiente enfoque, que no implica instalar software adicional ni otorgar privilegios elevados a usuarios que no deberían tenerlos. Sin embargo, todavía no he confirmado que esta solución realmente funcione; Sospecho que podría necesitar reiniciar el NAS por segunda vez al final del procedimiento. Actualizaré aquí a medida que sepa más. Si alguien lo intenta hasta el segundo reinicio, ¡deje un comentario!
Me di cuenta de que podía jugar el juego de Synology y reducir el grupo de usuarios "administradores" a solo un grupo que le otorga privilegios SSH.
Creé un segundo grupo y le di los mismos privilegios que el grupo predeterminado de "administradores". Digamos que llamas a este grupo "realadmin". Todos los usuarios que realmente se supone que tienen derechos de administrador deben agregarse a este grupo (solo para estar seguro, manténgalos también en los "administradores" originales). Después de crear este grupo y agregar todos los usuarios que deberían tener derechos de administrador, ingrese al NAS con una cuenta de administrador y sudo vi /etc/sudoers. Reemplace %administratorspor %realadmin(asegúrese de escribir esto correctamente, tal vez copie y pegue desde el panel de administración de DSM para mayor seguridad) y guarde y cierre escribiendo wq!. Reinicie el NAS para que este cambio surta efecto (perderá su acceso a sudo hasta que haya reiniciado el NAS). Finalmente, elimine todos los permisos del grupo "administradores", excepto aquellos que probablemente utilice con SSH, como rsync. Actualice la descripción para reflejar que "administradores" ahora es básicamente el grupo de usuarios SSH. Agregue todos los usuarios a los que desee otorgar acceso SSH; ahora no deberían obtener ningún derecho administrativo por ser "administradores". Asegúrese de volver a configurar el shell /bin/shpara cada uno de estos usuarios /etc/passwdy crear un .ssh/authorized_keysarchivo en sus directorios de inicio con las claves públicas con las que deberían poder autenticarse.
Seguí los pasos anteriores y luego intenté realizar SSH en el NAS con una cuenta de administrador no real que había agregado al grupo de "administradores". Aún así, lo tengo permission denied (publickey). No estoy seguro de qué falta en este momento. Tal vez necesite reiniciar el NAS nuevamente para que la adición del usuario a "administradores" surta efecto. También intenté brevemente agregar el mismo usuario a "realadmin", pero el usuario aún no podía usar SSH, al menos no sin reiniciar el NAS. No he reiniciado el NAS por segunda vez todavía, porque tengo procesos en ejecución que no quiero interrumpir con demasiada frecuencia y porque descubrí una solución diferente, rápida y sucia que resuelve mi problema particular por ahora.
Originalmente describí esta solución (teórica) en el foro de la comunidad de Synology, con alguna discusión adicional, en esta página:https://community.synology.com/enu/forum/1/post/125859?page=2(Respuesta número 16, la más reciente en el momento de escribir este artículo).
Respuesta4
De ninguna manera soy un experto en NAS, pero permitir el acceso del usuario a establece git_reposel shell activado /etc/passwd( para que encaje en la categoría). Cambiar eso para otorgar acceso SSH./var/packages/Git/target/bin/git-shellDSM 6.2.4-25556 Update 5DSM 6.2.x/bin/sh