SSH
Última actualización
Última actualización
Desde un inicio se crearon protocolos de remoto como TELNET, RLOGIN o RSH (Shell remota). Estos protocolos muy usados desde los años 70 permitían la ejecución remota de instrucciones sin embargo su conexión ni autenticación no estaba cifrada.
A raiz de esta necesidad se desarrolló ssh y se creó OPENSSH, desarrollado por OpenBSD, escrito en C y con licencia BSD simple, de dominio público. Sobre todo usada en BSD, GNU/Linux y UNIX, se apoya en el proyecto LibreSSL (Fork de OpenSSL tras heartbleed).
Esta herramienta añade algunos componentes interesantes como ssh, scp, sftp, ssh-keygen, ssh-agent, sshd y ssh-keyscan.
Para la autenticación, ssh puede usar cuatro métodos:
Por contraseña, usamos la contraseña del usuario en el sistema remoto
Por clave pública, el usuario genera un par de claves pública/privada, ubica la clave pública en el equipo remoto y accede a su sesión sin contraseña
Por Kerberos, principalmente para entornos corporativos ya que requiere de un servidor kerberos. Este solicita un ticket al servidor kerberos y este le proporciona SSO.
Por GSSAPI, una biblioteca programable para su uso con otros lenguajes o métodos.
El protocolo consta de dos fase: negociación y autenticación.
Ahor sí, vamos a ver como usar SSH!
Primeramente instalaremos Openssh
Por defecto nos creará varias claves. Para verificar que esta en funcionamiento:
El fichero de configuración de este servicio se encuentra habitualmente en /etc/ssh/sshd_config y contiene las opciones de configuración.
Se puede restringir el acceso con el usuario root utilizando contraseña, aspecto importante desde el punto de vista de seguridad, por lo que hoy en día habitualmente se utiliza la opcion:
En caso de que quisiéramos permitir acceder con el usuario root y contraseña, deberíamos poner esta opción a “yes”.
No específicas del acceso con usuario y contraseña, pero adecuadas para empezar:
Para la conexión de ssh, lo más sencillo es usar
La primera vez que nos conectemos, aparecerá la huella de SHA de la clave ECDSA pública del servidor. Esto es lo que se ha generado de la clave pública para comprobar con el servidor y poder confiar.
Una vez puesta la contraseña ya podemos acceder. Cabe mencionar que la clave pública la podemos encontrar en el sistema dentro de /etc/ssh/ssh_host_ecdsa_key.pub
Si yo dispusiera de la clave del servidor en mi máquina cliente, podria verificar su clave pública con:
De esta forma nos mostrará la clave de arriba previa a la conexión.
Hasta ahora no lo he mencionado específicamente pero SSH utiliza por defecto el puerto 22 como puedes ver en la imagen de arriba, un puerto que está siempre abierto en los firewalls y los routers, aunque podemos cambiarlo por el puerto que nosotros queramos usar. Si queremos conectar con otro puerto (por ejemplo el 27) podemos forzarlo por comandos:
Si deseas aumentar la seguridad cambiando el puerto predeterminado (22) del servicio SSH, realiza los siguientes pasos.
Abre el archivo de configuración SSH:
Encuentra la línea que especifica el puerto (por defecto, es Port 22), y cámbiala al puerto deseado (por ejemplo, Port 2222).
Guarda el archivo y reinicia el servicio SSH:
Primero generaremos las claves con:
En este caso vamos a generar una clave RSA de 4096 bits con SHA-2 (podríamos haber usado también una ED25519 pero para esto ya nos sirve).
De momento pasemos de la frase de paso. Verás que te ha generado una clave pública (.pub) y una privada (id_rsa_sha2) en la carpeta ~/.ssh
A continuación ejecutaremos el siguiente comando que lo que hará será crear el directorio .ssh si no existe (El -p asegura que no se genere un error si el directorio ya existe), agregar el contenido de la clave pública (id_rsa.pub) al archivo authorized_keys dentro del directorio .ssh y establece los permisos del archivo authorized_keys para que solo el propietario pueda leer y escribir en él:
Con todo esto ya mostrará la información de las claves generadas como la ubicación (la privada id_rsa_sha2 y la pública id_rsa_sha2.pub que se encuentran en .ssh/) , el fingerprint, y una imagen:
Ahora, si veo la clave privada (cat id_rsa_sha2) o la copio de mi sistema remoto (por scp o curl/wgetpor ejemplo) ya podré acceder por ssh en remoto.
Sino también puedo usar el propio ssh para copiar la clave a una ruta remota que es la IP, pero esto solo te funcionara en un sistema que tenga instalada esta utilidad:
Una vez hecho esto ya se puede acceder sin que te pida contraseña:
En cualquier momento, puedo revisar que claves están autenticadas dentro del fichero .ssh/authorized_keys, desde aquí puedo borrar anteriores.
Aunque habitualmente se generan ambas claves, en diferentes circunstancias puede ocurrir que tengamos la clave privada, pero no la correspondiente clave pública, en ese caso podemos utilizar ssh-keygen para obtenerla:
Evidentemente si tenemos la clave pública y no la privada, no podemos hacer el proceso inverso.
La autenticación con clave privada tiene importantes ventajas respecto al acceso con contraseña, pero tiene el inconveniente de la custodia de la clave privada.
Cualquier usuario que obtuviese nuestra clave privada podría entrar en nuestra cuenta de cualquier equipo en el que tuviésemos exportada la correspondiente clave pública. Para aumentar la seguridad en esta situación se utiliza una frase de paso para proteger la clave privada, frase que se introduce al crear la clave privada o que puede modificarse a posteriori.
Vamos a crear una nueva clave, pero en este caso protegida con frase de paso. Los pasos son los mismos pero en el momento de la frase de paso debemos excribir :
Procedemos de igual forma que en el caso anterior, exportando la clave pública, aunque ahora cada vez que accedamos nos solicitará la frase de paso de la clave privada:
Hemos ganado en seguridad, pero hemos perdido en usabilidad, porque ahora tenemos que escribir la frase de paso cada vez que accedamos al equipo remoto y además no es válido para procesos no interactivos. Para solucionar este inconveniente usaremos ssh-agent en una sección posterior.
ssh-agent es un manejador de claves para SSH, es decir, mantiene las claves privadas en memoria, descifradas y listas para usarse. Esto nos facilita el hecho de utilizar dichas claves sin necesidad de cargarlas y descifrarlas (en el caso de que hayamos seteado una passphrase) cada vez que vayamos a usarlas.
ssh-agent corre como un servicio en segundo plano de manera independiente al servicio principal de SSH. Además, mantiene las claves seguras evitando escribir información privada en el disco, y prohibiendo que cualquier aplicación del sistema pueda exportar las claves privadas sin el consentimiento del usuario.
En cualquier maquina linux te arranca al inicio el ssh-agent, para ello revisamos:
El resultado es el siguiente:
En el caso de que utilicemos un sistema que no haya cargado automáticamente un agente ssh, podemos ejecutarlo directamente, habitualmente se haría abriendo una nueva shell:
En el momento en que yo cree una sesión de paso (requerida) lo veré, ahora deberé vincularlo:
Si la clave está protegida por una frase de paso, se nos pedirá en ese momento, o se utilizará la aplicación ssh-askpass si se tratase de una aplicación gráfica u otra que no tuviese asociada una terminal.
Podemos ver las claves cargadas mediante:
Y sus huellas con:
ssh-agent permite que cualquier otra aplicación de la misma sesión utilice las claves privadas que almacena sin tener que volver a autenticarse, por lo que es importante controlar el uso de la sesión, bloqueándola cuando no se esté usando.
Se pueden eliminar claves ssh del agente mediante:
O incluso eliminar todas las claves con:
El forwarding es una propiedad del ssh-agent que sirve para acceder a una tercera maquina a través de una segunda. Esto no viene modificado por defecto así que debo editar el fichero de etc/ssh/ssh_config y modifico la siguiente propiedad.
Si adicionalmente quisiéramos ejecutar aplicaciones gráficas en el servidor, deberíamos descomentar y editar la siguiente propiedad en el servidor:
El cliente para conectarse y utilizar esta funcionalidad, deberá configurar adicionalmente la opción:
Al conectarnos por ssh podremos comprobar que está definida la variable DISPLAY con un valor definido a través de la variable X11DisplayOffset, por ejemplo:
Al ejecutar una aplicación en el equipo remoto sobre la conexión ssh nos aparecerá en nuestra pantalla. Por ejemplo mozilla o xeyes.
SSH permite entre otras cosas la transferencia de archivos.
Ten en cuenta que para el siguiente ejemplo nos estamos traspasando un fichero desde el servidor al anfitrión
Si quisiera hacerlo al revés, del anfitrión a la máquina:
Esto también se puede hacer de forma recursiva añadiendo un -r de parámetro tal y como se ve en la documentación.
Con esto, también es posible transferir un fichero entre dos equipos remotos:
Esta opción es muy potente y permite crear sencillos scripts para unificar configuraciones, por ejemplo imaginemos que queremos tener la misma configuración DNS en un conjunto de servidores, podríamos hacerlo de forma sencilla y potente con ssh mediante el siguiente script:
Al igual que scp, sftp permite transferir ficheros entre equipos remotos a través de SSH, aunque su principal diferencia es que sftp permite utilizarlo de una forma interactiva, al igual que el tradicional ftp, incluyendo los mismos comandos que éste. scp es mucho más habitual utilizarlo desde línea de comandos, mientras que sftp se puede utilizar bien desde la línea de comandos o a través de uno de los múltiples clientes ftp que lo soportan.
Es importante no confundir sftp (ssh ftp) con ftps que es una extensión del protocolo ftp añadiendo ssl para el cifrado de la conexión.
También llamado port-forwarding o TCP-forwarding, se usa en dos casos, para saltarse el cortafuegos o bien establecer una conexión segura y cifrada.
-> En modo local-forwarding, en mi maquina local abro un puerto y desde ese puerto establezco un tunel remoto con ssh a otra máquina.
Por ejemplo, teniendo un servidor web apache en mv1, lo que vamos a hacer es acceder a este servidor mediante otra máquina. Imaginemos que no tenemos acceso desde el anfitrión pero si desde la mv2
Ahora al revisar, puedo ver que se me ha abierto en mi máquina:
Si ahora accedo por navegador a 127.0.0.1:1080 podré ver lo mismo que veía a través de 192.168.1.10, en este caso, la página web de apache2.
-> La otra opción es el proceso contrario, el llamado remote-forwarding, abrir un puerto en la máquina remota, la sintaxis es parecida:
-> El último modo es el dynamic-forward lo que seria un servidor SOCKS parecido a como funciona una VPN, donde yo ejecuto las operaciones a través de un servidor intermedio.
-D 8080: Especifica que SSH debe actuar como un proxy SOCKS en el puerto 8080 de la máquina local.
-f: Esta opción hace que SSH se ejecute en segundo plano después de que se ha autenticado.
-C: Esta opción habilita la compresión de datos. Esto puede ser útil en conexiones lentas ya que reduce la cantidad de datos transmitidos, aunque puede incrementar el uso de CPU.
-q: Esta opción activa el modo silencioso. No se mostrarán mensajes de advertencia ni de diagnóstico. Es útil para suprimir la salida del cliente SSH.
-N: Esta opción indica que no se ejecutará ningún comando remoto. Sólo se establecerá la conexión y se configurará el túnel. Es útil cuando sólo necesitas el túnel SSH y no quieres ejecutar ningún comando en el servidor remoto.
Ahora podemos comprobar la conexión con un
Y, por poner un ejemplo, podemos configurar dentro de nuestro navegador Firefox>Preferencias>Avanzado>Conexión>Configuración
De esta forma podremos navegar por internet a través del servidor. Esto puede servir tambien si no te fías de una conexión de wifi pública por ejemplo te puedes conectar a través de un tunel ssh de un servidor remoto igual que lo harías con una VPN.
Para instalar el servicio necesitamos instalar en Ubuntu el software OpenSSH
Revisa el archivo sshd_config desde /etc/ssh si quieres configurar algunos parámetros de conexión.
Para poder conectarnos por SSH deberemos saber cuál es nuestra dirección IP en la MV con el comando:
Para la securización de nuestro servidor SSH, accederemos a nuestro archivo de configuración por defecto, para ello utiliza el siguiente comando:
Recuerda al final, reiniciar el servicio SSH para que los cambios surtan efecto:
Deshabilitar el inicio de sesión como root es uno de los métodos más antiguos y ampliamente utilizados para evitar que el sistema se vea comprometido en instalaciones de sistemas operativos nuevos.
Puedes evaluar esto dejando la instalación SSH tal como está, analizando el archivo /var/log/secure y contando la cantidad de intentos de fuerza bruta que recibes en unas pocas horas.
Busca la línea “PermitRootLogin” y cambia el valor “yes” a “no”
En Linux y Unix, los administradores pueden crear usuarios con contraseñas en blanco. Y si quieres mantener a los atacantes fuera de tus servidores SSH, esto puede ser una desventaja. Como resultado, lo mejor que puedes hacer es bloquear los inicios de sesión remotos para cuentas con contraseñas en blanco modificando de nuevo el archivo sshd_config y establece:
Dado que SSH está configurado para escuchar en el puerto 22, que es ampliamente conocido entre los atacantes y las herramientas de seguridad, así como los escáneres de puertos que realizan intentos de fuerza bruta, cambiar el puerto es una medida de seguridad efectiva. Edita el archivo de configuración principal de SSH y cambia el puerto del 22 a puertos diferentes, como el 899 directamente sobre el archivo; Busca la línea que contiene la configuración del puerto SSH. Por defecto, esta línea debería verse así:
Cambia el número del puerto (en este ejemplo, 22) a cualquier número que desees, siempre y cuando no esté siendo utilizado por otro servicio en tu sistema. Por ejemplo, puedes establecerlo en 2222:
Asegúrate de que el nuevo puerto esté abierto en el firewall de tu sistema. Puedes permitir el tráfico en el puerto 2222 (o el que hayas configurado) en el firewall (ufw por ejemplo), así:
Establecer un banner de bienvenida personalizado para las conexiones SSH es una buena práctica para todas las máquinas Linux y Unix. Esto no es tanto un consejo de seguridad como una advertencia de seguridad para cualquier acceso no autorizado a tus sistemas. Un banner de advertencia aparecerá una vez que el usuario haya obtenido acceso. Desplázate hacia abajo en el archivo hasta encontrar la sección que comienza con “#Banner“. Debería verse de la siguiente manera:
Elimina el signo de numeral “#” al principio de la línea para activar la configuración y proporciona la ubicación del archivo que contiene tu banner de advertencia personalizado. Puedes utilizar cualquier archivo de texto para el banner. Por ejemplo, si tu banner personalizado está en un archivo llamado “my_custom_banner.txt“, la línea se vería así:
Reemplaza “/ruta/a/my_custom_banner.txt” con la ubicación real de tu archivo de banner personalizado.
Establecer un límite razonable en la cantidad de intentos que un atacante puede realizar para iniciar sesión con una contraseña incorrecta es una medida inteligente para protegerse contra los ataques de fuerza bruta. La configuración MaxAuthTries puede ser útil para evitar tales ataques. Busca MaxAuthTries. Establécelo en 3, como:
Aquí tienes una representación visual hecha con .
Teniendo la IP (asegúrate que la MV está en modo "adaptador puente" para la interfaz de red) ahora abriremos la aplicación de
