Introducción
SSH es un protocolo seguro utilizado como el principal medio de conexión a servidores Linux de forma remota. Proporciona una interfaz basada en texto al generar un shell remoto. Después de conectarse, todos los comandos que escribe en su terminal local se envían al servidor remoto y se ejecutan allí.
En esta guía de estilo de hoja de trucos, cubriremos algunas formas comunes de conectarse con SSH para lograr sus objetivos. Esto se puede usar como una referencia rápida cuando necesite saber cómo conectarse o configurar su servidor de diferentes maneras.
Implementa tus aplicaciones frontend desde GitHub usando la Plataforma de Aplicaciones de DigitalOcean. Deja que DigitalOcean se enfoque en escalar tu aplicación.
Cómo Usar Esta Guía
- Lea primero la sección de Visión General de SSH si no está familiarizado con SSH en general o está comenzando.
- Utilice las secciones subsiguientes que sean aplicables a lo que está intentando lograr. La mayoría de las secciones no están condicionadas a ninguna otra, por lo que puede utilizar los siguientes ejemplos de manera independiente.
- Utilice el menú de Contenidos en el lado izquierdo de esta página (en anchos de página amplios) o la función de búsqueda de su navegador para localizar las secciones que necesite.
- Copie y pegue los ejemplos de línea de comandos dados, sustituyendo los valores
destacados
con sus propios valores.
Visión general de SSH
La forma más común de conectarse a un servidor Linux remoto es a través de SSH. SSH significa Secure Shell y proporciona una forma segura de ejecutar comandos, realizar cambios y configurar servicios de forma remota. Cuando se conecta a través de SSH, inicia sesión utilizando una cuenta que existe en el servidor remoto.
Cómo funciona SSH
Cuando se conecta a través de SSH, se le dejará en una sesión de shell, que es una interfaz basada en texto donde puede interactuar con su servidor. Durante la duración de su sesión de SSH, cualquier comando que escriba en su terminal local se envía a través de un túnel SSH cifrado y se ejecuta en su servidor.
La conexión SSH se implementa utilizando un modelo cliente-servidor. Esto significa que para que se establezca una conexión SSH, la máquina remota debe estar ejecutando un software llamado un demonio SSH. Este software escucha conexiones en un puerto de red específico, autentica las solicitudes de conexión y genera el entorno adecuado si el usuario proporciona las credenciales correctas.
La computadora del usuario debe tener un cliente SSH. Este es un software que sabe cómo comunicarse utilizando el protocolo SSH y puede recibir información sobre el host remoto al que conectarse, el nombre de usuario a utilizar y las credenciales que deben pasarse para autenticarse. El cliente también puede especificar ciertos detalles sobre el tipo de conexión que les gustaría establecer.
Cómo autentica SSH a los usuarios
Los clientes generalmente se autentican utilizando contraseñas (menos seguro y no recomendado) o claves SSH, que son muy seguras.
Los inicios de sesión con contraseña están encriptados y son fáciles de entender para los nuevos usuarios. Sin embargo, los bots automatizados y los usuarios malintencionados a menudo intentarán autenticarse repetidamente en cuentas que permitan inicios de sesión basados en contraseñas, lo que puede provocar compromisos de seguridad. Por esta razón, recomendamos siempre configurar la autenticación basada en claves SSH para la mayoría de las configuraciones.
Las claves SSH son un conjunto coincidente de claves criptográficas que se pueden utilizar para autenticación. Cada conjunto contiene una clave pública y una clave privada. La clave pública se puede compartir libremente sin preocupación, mientras que la clave privada debe ser guardada con vigilancia y nunca expuesta a nadie.
Para autenticarse usando claves SSH, un usuario debe tener un par de claves SSH en su computadora local. En el servidor remoto, la clave pública debe ser copiada a un archivo dentro del directorio de inicio del usuario en ~/.ssh/authorized_keys
. Este archivo contiene una lista de claves públicas, una por línea, que están autorizadas para iniciar sesión en esta cuenta.
Cuando un cliente se conecta al host, deseando utilizar la autenticación de clave SSH, informará al servidor de esta intención y le dirá al servidor qué clave pública usar. El servidor luego verifica su archivo authorized_keys
en busca de la clave pública, genera una cadena aleatoria y la cifra usando la clave pública. Este mensaje cifrado solo se puede descifrar con la clave privada asociada. El servidor enviará este mensaje cifrado al cliente para probar si realmente tienen la clave privada asociada.
Al recibir este mensaje, el cliente lo descifrará usando la clave privada y combinará la cadena aleatoria revelada con un ID de sesión previamente negociado. Luego genera un hash MD5 de este valor y lo transmite de vuelta al servidor. El servidor ya tenía el mensaje original y el ID de sesión, por lo que puede comparar un hash MD5 generado por esos valores y determinar que el cliente debe tener la clave privada.
Ahora que sabes cómo funciona SSH, podemos comenzar a discutir algunos ejemplos para demostrar diferentes formas de trabajar con SSH.
Generación y trabajo con claves SSH
Esta sección cubrirá cómo generar claves SSH en una máquina cliente y distribuir la clave pública a los servidores donde deben ser utilizadas. Esta es una buena sección para comenzar si previamente no ha generado claves debido a la mayor seguridad que permite para conexiones futuras.
Generación de un par de claves SSH
Generar un nuevo par de claves pública y privada SSH en tu computadora local es el primer paso para autenticarse con un servidor remoto sin contraseña. A menos que haya una buena razón para no hacerlo, siempre deberías autenticarte usando claves SSH.
A number of cryptographic algorithms can be used to generate SSH keys, including RSA, DSA, and ECDSA. RSA keys are generally preferred and are the default key type.
Para generar un par de claves RSA en tu computadora local, escribe:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
Este mensaje te permite elegir la ubicación para almacenar tu clave privada RSA. Presiona ENTER
para dejarlo en la ubicación predeterminada, que las almacenará en el directorio oculto .ssh
en el directorio de inicio de tu usuario. Dejar la ubicación predeterminada seleccionada permitirá que tu cliente SSH encuentre las claves automáticamente.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
El siguiente paso le permite ingresar una frase de contraseña de longitud arbitraria para proteger su clave privada. De forma predeterminada, deberá ingresar cualquier frase de contraseña que establezca aquí cada vez que use la clave privada, como medida de seguridad adicional. Si no desea una frase de contraseña, siéntase libre de presionar ENTER
para dejar esto en blanco. Sin embargo, tenga en cuenta que esto permitirá que cualquier persona que obtenga el control de su clave privada inicie sesión en sus servidores.
Si elige ingresar una frase de contraseña, no se mostrará nada mientras escribe. Esta es una precaución de seguridad.
OutputYour identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a root@here
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| + |
| o S . |
| o . * + |
| o + = O . |
| + = = + |
| ....Eo+ |
+-----------------+
Este procedimiento ha generado un par de claves SSH RSA, ubicado en el directorio oculto .ssh
dentro del directorio de inicio de su usuario. Estos archivos son:
~/.ssh/id_rsa
: La clave privada. ¡NO COMPARTA ESTE ARCHIVO!~/.ssh/id_rsa.pub
: La clave pública asociada. Esto se puede compartir libremente sin consecuencias.
Generar un Par de Claves SSH con un Mayor Número de Bits
Las claves SSH son de 2048 bits de forma predeterminada. Esto generalmente se considera suficiente para la seguridad, pero puede especificar un mayor número de bits para una clave más endurecida.
Para hacer esto, incluya el argumento -b
con el número de bits que desee. La mayoría de los servidores admiten claves con una longitud de al menos 4096 bits. Es posible que no se acepten claves más largas por razones de protección contra DDOS:
Si anteriormente has creado una clave diferente, se te preguntará si deseas sobrescribir tu clave anterior:
Overwrite (y/n)?
Si eliges “sí”, tu clave anterior será sobrescrita y ya no podrás iniciar sesión en los servidores utilizando esa clave. Debido a esto, asegúrate de sobrescribir las claves con precaución.
Eliminar o Cambiar la Frase de Contraseña en una Clave Privada
Si has generado una frase de contraseña para tu clave privada y deseas cambiarla o eliminarla, puedes hacerlo fácilmente.
Nota: Para cambiar o eliminar la frase de contraseña, debes conocer la frase de contraseña original. Si has perdido la frase de contraseña de la clave, no hay solución y tendrás que generar un nuevo par de claves.
Para cambiar o eliminar la frase de contraseña, simplemente escribe:
Enter file in which the key is (/root/.ssh/id_rsa):
Puedes escribir la ubicación de la clave que deseas modificar o presionar ENTER
para aceptar el valor predeterminado:
Enter old passphrase:
Ingresa la antigua frase de contraseña que deseas cambiar. Luego se te pedirá una nueva frase de contraseña:
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Aquí, ingresa tu nueva frase de contraseña o presiona ENTER
para eliminar la frase de contraseña.
Mostrando la Huella Digital de la Clave SSH
Cada par de claves SSH comparte una única “huella criptográfica” que se puede utilizar para identificarlas de manera única. Esto puede ser útil en una variedad de situaciones.
Para averiguar la huella digital de una clave SSH, escribe:
Enter file in which the key is (/root/.ssh/id_rsa):
Puedes presionar ENTER
si esa es la ubicación correcta de la clave, de lo contrario, introduce la ubicación revisada. Se te dará una cadena que contiene la longitud en bits de la clave, la huella digital, la cuenta y el host para los que fue creada, y el algoritmo utilizado:
Output4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e demo@test (RSA)
Copiando tu Clave Pública SSH a un Servidor con SSH-Copy-ID
Para copiar tu clave pública a un servidor, permitiéndote autenticarte sin una contraseña, se pueden tomar varias aproximaciones.
Si actualmente tienes configurado el acceso SSH basado en contraseña a tu servidor, y tienes instalada la utilidad ssh-copy-id
, este es un proceso sencillo. La herramienta ssh-copy-id
está incluida en muchos paquetes OpenSSH de distribuciones Linux, por lo que es muy probable que esté instalada por defecto.
Si tienes esta opción, puedes transferir fácilmente tu clave pública escribiendo:
Esto te pedirá la contraseña de la cuenta de usuario en el sistema remoto:
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Después de escribir la contraseña, el contenido de tu clave ~/.ssh/id_rsa.pub
se añadirá al final del archivo ~/.ssh/authorized_keys
de la cuenta de usuario:
OutputNumber of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
Ahora puedes iniciar sesión en esa cuenta sin contraseña:
Copiando tu clave SSH pública a un servidor sin SSH-Copy-ID
Si no tienes disponible la utilidad ssh-copy-id
, pero aún tienes acceso SSH basado en contraseña al servidor remoto, puedes copiar el contenido de tu clave pública de una manera diferente.
Puedes mostrar el contenido de la clave y enviarlo al comando ssh
. En el lado remoto, puedes asegurarte de que el directorio ~/.ssh
exista y luego agregar el contenido enviado al archivo ~/.ssh/authorized_keys
:
Se te pedirá que ingreses la contraseña de la cuenta remota:
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
[email protected]'s password:
Después de ingresar la contraseña, tu clave será copiada, lo que te permitirá iniciar sesión sin contraseña:
Copiando tu clave SSH pública a un servidor manualmente
Si no tienes disponible el acceso SSH basado en contraseña, tendrás que agregar tu clave pública al servidor remoto manualmente.
En tu máquina local, puedes encontrar el contenido de tu archivo de clave pública escribiendo:
Outputssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test
Puede copiar este valor y pegarlo manualmente en la ubicación correspondiente en el servidor remoto. Deberá iniciar sesión en el servidor remoto a través de otros medios (como la consola web de DigitalOcean).
En el servidor remoto, cree el directorio ~/.ssh
si aún no existe:
Luego, puede crear o agregar el archivo ~/.ssh/authorized_keys
escribiendo:
Ahora debería poder iniciar sesión en el servidor remoto sin contraseña.
Instrucciones Básicas de Conexión
La siguiente sección cubrirá algunos conceptos básicos sobre cómo conectarse a un servidor con SSH.
Conectándose a un Servidor Remoto
Para conectarse a un servidor remoto y abrir una sesión de shell allí, puede usar el comando ssh
.
La forma más sencilla asume que su nombre de usuario en su máquina local es el mismo que en el servidor remoto. Si esto es cierto, puede conectarse usando:
Si su nombre de usuario es diferente en el servidor remoto, debe pasar el nombre de usuario remoto de esta manera:
Su primera vez conectándose a un nuevo host, verá un mensaje que se ve así:
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
Escribe sí
para aceptar la autenticidad del host remoto.
Si estás utilizando autenticación por contraseña, se te pedirá la contraseña de la cuenta remota aquí. Si estás utilizando claves SSH, se te pedirá la frase de paso de tu clave privada si está configurada, de lo contrario iniciarás sesión automáticamente.
Ejecutar un Solo Comando en un Servidor Remoto
Para ejecutar un solo comando en un servidor remoto en lugar de iniciar una sesión de terminal, puedes agregar el comando después de la información de conexión, así:
Esto se conectará al host remoto, autenticará con tus credenciales y ejecutará el comando que especificaste. La conexión se cerrará inmediatamente después.
Iniciar Sesión en un Servidor con un Puerto Diferente
Por defecto, el demonio SSH en un servidor se ejecuta en el puerto 22
. Tu cliente SSH asumirá que este es el caso al intentar conectarse. Si tu servidor SSH está escuchando en un puerto no estándar (esto se demuestra en una sección posterior), deberás especificar el nuevo número de puerto al conectar con tu cliente.
Puedes hacerlo especificando el número de puerto con la opción -p
:
Para evitar tener que hacer esto cada vez que inicies sesión en tu servidor remoto, puedes crear o editar un archivo de configuración en el directorio ~/.ssh
dentro del directorio de inicio de tu computadora local.
Edita o crea el archivo ahora escribiendo:
En este archivo, puedes establecer opciones de configuración específicas del host. Para especificar tu nuevo puerto, usa un formato como este:
Host remote_alias
HostName remote_host
Port port_num
Esto te permitirá iniciar sesión sin especificar el número de puerto específico en la línea de comandos.
Agregando tus claves SSH a un Agente SSH para Evitar Escribir la Frase de Paso
Si tienes una frase de paso en tu clave SSH privada, se te pedirá que ingreses la frase de paso cada vez que la uses para conectarte a un host remoto.
Para evitar tener que hacer esto repetidamente, puedes ejecutar un agente SSH. Esta pequeña utilidad almacena tu clave privada después de haber ingresado la frase de paso por primera vez. Estará disponible durante la sesión de tu terminal, lo que te permitirá conectarte en el futuro sin volver a ingresar la frase de paso.
Esto también es importante si necesitas reenviar tus credenciales SSH (mostrado más adelante).
Para iniciar el Agente SSH, escribe lo siguiente en tu sesión de terminal local:
OutputAgent pid 10891
Esto iniciará el programa del agente y lo colocará en segundo plano. Ahora, necesitas agregar tu clave privada al agente, para que pueda gestionar tu clave:
Enter passphrase for /home/demo/.ssh/id_rsa:
Identity added: /home/demo/.ssh/id_rsa (/home/demo/.ssh/id_rsa)
Tendrás que ingresar tu frase de contraseña (si está configurada). Después, tu archivo de identidad se añade al agente, permitiéndote usar tu clave para iniciar sesión sin tener que volver a ingresar la frase de contraseña nuevamente.
Reenvío de tus Credenciales SSH para Usar en un Servidor
Si deseas poder conectarte sin contraseña a un servidor desde dentro de otro servidor, deberás reenviar la información de tu clave SSH. Esto te permitirá autenticarte en otro servidor a través del servidor al que estás conectado, usando las credenciales de tu ordenador local.
Para empezar, debes tener tu agente SSH iniciado y tu clave SSH añadida al agente (ver anteriormente). Después de hacer esto, necesitas conectarte a tu primer servidor usando la opción -A
. Esto reenvía tus credenciales al servidor para esta sesión:
A partir de aquí, puedes hacer SSH a cualquier otro host al que tu clave SSH esté autorizada para acceder. Te conectarás como si tu clave SSH privada estuviera ubicada en este servidor.
Opciones de Configuración en el Lado del Servidor
Esta sección contiene algunas opciones comunes de configuración del servidor que pueden influir en la forma en que responde su servidor y qué tipos de conexiones se permiten.
Deshabilitar la autenticación por contraseña
Si tiene configuradas, probadas y funcionando correctamente las claves SSH, probablemente sea una buena idea deshabilitar la autenticación por contraseña. Esto evitará que cualquier usuario inicie sesión con SSH utilizando una contraseña.
Para hacer esto, conéctese a su servidor remoto y abra el archivo /etc/ssh/sshd_config
con privilegios de root o sudo:
Dentro del archivo, busque la directiva PasswordAuthentication
. Si está comentada, descoméntela. Establézcala en no
para deshabilitar los inicios de sesión con contraseña:
PasswordAuthentication no
Después de realizar el cambio, guarde y cierre el archivo. Para implementar los cambios, debería reiniciar el servicio SSH.
En Ubuntu/Debian:
En CentOS/Fedora:
Ahora, todas las cuentas en el sistema no podrán iniciar sesión con SSH utilizando contraseñas.
Cambiando el puerto en el que se ejecuta el demonio SSH
Algunos administradores sugieren cambiar el puerto predeterminado en el que se ejecuta SSH. Esto puede ayudar a disminuir el número de intentos de autenticación a los que está expuesto su servidor por parte de bots automatizados.
Para cambiar el puerto en el que el demonio SSH escucha, deberás iniciar sesión en tu servidor remoto. Abre el archivo sshd_config
en el sistema remoto con privilegios de root, ya sea iniciando sesión con ese usuario o utilizando sudo
:
Una vez dentro, puedes cambiar el puerto en el que se ejecuta SSH buscando la especificación Port 22
y modificándola para reflejar el puerto que deseas utilizar. Por ejemplo, para cambiar el puerto a 4444
, coloca esto en tu archivo:
#Port 22
Port 4444
Guarda y cierra el archivo cuando hayas terminado. Para implementar los cambios, debes reiniciar el demonio SSH.
En Ubuntu/Debian:
En CentOS/Fedora:
Después de que el demonio se reinicie, deberás autenticarte especificando el número de puerto (demostrado en una sección anterior).
Limitar los usuarios que pueden conectarse a través de SSH
Para limitar explícitamente las cuentas de usuario que pueden iniciar sesión a través de SSH, puedes tomar algunos enfoques diferentes, cada uno de los cuales implica editar el archivo de configuración del demonio SSH.
En tu servidor remoto, abre este archivo ahora con privilegios de root o sudo:
El primer método para especificar las cuentas que tienen permitido iniciar sesión es mediante el uso de la directiva AllowUsers
. Busca la directiva AllowUsers
en el archivo. Si no existe, créala en cualquier lugar. Después de la directiva, lista las cuentas de usuario que deberían tener permitido iniciar sesión a través de SSH:
AllowUsers user1 user2
Guarda y cierra el archivo. Reinicia el demonio para implementar los cambios.
En Ubuntu/Debian:
En CentOS/Fedora:
Si te sientes más cómodo con la gestión de grupos, puedes usar la directiva AllowGroups
en su lugar. Si este es el caso, simplemente agrega un único grupo al que se le debe permitir el acceso SSH (crearemos este grupo y agregaremos miembros en breve):
AllowGroups sshmembers
Guarda y cierra el archivo.
Ahora, puedes crear un grupo de sistema (sin directorio de inicio) que coincida con el grupo que especificaste escribiendo:
Asegúrate de agregar las cuentas de usuario que necesitas a este grupo. Esto se puede hacer escribiendo:
A continuación, reinicia el demonio SSH para implementar los cambios.
En Ubuntu/Debian:
En CentOS/Fedora:
Desactivación del Inicio de Sesión de Root
A menudo es recomendable desactivar por completo el inicio de sesión de root a través de SSH después de haber configurado una cuenta de usuario SSH que tenga privilegios de sudo
.
Para hacer esto, abre el archivo de configuración del demonio SSH con permisos de root o sudo en tu servidor remoto.
Dentro, busca una directiva llamada PermitRootLogin
. Si está comentada, descoméntala. Cambia el valor a “no”:
PermitRootLogin no
Guarda y cierra el archivo. Para implementar los cambios, reinicia el demonio SSH.
En Ubuntu/Debian:
En CentOS/Fedora:
Permitir acceso root para comandos específicos
Hay casos en los que puedes querer deshabilitar el acceso root en general, pero habilitarlo para permitir que ciertas aplicaciones se ejecuten correctamente. Un ejemplo de esto podría ser una rutina de respaldo.
Esto se puede lograr a través del archivo authorized_keys
del usuario root, que contiene claves SSH autorizadas para usar la cuenta.
Agrega la clave de tu computadora local que deseas usar para este proceso (recomendamos crear una nueva clave para cada proceso automático) al archivo authorized_keys
del usuario root en el servidor. Demostraremos con el comando ssh-copy-id
aquí, pero puedes usar cualquiera de los métodos de copia de claves que discutimos en otras secciones:
Ahora, inicia sesión en el servidor remoto. Necesitaremos ajustar la entrada en el archivo authorized_keys
, así que ábrelo con acceso de root o sudo:
Al principio de la línea con la clave que cargaste, agrega un command=
que defina el comando para el cual esta clave es válida. Esto debería incluir la ruta completa al ejecutable, además de cualquier argumento:
command="/path/to/command arg1 arg2" ssh-rsa ...
Guarda y cierra el archivo cuando hayas terminado.
Ahora, abre el archivo sshd_config
con privilegios de root o sudo:
Encuentra la directiva PermitRootLogin
y cambia el valor a forced-commands-only
. Esto permitirá que los inicios de sesión con clave SSH utilicen root solo cuando se haya especificado un comando para la clave:
PermitRootLogin forced-commands-only
Guarda y cierra el archivo. Reinicia el demonio SSH para implementar tus cambios.
En Ubuntu/Debian:
En CentOS/Fedora:
Reenvío de Visualizaciones de Aplicaciones X al Cliente
El demonio SSH se puede configurar para reenviar automáticamente la visualización de aplicaciones X en el servidor a la máquina cliente. Para que esto funcione correctamente, el cliente debe tener un sistema de ventanas X configurado y habilitado.
Para habilitar esta funcionalidad, inicia sesión en tu servidor remoto y edita el archivo sshd_config
como root o con privilegios de sudo:
Busca la directiva X11Forwarding
. Si está comentada, descoméntala. Créala si es necesario y establece el valor en “yes”:
X11Forwarding yes
Guardar y cerrar el archivo. Reinicie su daemon SSH para implementar estos cambios.
En Ubuntu/Debian:
En CentOS/Fedora:
Para conectarse al servidor y reenviar la pantalla de una aplicación, debe pasar la opción -X
desde el cliente al realizar la conexión:
Las aplicaciones gráficas iniciadas en el servidor a través de esta sesión deberían mostrarse en la computadora local. El rendimiento podría ser un poco lento, pero es muy útil en caso de necesidad.
Opciones de configuración del lado del cliente
En la siguiente sección, nos enfocaremos en algunos ajustes que puede realizar en el lado del cliente de la conexión.
Definición de información de conexión específica del servidor
En su computadora local, puede definir configuraciones individuales para algunos o todos los servidores a los que se conecta. Estas pueden almacenarse en el archivo ~/.ssh/config
, que es leído por su cliente SSH cada vez que se llama.
Cree o abra este archivo en su editor de texto en su computadora local:
Dentro, puedes definir opciones de configuración individuales introduciendo cada una con una palabra clave Host
, seguida de un alias. Debajo de esto e indentado, puedes definir cualquiera de las directivas encontradas en la página del manual de ssh_config
:
Un ejemplo de configuración sería:
Host testhost
HostName your_domain
Port 4444
User demo
Luego podrías conectarte a tu_dominio
en el puerto 4444
usando el nombre de usuario demo
simplemente escribiendo:
También puedes usar comodines para hacer coincidir más de un host. Ten en cuenta que las coincidencias posteriores pueden anular las anteriores. Por esta razón, deberías poner tus coincidencias más generales en la parte superior. Por ejemplo, podrías establecer todas las conexiones por defecto para no permitir el reenvío de X, con una anulación para tu_dominio
teniendo esto en tu archivo:
Host *
ForwardX11 no
Host testhost
HostName your_domain
ForwardX11 yes
Port 4444
User demo
Guarda y cierra el archivo cuando hayas terminado.
Mantener Conexiones Activas para Evitar Desconexiones por Tiempo Fuera
Si te encuentras siendo desconectado de las sesiones de SSH antes de que estés listo, es posible que tu conexión se esté cerrando por tiempo de espera.
Puedes configurar tu cliente para enviar un paquete al servidor de vez en cuando para evitar esta situación:
En tu computadora local, puedes configurar esto para cada conexión editando tu archivo ~/.ssh/config
. Ábrelo ahora:
Si no existe aún, en la parte superior del archivo, define una sección que coincida con todos los hosts. Establece ServerAliveInterval
en “120” para enviar un paquete al servidor cada dos minutos. Esto debería ser suficiente para notificar al servidor que no cierre la conexión:
Host *
ServerAliveInterval 120
Guarda y cierra el archivo cuando hayas terminado.
Deshabilitar la verificación del host
De forma predeterminada, cada vez que te conectas a un nuevo servidor, se te mostrará la huella digital de la clave del host del demonio SSH remoto.
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
Esto está configurado para que puedas verificar la autenticidad del host al que intentas conectarte y detectar casos en los que un usuario malintencionado pueda intentar hacerse pasar por el host remoto.
En ciertas circunstancias, es posible que desees deshabilitar esta función. Nota: Esto puede ser un gran riesgo de seguridad, así que asegúrate de saber lo que estás haciendo si configuras tu sistema de esta manera.
Para realizar el cambio, abre el archivo ~/.ssh/config
en tu ordenador local:
Si no existe aún, en la parte superior del archivo, define una sección que coincida con todos los hosts. Establece la directiva StrictHostKeyChecking
en no
para agregar automáticamente nuevos hosts al archivo known_hosts
. Establece UserKnownHostsFile
en /dev/null
para no advertir sobre hosts nuevos o modificados:
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Puede habilitar la verificación caso por caso revirtiendo esas opciones para otros hosts. El valor predeterminado para StrictHostKeyChecking
es ask
:
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Host testhost
HostName your_domain
StrictHostKeyChecking ask
UserKnownHostsFile /home/demo/.ssh/known_hosts
Multiplexación de SSH sobre una única conexión TCP
Existen situaciones en las que establecer una nueva conexión TCP puede llevar más tiempo del deseado. Si está realizando múltiples conexiones al mismo equipo, puede aprovechar la multiplexación.
La multiplexación de SSH reutiliza la misma conexión TCP para múltiples sesiones de SSH. Esto elimina parte del trabajo necesario para establecer una nueva sesión, lo que posiblemente acelere las cosas. Limitar el número de conexiones también puede ser útil por otras razones.
Para configurar la multiplexación, puede configurar manualmente las conexiones o puede configurar su cliente para usar automáticamente la multiplexación cuando esté disponible. Aquí demostraremos la segunda opción.
Para configurar la multiplexación, edite el archivo de configuración del cliente SSH en su máquina local:
Si aún no tiene una definición de host comodín en la parte superior del archivo, agregue una ahora (como Host *
). Estableceremos los valores ControlMaster
, ControlPath
y ControlPersist
para establecer nuestra configuración de multiplexación.
El ControlMaster
debe establecerse en “auto” para permitir automáticamente la multiplexación si es posible. El ControlPath
establecerá la ruta al socket de control. La primera sesión creará este socket y las sesiones subsiguientes podrán encontrarlo porque está etiquetado por nombre de usuario, host y puerto.
Establecer la opción ControlPersist
en 1
permitirá que la conexión maestra inicial se ejecute en segundo plano. El 1
especifica que la conexión TCP debería terminarse automáticamente un segundo después de que se cierre la última sesión SSH:
Host *
ControlMaster auto
ControlPath ~/.ssh/multiplex/%r@%h:%p
ControlPersist 1
Guarde y cierre el archivo cuando haya terminado. Ahora, necesitamos crear realmente el directorio que especificamos en la ruta de control:
Ahora, cualquier sesión que se establezca con la misma máquina intentará usar el socket existente y la conexión TCP. Cuando la última sesión se cierre, la conexión se cerrará después de un segundo.
Si por alguna razón necesitas omitir temporalmente la configuración de multiplexación, puedes hacerlo pasando la bandera -S
con none
:
Configuración de túneles SSH
Tunelizar otro tráfico a través de un túnel SSH seguro es una excelente manera de sortear las configuraciones restrictivas de firewall. También es una excelente manera de cifrar el tráfico de red que de otro modo no estaría cifrado.
Configurando el Túnel Local hacia un Servidor
Las conexiones SSH pueden utilizarse para tunelizar el tráfico desde puertos en el host local hacia puertos en un host remoto.
A local connection is a way of accessing a network location from your local computer through your remote host. First, an SSH connection is established to your remote host. On the remote server, a connection is made to an external (or internal) network address provided by the user and traffic to this location is tunneled to your local computer on a specified port.
Esto se usa a menudo para tunelizar hacia un entorno de red menos restringido al eludir un firewall. Otro uso común es acceder a una interfaz web “solo localhost” desde una ubicación remota.
Para establecer un túnel local hacia tu servidor remoto, necesitas usar el parámetro -L
al conectarte y debes proporcionar tres piezas de información adicional:
- El puerto local donde deseas acceder a la conexión tunelizada.
- El host al que deseas que se conecte tu host remoto.
- El puerto al que deseas que se conecte tu host remoto.
Estos se proporcionan, en el orden mencionado (separados por dos puntos), como argumentos a la bandera -L
. También usaremos la bandera -f
, que hace que SSH se ejecute en segundo plano antes de ejecutar y la bandera -N
, que no abre una shell ni ejecuta un programa en el lado remoto.
Por ejemplo, para conectarte a tu_dominio
en el puerto 80 en tu host remoto, haciendo que la conexión esté disponible en tu máquina local en el puerto 8888, podrías escribir:
Ahora, si apuntas tu navegador web local a 127.0.0.1:8888
, deberías ver cualquier contenido que esté en tu_dominio
en el puerto 80
.
A more general guide to the syntax is:
Dado que la conexión se realiza en segundo plano, deberás encontrar su PID para terminarla. Puedes hacerlo buscando el puerto que has reenviado:
Output1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -L 8888:your_domain:80 username@remote_host
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
Luego puedes finalizar el proceso apuntando al PID, que es el número en la segunda columna de la línea que coincide con tu comando SSH:
Otra opción es iniciar la conexión sin la bandera -f
. Esto mantendrá la conexión en primer plano, impidiéndote usar la ventana del terminal durante el reenvío. La ventaja de esto es que puedes terminar fácilmente el túnel escribiendo CTRL-C
.
Configuración del reenvío remoto a un servidor
Las conexiones SSH pueden utilizarse para enviar el tráfico desde puertos en el host local a puertos en un host remoto.
En un túnel remoto, se establece una conexión con un host remoto. Durante la creación del túnel, se especifica un puerto remoto. Este puerto, en el host remoto, luego será enviado a una combinación de host y puerto que se conecta desde la computadora local. Esto permitirá que la computadora remota acceda a un host a través de tu computadora local.
Esto puede ser útil si necesitas permitir el acceso a una red interna que está bloqueada para conexiones externas. Si el firewall permite conexiones hacia fuera de la red, esto te permitirá conectarte a una máquina remota y enviar el tráfico desde esa máquina a una ubicación en la red interna.
Para establecer un túnel remoto hacia tu servidor remoto, necesitas usar el parámetro -R
al conectar y debes proporcionar tres piezas de información adicional:
- El puerto donde el host remoto puede acceder a la conexión tunelizada.
- El host al que deseas que se conecte tu computadora local.
- El puerto al que deseas que se conecte tu computadora local.
Estos se dan, en el orden mencionado (separados por dos puntos), como argumentos para la bandera -R
. También usaremos la bandera -f
, que hace que SSH se ejecute en segundo plano antes de ejecutar y la bandera -N
, que no abre una shell ni ejecuta un programa en el lado remoto.
Por ejemplo, para conectarse a tu_dominio
en el puerto 80 en nuestra computadora local, haciendo que la conexión esté disponible en nuestro host remoto en el puerto 8888
, podrías escribir:
Ahora, en el host remoto, abrir un navegador web a 127.0.0.1:8888
te permitiría ver cualquier contenido que esté en tu_dominio
en el puerto 80
.
A more general guide to the syntax is:
Dado que la conexión está en segundo plano, deberás encontrar su PID para terminarla. Puedes hacerlo buscando el puerto que reenviaste:
Output1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -R 8888:your_domain:80 username@remote_host
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
Luego puedes detener el proceso apuntando al PID, que es el número en la segunda columna, de la línea que coincide con tu comando SSH:
Otra opción es iniciar la conexión sin la bandera -f
. Esto mantendrá la conexión en primer plano, impidiendo que utilices la ventana del terminal durante el tiempo que dure el reenvío. El beneficio de esto es que puedes terminar fácilmente el túnel escribiendo CTRL-C
.
Configuración de túneles dinámicos hacia un servidor remoto
Las conexiones SSH pueden usarse para enviar el tráfico desde puertos en el host local a puertos en un host remoto.
A dynamic tunnel is similar to a local tunnel in that it allows the local computer to connect to other resources through a remote host. A dynamic tunnel does this by simply specifying a single local port. Applications that wish to take advantage of this port for tunneling must be able to communicate using the SOCKS protocol so that the packets can be correctly redirected at the other side of the tunnel.
El tráfico que se envía a este puerto local será enviado al host remoto. Desde allí, el protocolo SOCKS será interpretado para establecer una conexión con la ubicación final deseada. Esta configuración permite que una aplicación compatible con SOCKS se conecte a cualquier número de ubicaciones a través del servidor remoto, sin múltiples túneles estáticos.
Para establecer la conexión, pasaremos la bandera -D
junto con el puerto local donde deseamos acceder al túnel. También usaremos la bandera -f
, que hace que SSH pase al segundo plano antes de ejecutarse, y la bandera -N
, que no abre una shell ni ejecuta un programa en el lado remoto.
Por ejemplo, para establecer un túnel en el puerto 7777
, puedes escribir:
A partir de aquí, puedes comenzar a dirigir tu aplicación compatible con SOCKS (como un navegador web) al puerto que seleccionaste. La aplicación enviará su información a un socket asociado con el puerto.
El método para dirigir el tráfico al puerto SOCKS variará según la aplicación. Por ejemplo, en Firefox, la ubicación general es Preferencias > Avanzado > Configuración > Configuraciones de proxy manuales. En Chrome, puedes iniciar la aplicación con la bandera --proxy-server=
establecida. Querrás usar la interfaz de localhost y el puerto que hayas reenviado.
Dado que la conexión está en segundo plano, tendrás que encontrar su PID para finalizarla. Puedes hacerlo buscando el puerto que reenviaste:
Output1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -D 7777 username@remote_host
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
Luego puedes finalizar el proceso apuntando al PID, que es el número en la segunda columna, de la línea que coincida con tu comando SSH:
Otra opción es iniciar la conexión sin la bandera -f
. Esto mantendrá la conexión en primer plano, evitando que uses la ventana del terminal durante el reenvío. La ventaja de esto es que puedes finalizar fácilmente el túnel escribiendo CTRL-C
.
Usando Códigos de Escape de SSH para Controlar Conexiones
Incluso después de establecer una sesión SSH, es posible ejercer control sobre la conexión desde dentro del terminal. Podemos hacer esto con algo llamado códigos de escape de SSH, que nos permiten interactuar con nuestro software SSH local desde dentro de una sesión.
Forzar una desconexión desde el lado del cliente (Cómo salir de una sesión atascada o congelada)
Una de las características más útiles de OpenSSH que pasa desapercibida en gran medida es la capacidad de controlar ciertos aspectos de la sesión desde dentro.
Estos comandos pueden ejecutarse comenzando con el carácter de control ~
dentro de una sesión SSH. Los comandos de control solo serán interpretados si son lo primero que se escribe después de un salto de línea, así que siempre presiona ENTER una o dos veces antes de usar uno.
Uno de los controles más útiles es la capacidad de iniciar una desconexión desde el cliente. Las conexiones SSH suelen cerrarse por el servidor, pero esto puede ser un problema si el servidor está experimentando problemas o si la conexión se ha interrumpido. Al usar una desconexión del lado del cliente, la conexión puede cerrarse limpiamente desde el cliente.
Para cerrar una conexión desde el cliente, utiliza el carácter de control (~
), seguido de un punto. Si tu conexión está teniendo problemas, es probable que estés en lo que parece ser una sesión de terminal atascada. Escribe los comandos a pesar de la falta de retroalimentación para realizar una desconexión del lado del cliente:
La conexión debería cerrarse inmediatamente, devolviéndote a tu sesión de shell local.
Colocando una Sesión SSH en Segundo Plano
Una de las características más útiles de OpenSSH que pasa desapercibida en gran medida es la capacidad de controlar ciertos aspectos de la sesión desde dentro de la conexión.
Estos comandos pueden ejecutarse comenzando con el carácter de control ~
desde dentro de una conexión SSH. Los comandos de control solo se interpretarán si son lo primero que se escribe después de un salto de línea, así que siempre presiona ENTER
una o dos veces antes de usar uno.
Una capacidad que esto proporciona es poner una sesión SSH en segundo plano. Para hacer esto, necesitamos suministrar el carácter de control (~
) y luego ejecutar el atajo de teclado convencional para enviar una tarea al segundo plano (CTRL-z):
Esto colocará la conexión en segundo plano, devolviéndote a tu sesión de shell local. Para volver a tu sesión SSH, puedes usar los mecanismos de control de trabajos convencionales.
Puedes reactivar inmediatamente tu tarea más reciente en segundo plano escribiendo:
Si tienes múltiples tareas en segundo plano, puedes ver los trabajos disponibles escribiendo:
Output[1]+ Stopped ssh username@some_host
[2] Stopped ssh username@another_host
Luego, puedes llevar cualquiera de las tareas al primer plano usando el índice en la primera columna con un signo de porcentaje:
Cambiando las opciones de reenvío de puertos en una conexión SSH existente
Una de las características más útiles de OpenSSH que pasa desapercibida en gran medida es la capacidad de controlar ciertos aspectos de la sesión desde dentro de la conexión.
Estos comandos se pueden ejecutar comenzando con el carácter de control ~
desde dentro de una conexión SSH. Los comandos de control solo serán interpretados si son lo primero que se escribe después de una nueva línea, así que siempre presione ENTER una o dos veces antes de usar uno.
Una cosa que esto permite es que un usuario altere la configuración de reenvío de puertos después de que la conexión ya haya sido establecida. Esto le permite crear o desmantelar reglas de reenvío de puertos sobre la marcha.
Estas capacidades forman parte de la interfaz de línea de comandos SSH, a la que se puede acceder durante una sesión usando el carácter de control (~
) y “C”:
ssh>
Se te dará un prompt de comando SSH, que tiene un conjunto muy limitado de comandos válidos. Para ver las opciones disponibles, puedes escribir -h
desde este prompt. Si no se devuelve nada, es posible que tengas que aumentar la verbosidad de tu salida SSH usando ~v
algunas veces:
Commands:
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-D[bind_address:]port Request dynamic forward
-KL[bind_address:]port Cancel local forward
-KR[bind_address:]port Cancel remote forward
-KD[bind_address:]port Cancel dynamic forward
Como puedes ver, puedes implementar fácilmente cualquiera de las opciones de reenvío utilizando las opciones apropiadas (consulta la sección de reenvío para obtener más información). También puedes destruir un túnel con el comando asociado “kill” especificado con una “K” antes de la letra del tipo de reenvío. Por ejemplo, para matar un reenvío local (-L
), podrías usar el comando -KL
. Solo necesitarás proporcionar el puerto para esto.
Entonces, para configurar un reenvío de puerto local, puedes escribir:
El puerto 8888
en tu ordenador local podrá comunicarse con el servidor web en el host al que te estás conectando. Cuando hayas terminado, puedes deshacer ese reenvío escribiendo:
Conclusión
Las instrucciones anteriores deberían cubrir la mayoría de la información que la mayoría de los usuarios necesitarán sobre SSH en su día a día. Si tienes otros consejos o deseas compartir tus configuraciones y métodos favoritos, siéntete libre de utilizar los comentarios a continuación.