====== SSH ====== SSH (**S**ecure **Sh**ell) es el nombre de un protocolo y del programa que lo implementa cuya principal función es el acceso remoto a un servidor por medio de un canal seguro en el que toda la información está cifrada. Puerto TCP por defecto: 22. ===== Configuración servidor ===== Fichero ''/etc/ssh/sshd_config'' ===== scp ===== Permite la copia segura de ficheros remotos ==== Mantener tiempos ==== La opción ''-p'' mantiene los tiempos de modificación, acceso y modos del fichero original. scp -p usuario@servidor:/ruta/fichero/remoto.ext /ruta/fichero/local.ext ===== Autenticación ===== ==== Autenticación de llave pública ==== Un método más fiable para autenticar conexiones SSH consiste en utilizar claves de autenticación almacenadas localmente en el disco del usuario. La autenticación por claves no exime de la obligación de utilizar una contraseña, pero garantiza al usuario que la máquina remota es con la que se quiere trabajar, y no una falsificación. Se basa en el cifrado asimétrico (claves públicas y privadas). Creación de claves en el cliente: ssh-keygen -t ''algoritmo'' representa el algoritmo usado para la generación de las claves del cliente. RSA y DSA son dos algoritmos de cifrado asimétricos que se usan a menudo para autenticar. Si no se especifica un algoritmo, se usa el valor por defecto: RSA. Ejemplo: ssh-keygen -t RSA Se crearán los ficheros: * ''.ssh/id_rsa'': clave privada * ''.ssh/id_rsa.pub'': clave pública Ejemplo de generación de claves: $ ssh-keygen -t RSA Generating public/private RSA key pair. Enter file in which to save the key (/home/tempwin/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/tempwin/.ssh/id_rsa Your public key has been saved in /home/tempwin/.ssh/id_rsa.pub The key fingerprint is: SHA256:2jv+123lfWyRCjdZL444jGcELuDeBhN2tr8He0847to tempwin@rrr The key's randomart image is: +---[RSA 3072]----+ | | | .| | + o . ...| | o + o . ooo.| | + S ..o+oo | | . * o.+oooo.| | o + ooB.o *| | ..o.Bo= +.| | .oo=*B.+ | +----[SHA256]-----+ El cliente deberá copiar su clave pública al servidor en el fichero ''.ssh/authorized_keys''. Una forma sencilla, si hemos dejado los valores por defecto al crear las claves, es usar ''ssh-copy-id'': ssh-copy-id usuario@servidorremoto.com En cada conexión, el servidor mira en el directorio local del usuario que se intenta conectar para ver si existe el directorio ''.ssh/authorized_keys'' y si contiene la clave pública del cliente. Si este es el caso, la autenticación del servidor la puede realizar el cliente. La clave privada no puede salir de nuestra máquina. Solo se comparte la clave pública. En cada conexión, el servidor comprueba en dicho fichero del directorio del usuario que contiene la clave pública del cliente. ===== Redirección X11 ===== Si queremos abrir una herramienta gráfica que está en el servidor, pero en nuestro equipo cliente, tendremos que indicar al servidor X donde exportar esa sesión gráfica: export DISPLAY=192.168.1.10:0.0 La IP es la del equipo cliente. Se da por hecho que el equipo cliente (donde vamos a visualizar la aplicación gráfica del servidor) tiene un servidor gráfico X11. Si estuviésemos en un equipo con Windows, tendríamos que utilizar herramientas como XLaunch, del programa [[http://www.straightrunning.com/XmingNotes/|Xming]]. Para que funcione, en el servidor SSH debe estar activada la directiva ''X11Forwarding'' en ''/etc/ssh/sshd_config'': X11Forwarding yes Lo único que nos quedará será ejecutar la aplicación gráfica en el servidor y se visualizará en el cliente. Otra opción más cómoda, si estamos trabajando solo con equipos Linux, es conectarnos con la opción ''-X'': ssh -X usuario@servidor.remoto Toda aplicación gráfica que lancemos en el servidor, se mostrará en el equipo cliente. ===== Túnel SSH ===== También conocido como redirección (mapeo) de puertos (port forwarding) por SSH. Un túnel SSH consiste en establecer una vía de comunicación segura a través de una conexión SSH. Es decir, es posible crear un camino cifrado entre dos equipos. Ventajas: * Asegurar las comunicaciones en protocolos que no son seguros. * Evitar proxy. Para crear un túnel: * Un puerto de una máquina local necesita ser redirigido a un puerto en otra máquina al otro lado del túnel * Una vez establecido el túnel, el usuario se conecta al puerto que acaba de especificar en la máquina local Tipos de redirección: * Redirección local de puertos * Redirección remota de puertos * Redirección dinámica de puertos ==== Redirección local ==== ssh -L puerto_local:ip_remota:puerto_remoto usuario@servidor_con_ssh * ''L puerto_local'': indicamos el puerto de la máquina local (L) que se utilizará * ''ip_remota'': IP del equipo de destino, la IP que tenga localmente en esa red. * ''puerto_remoto'': puerto del equipo destino que se comunicará con el local * ''usuario@servidor_con_ssh'': es el inicio de sesión de un servidor con SSH Ejemplo: ssh -L 8888:10.0.0.10:80 pepito@mi-server.es El comando anterior se muestra en el servidor, es decir, que veremos como iniciamos sesión en la máquina que tiene el servidor SSH. Si no queremos, añadimos la opción ''-N'': ssh -L 8888:10.0.0.10:80 pepito@mi-server.es -N Estamos redirigiendo el puerto local 8888 al puerto 80 en el equipo de destino. Más ejemplos: No se puede acceder a la web de CaraLibro, pero si hacemos: ssh -L 8888:caralibro.com:80 pepito@mi-server.es -N Si abrimos el navegador y vamos a localhost:8888, voilà, acceso a la web sin restricciones. ¿Cómo es posible? Porque quien realmente se conecta a la web es el servidor y nos manda el resultado de la consulta de vuelta al equipo origen a través del túnel. ==== Redirección dinámica ==== El problema de saltarnos la censura de cierta página web, es que si queremos ir a otra página, tendremos que crear otro túnel. La salvación es la redirección dinámica de puertos. Tan sencillo como: ssh -D 8888 usuario@servidor-con-ssh El inconveniente es que la aplicación (el navegador) debe enviar el tráfico usando el protocolo SOCKS, así que hay que configurar el navegador para tal tarea: {{ :informatica:sistemas:linux:socks-firefox.png?nolink |}} Es posible que de primeras no funcione. En mi caso, tuve que editar a mano los siguientes valores a través de ''about:config'': Solo válido para Mozilla Firefox y navegadores basados en él. network.proxy.socks : 127.0.0.1 network.proxy.socks_port : 1337 network.proxy.socks.remote_dns : true network.proxy.socks_version : 5 network.proxy.type : 1 network.proxy.no_proxies_on : localhost, 127.0.0.1, 192.168.0.0/24, .yourcompany.com * http://askubuntu.com/questions/469582/how-do-i-set-up-a-local-socks-proxy-that-tunnels-traffic-through-ssh ==== Ejemplo ==== ssh -N usuario@servidorA -L 12345:servidorB:12345 De esta manera accederíamos a ''servidorB'' desde ''servidorA'' mediante ''localhost:12345''. Esto suele hacerse bastante para conectarse a una base de datos que no está accesible directamente sino que hay que hacerlo desde un servidor intermedio o de salto. ===== Asegurar SSH ===== * Cambiar puerto de escucha por defecto * Utilizar ''Protocol 2'' * ''PermitRootLogin'' -> No * ListenAddress * ''AllowUsers'': indica los usuarios que pueden conectarse por SSH. También se puede indicar la IP desde la que puede conectarse el usuario. * ''AllowGroups'' * ServerKeyBits 4096 * KeyRegenerationInterval 1200s * MaxStartups (Default 10). Si hay pocos usuarios, bajarlo a 3. * Ciphers: aes128-ctr, aes256-ctr,arefour256,arcfour,aes128-cbc, aes256-cbc * MaxAuthTries (por defecto 6) ponerlo a 3 * LoginGraceTime en 60 ===== Recursos ===== * [[https://blog.ktz.me/ssh-tips-and-tricks/|SSH Tips and why ProxyJump is awesome]] * [[https://www.ssh.com/ssh/port|SSH Port]]: historia sobre cómo se escogió el puerto 22 para SSH.