> For the complete documentation index, see [llms.txt](https://apuntes-alex.gitbook.io/apuntes-sistemas-y-redes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://apuntes-alex.gitbook.io/apuntes-sistemas-y-redes/sistemas-y-servidores/terminal-shell-y-comandos-de-linux/ssh.md). # SSH 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*. {% hint style="info" %} SSH es un protocolo que hace uso de la **criptografía asimétrica** (también denominado de clave pública), ósea aquella en la que NO se usa la misma clave para cifrar y descifrar. Para ello, se crean dos claves relacionadas: **clave privada** y **clave pública**. La privada descifra lo cifrado por la pública y al contrario. Esto evita el problema del cifrado simétrico sin embargo lo vuelve más complejo y hay menos algoritmos disponibles. ![](/files/sk4HD2pFETI6nqOG45fJ) Aquí tienes una representación visual hecha con [idea](https://idea-instructions.com/). Las claves usan factorización de números primos, como RSA o DSA o de curvas elípticas como ECDSA o Ed25519. {% endhint %} 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! ## Instalación y configuración inicial Primeramente instalaremos `Openssh` ```bash sudo apt update sudo apt install openssh-server #Para el servidor apt install openssh-client #Para el cliente ``` Por defecto nos creará varias claves. Para verificar que esta en funcionamiento: ```bash systemctl status openssh #con systemctl ps aux igrep ssh #con ps ss -lntp #con ss aparecerá un proceso ssh en el puerto 22 dpkg -l |grep openssh-server ii openssh-server ``` El fichero de configuración de este servicio se encuentra habitualmente en `/etc/ssh/sshd_config` y contiene las opciones de configuración. ### Consideraciones acerca de root 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: ```bash PermitRootLogin without-password ``` En caso de que quisiéramos permitir acceder con el usuario root y contraseña, deberíamos poner esta opción a “yes”. ### Otras opciones No específicas del acceso con usuario y contraseña, pero adecuadas para empezar: ```bash PrintLastLog yes|no PrintMotd yes|no Banner Ruta_a_fichero ``` {% hint style="info" %} Recuerda que para que funcione en tu ordenador doméstico deberás configurar un reenvio de puertos desde una IP fija a través de tu router. {% endhint %} ## Uso de ssh ### Conexión por contraseña Para la conexión de ssh, lo más sencillo es usar 
ssh root@192.168.1.10 #ssh usuario@IP
ssh root@192.168.1.10 whoami #ssh permite tambien enviar comandos y ejecutarlos para luego cerrar la sesión.
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.

Esto solo lo hace si se autentica por usuario

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: {% code overflow="wrap" %} ```bash ssh-keygen -l -E sha256 -f server.pub #Aquí le estoy dicieendo el algoritmo y el nombre del archivo ``` {% endcode %} 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: ```bash $ ssh -p 27 @ ``` ### Configurar el puerto por defecto Si deseas aumentar la seguridad cambiando el puerto predeterminado (22) del servicio SSH, realiza los siguientes pasos. 1. Abre el archivo de configuración SSH: 
sudo nano /etc/ssh/sshd_config
2. Encuentra la línea que especifica el puerto (por defecto, es `Port 22`), y cámbiala al puerto deseado (por ejemplo, `Port 2222`). 3. Guarda el archivo y reinicia el servicio SSH: ```bash sudo systemctl restart ssh ``` ### Conexión por claves Primero generaremos las claves con: ```bash ssh-keygen -t rsa -b 4096 -o -a 100 -f ~/.ssh/id_rsa_sha2 ``` 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: ```bash mkdir -p ~/.ssh && cat ~/.ssh/id_rsa_sha2.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys ``` 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:

Resultado

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: ```bash ssh-copy-id -i ruta_a_clave_privada usuario@192.168.1.10 ``` Una vez hecho esto ya se puede acceder sin que te pida contraseña: ```bash ssh root@192.168.1.10 ``` En cualquier momento, puedo revisar que claves están autenticadas dentro del fichero `.ssh/authorized_keys`, desde aquí puedo borrar anteriores. {% hint style="warning" %} ### Generación de una clave pública a partir de la privada 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: ``` ssh-keygen -y -f clave >> clave.pub ``` Evidentemente si tenemos la clave pública y no la privada, no podemos hacer el proceso inverso. {% endhint %} ### Conexión con claves y frases de paso 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 : ```bash ssh-keygen -t ecdsa ``` 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: ```bash ssh -i ~/.ssh/id_ecdsa debian@172.22.200.175 Enter passphrase for key '/home/alberto/.ssh/id_ecdsa': ``` 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 `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: ```bash env | grep SSH ps aux | grep ssh-agent ``` El resultado es el siguiente:

el ssh agent ligado a la interfaz de sesión x-session-manager

{% hint style="warning" %} 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: ```bash ssh-agent /bin/bash ``` {% endhint %} En el momento en que yo cree una sesión de paso (requerida) lo veré, ahora deberé vincularlo: ```bash ssh-add ~/.ssh/nombre_de_la_clave_privada ssh-add -l #Listará las claves disponibles ``` 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: ```bash ssh-add -L ``` Y sus huellas con: ```bash ssh-add -l ``` 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: ```bash ssh-add -d nombre_de_la_clave ``` O incluso eliminar todas las claves con: ```bash ssh-add -D ``` {% hint style="info" %} ### {% endhint %}
Error: Cambio de clave pública del servidor Habitualmente se almacenan las claves públicas de los servidores a los que nos hemos conectado previamente en el fichero \~/.ssh/known\_hosts, por lo que se verifica cada vez que se conecta que el servidor ofrece la misma clave pública. En caso de que no coincida veremos el siguiente mensaje: ```bash ssh debian@172.22.200.175 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:J9CMWSbavkqECRI1KWhy8s/D7UVJWDiysAocAbo1F6k. Please contact your system administrator. Add correct host key in /home/alberto/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/alberto/.ssh/known_hosts:88 remove with: ssh-keygen -f "/home/alberto/.ssh/known_hosts" -R 172.22.200.175 ECDSA host key for 172.22.200.175 has changed and you have requested strict checking. Host key verification failed. ``` Es posible que se trate de una suplantación y por tanto un problema de seguridad, pero también es posible que se haya realizado un cambio en el servidor que haya implicado un cambio en las claves del servicio ssh o una situación muy habitual hoy en día: estamos reutilizando la misma IP para un nuevo servidor. En caso de que estemos seguros de que no hay ningún problema de seguridad al acceder a ese equipo remoto, debemos eliminar la antigua clave asociada a la dirección IP (o al nombre), mediante la instrucción: ```bash ssh-keygen -R 172.22.200.175 # Host 172.22.200.175 found: line 88 /home/alberto/.ssh/known_hosts updated. Original contents retained as /home/alberto/.ssh/known_hosts.old ```
### Forwarding 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. ``` ForwardAgent yes ``` Si adicionalmente quisiéramos ejecutar aplicaciones gráficas en el servidor, deberíamos descomentar y editar la siguiente propiedad en el servidor: 
X11Forwarding yes
X11DisplayOffset 10
El cliente para conectarse y utilizar esta funcionalidad, deberá configurar adicionalmente la opción: ``` ForwardX11 yes ``` 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: ```bash env |grep DISPLAY #DISPLAY=localhost:10 ``` Al ejecutar una aplicación en el equipo remoto sobre la conexión ssh nos aparecerá en nuestra pantalla. Por ejemplo *mozilla* o *xeyes*. ## Transferencia de ficheros SSH permite entre otras cosas la transferencia de archivos. ### SCP Ten en cuenta que para el siguiente ejemplo nos estamos traspasando un fichero desde el servidor al anfitrión ```bash #scp usuario@maquinaorigen:ruta_origen ruta_destino scp alex@192.168.1.10 :/home/Descargas/fichero.txt /home/Documentos ``` Si quisiera hacerlo al revés, del anfitrión a la máquina: ```bash scp /home/Documento/fichero2.txt alex@192.168.1.10 :/home/Descargas/ ``` 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: ```bash scp root@172.22.200.175:/etc/hosts root@172.22.200.176:/etc/hosts ``` 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: ```bash #!/bin/bash for i in `seq 1 100`; do scp root@servidor1:/etc/resolv.conf 192.168.1.$i:/etc/resolv.conf done ``` ### SFTP 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. {% hint style="danger" %} 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. {% endhint %} ## Túneles ssh 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 ```bash ssh -f -L 1080:192.168.1.10:80 usuario@192.168.1.20 -N #Recuerda que -f es para que se ponga en segundo plano ``` Ahora al revisar, puedo ver que se me ha abierto en mi máquina: ```bash ps aux |grep ssh #revisión de servicios ss -lntp |grep 1080 #Revisión de puertos ```

Resultado de los comandos

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: ```bash ssh -f -R 8080:localhost:80 usuario@192.168.1.20 -N ``` -> 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. ```bash ssh -D 8080 -f -C -q -N usuario@192.168.1.20 ``` * **`-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

Resultado

Y, por poner un ejemplo, podemos configurar dentro de nuestro navegador *Firefox>Preferencias>Avanzado>Conexión>Configuración*

Rellenamos la parte azul con la IP de arriba "127.0.0.1" y el puerto 8080

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. ## Acceso servidor por Putty Para instalar el servicio necesitamos instalar en Ubuntu el software **OpenSSH** 
sudo apt install openssh-server
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: ```bash $ ip a ``` Teniendo la IP (asegúrate que la MV está en modo "adaptador puente" para la interfaz de red) ahora abriremos la aplicación de [Putty.](https://www.putty.org/)

Ingresa la IP en la parte superior y abre la conexión

## Securización de SSH Para la securización de nuestro servidor SSH, accederemos a nuestro archivo de configuración por defecto, para ello utiliza el siguiente comando: ``` nano /etc/ssh/sshd_config ``` Recuerda al final, reiniciar el servicio SSH para que los cambios surtan efecto: ``` sudo service ssh restart ``` #### 1. Deshabilitar el Inicio de Sesión como Root 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” ``` PermitRootLogin no ``` #### 2. Las Contraseñas en Blanco Deben Ser Deshabilitadas 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: ``` PermitEmptyPasswords no ``` #### 3. Establece un puerto SSH personalizado 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í: ``` Port 22 ``` 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: ``` Port 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í: ``` sudo ufw allow 2222/tcp ``` #### 4. Configura un banner de advertencia personalizado para SSH 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: ``` #Banner /etc/issue.net ``` 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í: ``` Banner /ruta/a/my_custom_banner.txt ``` ``` ******************************************** ** Acceso no autorizado prohibido ** ** Este sistema es para uso ** ** autorizado solamente. ** ** by: esgeeks ** ** ** Todas las actividades ** ** realizadas en este sistema ** ** pueden ser monitoreadas y ** ** registradas para fines de ** ** seguridad de la red. ** ******************************************** ``` *Reemplaza “/`ruta/a/my_custom_banner.txt`” con la ubicación real de tu archivo de banner personalizado.* #### 5. Limita el número de intentos de inicio de sesión con contraseña fallidos 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: ``` MaxAuthTries 3 ``` ## Cheatsheet