> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/rdm/es/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md). # Prácticas recomendadas de seguridad de Open SSH Aunque Open SSH se ha convertido en la norma en lo que respecta al acceso remoto, utilizar su instalación predeterminada sigue implicando algunos riesgos de seguridad. Esta guía propone formas de aumentar considerablemente el nivel de seguridad de una instalación de Open SSH. ### Utilizar autenticación con claves privadas/públicas Utilizar claves cifradas para la autenticación resulta útil, ya que elimina la necesidad de introducir contraseñas. Ni los hackers más ingeniosos podrán interferir o colarse en una sesión, y no habrá más intentos de descifrar contraseñas. 1. Genere un par de claves pública/privada con este comando: `$ ssh-keygen -t rsa`. Esto crea dos ficheros en el directorio (oculto) `~/.ssh`; la clave privada se llama `id_rsa` y la pública `id_rsa.pub`. 2. Elija una contraseña que se utilizará para desbloquear la clave pública en cada conexión. Opcionalmente, se puede añadir un cifrado protegido con una frase de contraseña al crear la clave.

También funciona pulsar Enter sin introducir una frase de contraseña. Tenga en cuenta, sin embargo, que crear una clave sin frase de contraseña otorga automáticamente acceso SSH al servidor remoto a cualquiera que consiga acceso a su máquina local.

3. Copie la clave pública (`id_rsa.pub`) al servidor: ```` Scp –p id_rsa.pub remoteuser@remotehost: ```
The `remoteuser` should never be root. Select the default non-root user as `remoteuser` instead.
```` 4. Inicie sesión con SSH y copie la clave pública en el lugar adecuado: ``` ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout ``` 5. A continuación, elimine la clave pública del servidor; de lo contrario, el cliente SSH no permite iniciar sesión en el servidor: ``` rm id_rsa.pub ``` 6. Establezca los permisos de fichero en el servidor (estos dos son necesarios si "StrictModes" está configurado como ***yes***): ``` $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys ``` 7. Una vez que haya iniciado sesión utilizando la frase de contraseña de la clave, se puede desactivar por completo la autenticación con contraseña. Para ello, abra el fichero `/etc/ssh/sshd_config` y añada las siguientes líneas: ``` # Disable password authentication forcing use of keys PasswordAuthentication no ``` ### Desactivar la autenticación con nombre de usuario y contraseña Para eliminar por completo la autenticación basada en contraseñas y forzar el uso de claves o certificados SSH, actualice la configuración de SSH añadiendo las siguientes líneas en el fichero `/etc/ssh/sshd_config`: ``` PasswordAuthentication no ChallengeResponseAuthentication no KbdInteractiveAuthentication no UsePAM no ``` A continuación, reinicie el servicio SSHD introduciendo `/etc/init.d/sshd restart` o `service sshd restart`. Una vez hecho esto, el servidor debería rechazar todos los inicios de sesión con nombre de usuario/contraseña y aceptar únicamente la autenticación mediante clave o certificado. ### Configurar el intervalo de tiempo de inactividad Se puede establecer un intervalo de tiempo de inactividad para evitar tener una sesión SSH desatendida. Para ello, abra el fichero `/etc/ssh/sshd_config` y añada la siguiente línea: ``` ClientAliveInterval 360 ClientAliveCountMax 0 ``` El intervalo de tiempo de inactividad se expresa en segundos (360 segundos = 6 minutos). Una vez transcurrido el intervalo, los usuarios inactivos se desconectan automáticamente. ### Desactivar las contraseñas vacías Para mayor seguridad, se recomiendaimpedir los inicios de sesión remotos desde cuentas con contraseñas vacías. Abra el fichero `/etc/ssh/sshd_config` y actualice la siguiente línea: ``` PermitEmptyPasswords no ``` ### Limitar el acceso SSH a unos pocos usuarios En los casos en los que no se pueda evitar la autenticación con nombre de usuario/contraseña, se recomienda limitar el inicio de sesión SSH únicamente a determinados usuarios que necesiten acceso remoto, minimizando así el impacto de los usuarios con contraseñas débiles. Para limitar el inicio de sesión SSH, abra el fichero `/etc/ssh/sshd_config` y añada una línea `AllowUsers`, seguida de la lista de nombres de usuario separados por espacios: ``` AllowUsers user1 user2 ``` A continuación, reinicie el servicio SSHD introduciendo `/etc/init.d/sshd restart` o `service sshd restart`. ### Desactivar el inicio de sesión de root Para desactivar los inicios de sesión de root, abra el fichero `/etc/ssh/sshd_config` mientras esté conectado como root y cambie la línea `#PermitRootLogin` por `PermitRootLogin no`. Asegúrese de eliminar el símbolo #; de lo contrario, no funcionará. A continuación, reinicie el servicio SSHD introduciendo `/etc/init.d/sshd restart` o `service sshd restart`. ### Desactivar los cifrados débiles Abra el fichero `/etc/ssh/sshd_config` y añada estas líneas: ``` # Ciphers moderns Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com # KEX robusts KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384 # MAC moderns MACs hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com # Disable weak algorithms PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512 HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512 ``` A continuación, reinicie el servicio SSHD introduciendo `/etc/init.d/sshd restart` o `service sshd restart`. ### Utilizar un puerto no estándar La gran mayoría de los hackers que buscan servidores SSH abiertos buscarán el puerto 22, ya que, de forma predeterminada, SSH escucha las conexiones entrantes en ese puerto. Para ejecutar SSH en un puerto diferente, abra el fichero `/etc/ssh/sshd_config` y añada las siguientes líneas: ``` #Run SSH on a non standard port Port 2025 #Change me ``` A continuación, reinicie el servicio SSHD introduciendo `/etc/init.d/sshd restart` o `service sshd restart`. Asegúrese de cambiar el reenvío de puertos en su router y cualquier regla de firewall necesaria. Se recomienda informar a los clientes de cualquier cambio de puerto para que sepan a qué puerto conectarse, ya que SSH ya no escuchará conexiones en el puerto estándar. ### Limitar la exposición de SSH con controles de red Si no es viable cambiar el puerto SSH, implementar un servidor de salto proporciona un sólido punto de control Zero-Trust entre los clientes y los sistemas internos. Centraliza la autenticación, aplica políticas de acceso uniformes y evita la exposición directa de los activos críticos. Consulte [Remote Desktop Manager Jump (función)](https://docs.devolutions.net/resources/es/devolutions-agent/jump-host#configure-a-jump-host) para conocer los pasos de configuración. ### Habilitar la autenticación multifactor La autenticación multifactor es una de las principales protecciones que se deben añadir a los servidores SSH para protegerlos del acceso no autorizado, ya que cada inicio de sesión de usuario debe estar vinculado a un usuario MFA configurado. Incluso si un hacker consigue hacerse con una contraseña o penetrar en el servidor SSH, la MFA seguirá bloqueándolo. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/rdm/es/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.