index.html (21199B)
1 <!DOCTYPE html> 2 <html> 3 <head> 4 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 5 <meta name="viewport" content="width=device-width, initial-scale=1" /> 6 <title>Robustecimiento y securización del protocolo SSH</title> 7 <link rel="icon" type="image/png" href="/favicon.png" /> 8 <link rel="stylesheet" type="text/css" href="../article.css" /> 9 </head> 10 <body> 11 <header> 12 <p class="title">Robustecimiento y securización del protocolo SSH</p> 13 <p class="date">20 de febrero de 2019 • fjbalon</p> 14 </header> 15 <p>SSH es uno de los protocolos más interesantes de los que dispone el administrador de sistemas, permitiendo acceder a otros equipos de forma remota; pero sobretodo, de forma segura. Con SSH creamos un túnel entre cliente y servidor que simula, en la capa de aplicación, la shell o intérprete de comandos del servidor, dotando al administrador de toda funcionalidad en el equipo.</p> 16 <p>SSH puede considerarse una evolución del protocolo Telnet, pero el primero cuenta con técnicas de criptografía para proteger los datos intercambiados entre ambos nodos que conforman la conexión SSH. SSH utiliza un intercambio de claves basado en el protocolo criptográfico de Diffie-Hellman, imprescindible en el robustecimiento de la capa de transporte.</p> 17 <p>SSH trabaja sobre el protocolo TCP/IP. Por ello, en primer lugar se realiza la conexión TCP, realizando el three-way handshake. Después de abrir la conexión, cliente y servidor se envían la versión disponible del protocolo. Se utilizará luego el par de claves, pública y privada, de RSA. El servidor enviará su clave pública de host al cliente, de forma que éste pueda cifrar lo que necesite enviar al servidor. El cliente comparará la clave pública de host con la que tenga almacenada en el archivo known_hosts, si lo hubiera.</p> 18 <p>Una vez el cliente dispone de la clave pública del host del servidor, este generará una clave de sesión aleatoria y seleccionará un algoritmo de cifrado simétrico. Con esta clave de sesión, que se generará por defecto cada 3600 segundos, se cifrará el túnel. El cliente enviará un mensaje que contiene la clave de sesión y el algoritmo de cifrado seleccionado, información que viajará cifrada mediante la clave pública de host, al servidor. En este instante, el resto de la comunicación se utilizará el algoritmo de cifrado simétrico y la clave compartida de sesión, dando velocidad a la conexión (en técnicas de clave simétrica el cifrado y descifrado se hace más rápido), pero utilizando siempre primero el protocolo de Diffie-Hellman para poder enviar de forma segura la clave compartida de sesión; y supliendo así la principal carencia en seguridad de los algoritmos de criptografía simétrica: el intercambio de claves.</p> 19 <p>Con el túnel creado, se llevará a cabo la autenticación del usuario en el servidor, pudiendo utilizar distintos métodos para llevar a cabo tal autenticación.</p> 20 <img src="resources/ssh00.png" style="width: 70%;"/> 21 22 <h1>Autenticación mediante par de claves</h1> 23 <p>una conexión común usando el protocolo SSH es de por sí segura; al menos más segura que una conexión no cifrada como telnet, pero presenta, grosso modo dos inconvenientes:</p> 24 <ul> 25 <li>La contraseña, aún yendo cifrada, viaja por la red siempre que nos autenticamos. Esto puede ser peligroso en el caso que haya alguien sniffeando el tráfico de nuestra red y fuese capaz de descifrar nuestra clave (mediante ataques por fuerza bruta o diccionario, utilizando alguna vulnerabilidad conocida, etc.).</li> 26 <li>En el caso de manejar numerosos servidores y conexiones SSH puede ser muy tedioso tener que estar recordando contraseñas, almacenandolas, etc. Este método agregaría un plus de comodidad y escalabilidad a las conexiones.</li> 27 </ul> 28 29 La implementación del algoritmo RSA presenta solución a estos problemas. Su funcionamiento es: 30 <ol> 31 <li>El cliente envía información sobre su clave pública al servidor.</li> 32 <li>El servidor busca en su base de datos la clave pública del cliente y, cuando la encuentra, envía al cliente un challenge (desafío), que contiene un número aleatorio generado y cifrado por éste utilizando la clave pública del cliente.</li> 33 <li>El cliente recibe el paquete cifrado y usa su clave privada para descifrarlo y devolvérselo al servidor.</li> 34 <li>El servidor comprueba que el número devuelto es el que mandó cifrado, en caso afirmativo, el usuario se ha autenticado y se le permite la sesión de shell.</li> 35 </ol> 36 <p>En ningún momento se envían claves por Internet (más que el envío de la clave pública al servidor en el primer contacto, para que éste la conozca). Por supuesto si alguien accede a nuestro equipo y nos roba la clave privada podría autenticarse como nosotros y suplantar nuestra identidad criptográfica. Por esta razón es necesario proteger las distintas formas de acceso, desde cifrado de particiones a configuración estricta de permisos.</p> 37 <p>También es posible asignar un cifrado simétrico sobre las claves asimétricas, dando una capa extra de seguridad a cambio de tener que introducir una clave cada vez que la usemos.</p> 38 <p>La configuración del servidor oldscizor es sencilla:</p> 39 40 <pre><code># /etc/ssh/sshd_config 41 RSAAuthentication yes 42 PubkeyAuthentication yes 43 AuthorizedKeysFile %h/.ssh/authorized_keys</code></pre> 44 <p>Véase la última línea, donde añadimos el fichero que almacenará las claves públicas de los clientes reconocidos. Si no existiera este directorio y/o fichero deberemos crearlo.</p> 45 <p>Por otro lado, la configuración del cliente scizor consiste en la generación del par de claves RSA para éste:</p> 46 47 <pre><code>$ ssh-keygen -t rsa 48 Generating public/private rsa key pair. 49 Enter file in which to save the key (/home/scizor/.ssh/id_rsa): 50 /home/scizor/.ssh/rsa 51 Enter passphrase (empty for no passphrase): 52 Enter same passphrase again: 53 Your identification has been saved in /home/scizor/.ssh/rsa 54 Your public key has been saved in /home/scizor/.ssh/rsa.pub 55 The key fingerprint is: 56 SHA256:aVgQfYrakZnFhaw4Gcl0bHqrJj7QtR3dXm332wx9qdE scizor@client 57 The key's randomart image is: 58 +---[RSA 3072]----+ 59 | o.o+= o. | 60 | +.o.* . | 61 | * O.+ . | 62 | * Xoo.. . o .| 63 | . . B.+S. . ..oo| 64 |. . o +. . ..E+| 65 | . . oo+| 66 | o o . .o| 67 | ..+ | 68 +----[SHA256]-----+</code></pre> 69 <p>A continuación debemos configurar el ssh-agent para añadirle nuestra clave privada emparejada con la pública que enviaremos al servidor, de forma que, ejecutándose junto a la sesión, éste esté vinculado a ella directamente.</p> 70 71 <pre><code>$ eval $(ssh-agent -s) 72 Agent pid 15081 73 $ ssh-add ~/.ssh/rsa 74 Identity added: /home/scizor/.ssh/rsa 75 (/home/scizor/.ssh/rsa)</code></pre> 76 77 Otra opción es utilizar el fichero config: 78 79 <pre><code># ~/.ssh/config 80 Host oldscizor.es 81 User scizor 82 IdentityFile ~/.ssh/server_key</code></pre> 83 <p>La clave pública deberá ser enviada al servidor y almacenada en authorized_keys o en el fichero seleccionado.</p> 84 85 <pre><code># cat ~/.ssh/authorized_keys 86 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCoaiQqlc0hhqdVsh52sB/ui 87 ISb1pRU/6DVWqyvpCYWQOd8PGNGjuFwYeOnTQ1mZYppuNoXmQxzKXJXGK4ke/ 88 4HcgRHj9l2zZL0LBacnU1NEszqVYUgpI4+1qbyMi0LQZTpKedGULFcSVa1QDt 89 SWTLeQIYTK7dphN4wo7cer9EFkfj5Z1ZNWSjC4blTFTGD2L03aSUklek+BHkk 90 FFGYmVKw/+VD7aOA+Imsb/qHp1eUhEKcHSlWPfDS6qf+GwJoB72v4TMCH1At1 91 fM2LP8o/eRF31fZdRJGOHL+MzfXR0RqS1SLfr/1g6NRohmu1BFFdQQxisovPf 92 h1iOBs4apqQjRl6P6qQziwSVShkkzDW0xOnIflWwbYjo/w1SFN5YzwDaOV3QK 93 VYEeHQGm2mdwPGqPxyeyTaCZqf5Ca2k/Gv53BlRCUb3ATpXTbN6HzIliOUtFm 94 idUAYQwYM0n7VMpL7NW+/1ap6UthX/ep/CjcxGqYZc4+iTSSSict9caCSGSY+ 95 Ec= scizor@client</code></pre> 96 <p>Finalizada la configuración, observamos el proceso de conexión mediante el parámetro verbose:</p> 97 98 <pre><code>$ ssh -v oldscizor.es 99 OpenSSH_8.8p1, OpenSSL 1.1.1l 24 Aug 2021 100 debug1: Reading configuration data /home/scizor/.ssh/config 101 debug1: /home/scizor/.ssh/config line 9: Applying options for oldscizor.es 102 debug1: /home/scizor/.ssh/config line 13: Applying options for oldscizor.es 103 debug1: Reading configuration data /etc/ssh/ssh_config 104 debug1: Connecting to oldscizor.es [54.38.52.183] port 22. 105 debug1: Connection established. 106 debug1: identity file /home/scizor/.ssh/oldscizor type 0 107 debug1: identity file /home/scizor/.ssh/oldscizor-cert type -1 108 debug1: identity file /home/scizor/.ssh/scizorc type 0 109 debug1: identity file /home/scizor/.ssh/scizorc-cert type -1 110 debug1: Local version string SSH-2.0-OpenSSH_8.8 111 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2 112 debug1: compat_banner: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000 113 debug1: Authenticating to oldscizor.es:22 as 'scizor' 114 debug1: load_hostkeys: fopen /home/scizor/.ssh/known_hosts2: No such file or directory 115 debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory 116 debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory 117 debug1: SSH2_MSG_KEXINIT sent 118 debug1: SSH2_MSG_KEXINIT received 119 debug1: kex: algorithm: curve25519-sha256 120 debug1: kex: host key algorithm: ssh-ed25519 121 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none 122 debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none 123 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY 124 debug1: SSH2_MSG_KEX_ECDH_REPLY received 125 debug1: Server host key: ssh-ed25519 SHA256:d6TuEWkCHpZXztBeSP2s2dVCRC+nHu3a2JxnJXioA34 126 debug1: load_hostkeys: fopen /home/scizor/.ssh/known_hosts2: No such file or directory 127 debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory 128 debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory 129 debug1: Host 'oldscizor.es' is known and matches the ED25519 host key. 130 debug1: Found key in /home/scizor/.ssh/known_hosts:7 131 debug1: rekey out after 134217728 blocks 132 debug1: SSH2_MSG_NEWKEYS sent 133 debug1: expecting SSH2_MSG_NEWKEYS 134 debug1: SSH2_MSG_NEWKEYS received 135 debug1: rekey in after 134217728 blocks 136 debug1: Will attempt key: /home/scizor/.ssh/oldscizor RSA SHA256:zFOQBJRsUuKhgVyvCkKaJDcJ/Y7qWq2VEN1lRkJxL74 explicit 137 debug1: Will attempt key: /home/scizor/.ssh/scizorc RSA SHA256:0zdBByBWUvwkcfgcRYL68IdoNMOmJwijG2QiHsgcTaM explicit 138 debug1: SSH2_MSG_EXT_INFO received 139 debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> 140 debug1: SSH2_MSG_SERVICE_ACCEPT received 141 debug1: Authentications that can continue: publickey 142 debug1: Next authentication method: publickey 143 debug1: Offering public key: /home/scizor/.ssh/oldscizor RSA SHA256:zFOQBJRsUuKhgVyvCkKaJDcJ/Y7qWq2VEN1lRkJxL74 explicit 144 debug1: Server accepts key: /home/scizor/.ssh/oldscizor RSA SHA256:zFOQBJRsUuKhgVyvCkKaJDcJ/Y7qWq2VEN1lRkJxL74 explicit 145 Authenticated to oldscizor.es ([54.38.52.183]:22) using "publickey". 146 debug1: channel 0: new [client-session] 147 debug1: Requesting no-more-sessions@openssh.com 148 debug1: Entering interactive session. 149 debug1: pledge: filesystem full 150 debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 151 debug1: client_input_hostkeys: searching /home/scizor/.ssh/known_hosts for oldscizor.es / (none) 152 debug1: client_input_hostkeys: searching /home/scizor/.ssh/known_hosts2 for oldscizor.es / (none) 153 debug1: client_input_hostkeys: hostkeys file /home/scizor/.ssh/known_hosts2 does not exist 154 debug1: client_input_hostkeys: no new or deprecated keys from server 155 debug1: Remote: /home/scizor/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding 156 debug1: Remote: /home/scizor/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding 157 Linux oldscizor 4.19.0-17-cloud-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 158 159 The programs included with the Debian GNU/Linux system are free software; 160 the exact distribution terms for each program are described in the 161 individual files in /usr/share/doc/*/copyright. 162 163 Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 164 permitted by applicable law. 165 Last login: Tue Nov 16 21:56:22 2021 from 172.16.7.12 166 scizor@oldscizor:~$</code></pre> 167 <p>El cliente lee el fichero ssh_config antes de realizar la conexión al servidor oldscizor.es en su puerto por defecto 22. Tras esto, se crea la conexión TCP y, una vez se realiza el three-way handshake entre cliente y servidor, la conexión queda establecida; pero aún no existe canal cifrado.</p> 168 <p>El cliente verifica la existencia de posibles claves privadas y verifica si se encuentra alguna en la lista negra. Una vez realizado este proceso, verifica también la versión del protocolo. Es en este instante en el que se intercambian la clave pública host del servidor al cliente, para que éste pueda generar y cifrar la clave simétrica, la cual será la encargada de cifrar el canal.</p> 169 <p>Una vez el cliente recibe la clave del host, la verifica en el fichero known_hosts. Si se encuentra, se verifica la identidad del servidor. Si por el contrario no se encuentra mostraría un mensaje avisando de la posible suplantación (por defecto).</p> 170 <p>Tras aceptar el cliente al servidor, verificando la identidad de éste, se establece la conexión en un canal ya seguro. El servidor envía el banner y el cliente lo muestra por pantalla. Despues, el servidor envía al cliente los métodos de autenticación para el usuario de los que se disponen y el cliente valorará su configuración previamente cargada para realizar la autenticación pertinente; que en nuestro ejercicio es una autenticación basada en claves RSA, y tras autenticarse, se envían desde el servidor las variables de entorno de la sesión y proporciona el control de la shell en remoto.</p> 171 172 <h1>Aplicaciones del protocolo SSH</h1> 173 <p>Sobre SSH existen varias aplicaciones que sirven de arsenal bastante completo al administrador de sistemas. Enumero las que conozco:</p> 174 <h2>Automatización envío de claves públicas RSA</h2> 175 <p>La utilidad ssh-copy-id permite enviar las claves públicas directamente a tantos servidores sea necesario, automatizando y simplificando la comunicación cifrada contra múltiples equipos sin necesidad de abrir una sesión en cada uno de ellos.</p> 176 177 <pre><code> .---------------------------------------. 178 | aws:/home/thufir/.ssh/authorized_keys | 179 |---------------------------------------| 180 | ssh-rsa AAAA... user10@host | 181 '---------------------------------------' 182 ^ 183 | 184 | 185 ssh-copy-id | .---------------------------------------. 186 | | aws:/home/ubuntu/.ssh/authorized_keys | 187 .---' |---------------------------------------| 188 | | ssh-rsa AAAA... user10@host | 189 | '---------------------------------------' 190 | ^ 191 .---------------------------------------. | 192 | local:/home/user10/.ssh/id_rsa | | ssh-copy-id 193 | Private Key | | 194 |---------------------------------------| | 195 | BEGIN RSA PRIVATE KEY |----------. 196 | Proc-Type: 4,ENCRYPTED | | 197 | DEK-Info: AES- | | ssh-copy-id 198 '---------------------------------------' | 199 | v 200 | .---------------------------------------. 201 '---. | aws2:/home/user5/.ssh/authorized_keys | 202 | |---------------------------------------| 203 | | ssh-rsa AAAA... user10@host | 204 ssh-copy-id | '---------------------------------------' 205 | 206 v 207 .----------------------------------------. 208 | aws2:/root/.ssh/authorized_keys | 209 |----------------------------------------| 210 | ssh-rsa AAAA... user10@host | 211 '----------------------------------------'</code></pre> 212 <h2>Automatización de contraseñas con sshpass</h2> 213 <p>Aunque no soy amigo de utilizar la autenticación básica por contraseña en mis infraestructuras SSH, a veces es necesario autenticar de esta forma, y nunca esta utilidad que permite al usuario cierta automatización a la hora de gestionar conexiones, principalmente cuando esta administración se hace desde otros programas o scripts donde no puede haber interactividad directa. La utilidad sshpass está diseñada para ejecutar SSH utilizando el modo de autenticación de contraseña interactiva de teclado, pero de una manera no interactiva, utilizando acceso TTY directo para garantizar que la contraseña sea emitida por un usuario de teclado interactivo, engañando a SSH haciéndole creer que está obteniendo la contraseña de un usuario interactivo.</p> 214 <p>Su modo de uso es tan sencillo como indicar previamente a la comunicación con el servidor SSH la clave de éste tras el comando propio de sshpass:</p> 215 216 <pre><code>$ sshpass -p !4u2tryhack ssh user@host</code></pre> 217 <h2>SCP</h2> 218 <p>SCP o Secure Copy es un protocolo similar funcionalmente a RCP (Remote Copy), cuyo objetivo es transferir archivos desde una máquina a otra. La diferencia entre ambos protocolos es que SCP utiliza el protocolo SSH para establecer sus comunicaciones, estableciendo un túnel cifrado por el que enviar dichos archivos.</p> 219 <p>La ejecución de SCP es realmente sencilla, contando con la sintaxis:</p> 220 221 <pre><code>$ scp [opciones] origen destino</code></pre> 222 <p>Donde el origen o destino local es la ruta, ya sea absoluta o relativa y el origen o destino remoto cumple con su propia sintaxis:</p> 223 224 <pre><code>usuario@host:<ruta_archivo></code></pre> 225 <p>De tal forma que para enviar un archivo a un servidor mantendríamos la sintaxis:</p> 226 <pre><code>$ scp /home/scizor/archivo oldscizor.es:/usr/archivo</code></pre> 227 <p>Y siendo la forma inversa:</p> 228 229 <pre><code>$ scp oldscizor:/usr/archivo2 /home/scizor/archivo2</code></pre> 230 <p>Cabe destacar que también podemos realizar copias seguras entre máquinas remotas, no necesariamente debe ser una origen o destino local:</p> 231 <pre><code>$ scp oldscizor.es:/root/origen root@172.16.1.2:/etc/destino</code></pre> 232 <h2>SFTP</h2> 233 <p>SSH File Transfer Protocol o SFTP permite el envío de ficheros a nivel de aplicación, a través de SSH, utilizando las aplicaciones y los comandos propios del protocolo FTP. Es sabido que el protocolo FTP no es seguro per se, debido a que no cuenta con cifrado.</p> 234 <p>La sintaxis es similar al protocolo FTP, manteniendo una vez establecida la conexión una cadena de conexión a nivel de aplciación similar a SSH.</p> 235 236 <pre><code>$ sftp oldscizor.es 237 Connected to 10.101.5.3- 238 sftp></code></pre> 239 <h2>SSHFS</h2> 240 <p>El protocolo SSH dispone de la posibilidad de gestionar el sistema de archivos de manera remota y segura utilizando SSHFS o Secure Shell File System. En el equipo local donde se realiza el montaje de SSHFS, la implementación hace uso del módulo del kérnel FUSE.</p> 241 <p>La sintaxis es sencilla. Se debe ejecutar el comando sshfs seguido de la ruta remota que se quiere montar localmente y, por último, la ruta local que se utilizará como punto de montaje.</p> 242 243 <pre><code>$ mkdir fs 244 $ sshfs oldscizor.es:/home/git fs 245 $ ls -l fs 246 drwxr-xr-x 7 git git 4096 Nov 15 09:47 arch.git 247 drwxr-xr-x 7 git git 4096 Oct 25 16:31 automata.git 248 drwxr-xr-x 7 git git 4096 Nov 12 10:33 crypto.git 249 drwxr-xr-x 7 git git 4096 Nov 12 10:22 dmenu.git 250 drwxr-xr-x 7 git git 4096 Nov 15 09:32 dotfiles.git 251 drwxr-xr-x 7 git git 4096 Nov 9 23:32 dwm.git</code></pre> 252 <p>Una vez realizado el montaje, se puede utilizar cualquier tipo de operación como si la ruta fuera local. También podemos utilizar sobre el punto de montaje cualquier software, como un gestor de archivos gráfico para desempeñar el trabajo que sea. Todas las acciones remotas las hará de forma transparente al usuario y mediante un túnel cifrado.</p> 253 <h2>X11 forwarding</h2> 254 <p>Esta opción del protocolo SSH permite al usuario conectarse a un servidor para levantar procesos que requieran de un servidor gráfico para su interacción. De tal modo que un administrador pueda, por ejemplo, ejecutar un navegador en un servidor remoto, y la presentación gráfica se realizará en la máquina local a pesar del proceso encontrarse ejecutando en la máquina remota. Evidentemente, toda comunicación cliente-servidor se realizará de manera segura mediante el protocolo SSH, por lo que los datos de presentación del proceso viajarán por la red bajo este protocolo. Para poder redirigir la salida de las ventanas de los procesos que se ejecutan, el servidor debe habilitar la directiva X11Forwarding en su fichero sshd_config.</p> 255 <p>Si bien el <a href="../ssh-tunneling/">SSH Tunneling</a> puede considerarse una aplicación del protocolo, he decidido hacer una entrada a parte sólo para ese caso, pues es más complejo y especial.</p> 256 257 </body> 258 </html>