SSH es una familia de clientes de consola que usa SSL para securizar la conexión. Es el sustituto natural de "telnet". Existen numerosas implementaciones con o sin interfaz gráfica. En todos los sistemas operativos existe un cliente de linea de comandos que se invoca con el comando "ssh".
Conexión usando claves RSA
Habitualmente cuando obtenemos acceso a un servidor remoto, el administrador nos proporcionará un usuario y una contraseña. Eso será suficiente para acceder. Si tenemos problemas, podemos depurar la conexión según se recomienda al final de este documento.
Por el engorro de las contraseñas, el paso normal de los usuarios es a querer usar claves RSA para conectar por SSH. Si las protegemos por una password local (esa clave nunca sale de nuestro sistema) nos acercamos a un buen nivel de seguridad en la gestión de secretos. Por ello, vamos directamente a explicar como se usan claves RSA en canales SSH.
Recuerda que las claves RSA siempre son una pareja que se complementa criptográficamente. Conserva ambas o dejan de ser útiles. Por ejemplo: id_rsa (clave privada) e id_rsa.pub (clave pública).
$ ls -la $HOME/.ssh
-rw------- 1 usrclient usrclient 3389 sep 12 2022 id_rsa
-rw-r--r-- 1 usrclient usrclient 747 sep 12 2022 id_rsa.pub
Mantendremos siempre bajo seguridad y solo para nuestros ojos la clave privada que no debe de caer en otras manos. En el apartado siguiente se recomienda proteger dicha clave privada con un password. Sin embargo, la clave pública puede ser mostrada o enviada a donde sea necesario.
Como se ve los permisos de estos 600 y 644 respectivamente.
Creación del par claves (local)
Puedes crear tantas claves RSA como quieras. La fórmula es la siguiente:
$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usrclient/.ssh/id_rsa):
En este punto podemos optar por poner otro nombre al fichero de claves para reconocerlo. Reusar el nombre de un par de claves anterior en la ubicación por defecto es sobreescribir/destruir esas claves anteriores (OJO!).
Es importante dejar las claves en la ubicación $HOME/.ssh por los automatismos del cliente SSH.
Recomendación: si no vas a automatizar procesos con SSH, se recomienda poner un password para proteger el uso de la clave privada. Te ofrece esa posibilidad cuando ejecutas el comando anterior. En una sesión de escritorio se usará el llavero de linux/windows/mac y no es engorroso, pero si seguro.
Autorizar la clave pública (remoto)
En nuestro equipo local tenemos en este momento los ficheros id_rsa e id_rsa.pub (o con los nombres escogidos). Son respectivamente la clave privada y la clave pública. Debemos de copiar el contenido de la clave pública en un fichero "authorized_keys" localizado en $HOME/.ssh del servidor al que nos queremos conectar usando las claves.
-rw------- 1 usrserver usrserver 747 jul 4 12:59 authorized_keys
Evidentemente, primero hay que conectar con contraseña al servidor remoto y hacer la operación, o pedir la administrador que lo haga por nosotros. Observa que los permisos de este fichero son los adecuados. Como se muestra en la linea anterior, "600" funciona y es seguro.
Típicamente tiene un contenido como el siguiente:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQClTXF+8pLR+a9M3coKxKeDTYc1Ge9I.........Qwf8pKLo77br3LPQ== userclient@escritorioXX
ssh-rsa AAAAB3NzaC1+a9M3coKxKeDTYc1Ge+a9M3coKxKeDTYc1Ge+8pLR9I.........7br3KLo77br3LPQ== userclient@escritorioYY
Cada línea es una clave pública aceptada por el usuario al que pertenece el HOME. Aceptada significa que aquel que venga diciendo ser el usuario propietario del HOME y demuestre tener la clave privada que encaja con esa clave pública tiene el acceso garantizado sin saber la contraseña. No es muy importante el comentario final de cada linea, que es méramente informativo para humanos.
NOTA: usemos contraseña o claves RSA, siempre necesitamos decir el usuario y el servidor remoto al que nos conectamos. Contraseña o claves RSA solo representan el secreto que nos autentica como ese usuario.
Configurar preferencias en local
Por defecto, el cliente SSH buscará el fichero $HOME/.ssh/config en el equipo local desde el que se inicia la conexión para ver qué preferencias tenemos con respecto a la conexión que estamos intentando.
Este fichero es de texto y contiene bloques como el siguiente separados por lineas en blanco.
Host atlas
HostName atlas-scc.atica.um.es
User usrserver
Port 22
IdentityFile ~/.ssh/id_rsa_atlas
HostKeyAlgorithms ssh-rsa
Comentarios:
- Aunque en el equipo local nuestro usuario es "usrclient", en el remoto puede ser cualquier otro nombre.
- La primera linea indica el nombre del bloque en la configuración. NO ES EL NOMBRE DEL SERVIDOR REMOTO. Gracias a ello, en este caso podemos hacer "ssh atlas" y por defecto tomará el usuario "usrserver" y el nombre de host "atlas-scc.atica.um.es". La alternativa a no tener este bloque es por tanto escribir siempre "ssh usrserve@atlas-scc.atica.um.es" equivalente gracias a config a "ssh atlas"
- Estamos diciendo que de todas las parejas de claves RSA utilice la privada id_rsa_altas y la pública id_rsa_atlas.pub.
- Indicamos otras cosas como el puerto y algoritmos criptográficos.
Usar el fichero "config" nos ayuda mucho cuando queremos acortar los comandos ssh, gestionar claves RSA diferentes según destino, opciones criptográficas, diferentes , etc..
Uso explícito en de un par de claves
Además del uso del fichero "$HOME/.ssh/config", existe la posibilidad de indicar en linea de comandos qué clave usaremos para un destino concreto usando el flag "-ii:
ssh -i $HOME/.ssh/id_rsa__específica usrserver@atlas-scc.atica.um.es
Hay muchos más flags para otras formas de conexión.
Depurar problemas
En primer lugar, si hay un problema de conexión debemos de realizar un intento con información de depuración. En Linux se consigue con "-vvv"
Usando -vvv en tu comando SSH obtendrás muchos mensajes por consola. Busca en esos mensajes e identifica la presencia o no de las líneas siguientes y entiende lo que significa.
Ej:
ssh -vvv atlas
Configuraciones por defecto
Las lineas siguientes indican que se están tomando decisiones basadas en la presencia de los ficheros ssh_confg (global) y config (personal). Si no has tocado estos ficheros, puedes saltar este apartado. Debes volver a preguntarte sobre esto si no hay solución con los apartados siguientes.
debug1: Reading configuration data /home/usrclient/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
[...]
¿ Has conseguido conectar ?
Si no obtienes lo siguiente, tenemos un problema de red o de cortafuegos:
debug1: Connecting to atlas-scc.atica.um.es [35.210.226.77] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
Claves RSA disponibles
Tanto si se van a usar como si no, SSH mira las que hay disponibles. Asegúrate de que están las que esperas usar:
debug1: identity file /home/usrclient/.ssh/id_rsa_atlas type 0
debug1: identity file /home/usrclient/.ssh/id_rsa_atlas_alternative type -1
Un poco más abajo, aparecen lineas que indican lo que va a intentar y en qué orden
debug1: Will attempt key: /home/usrclient/.ssh/id_rsa_atlas_alternative RSA SHA256:1+Owg1wFhPfMpzyBZwFhPfMpzNV0Cg97wG0s explicit agent
debug1: Will attempt key: /home/usrclient/.ssh/id_rsa_atlas RSA SHA256:pwFhPfMpzzwFhPfMpzwFhPfMpzwFhPfMpzS1u11Nc0QDo9CU6v3c agent
debug1: Will attempt key: usrclient@escritorio RSA SHA256:aYwyjlt0Tz7sOr57EqHwjTz7siRsxBdZKiGik agent
debug1: Will attempt key: usrclient@escritorio RSA SHA256:joIwxJMxtG2IR/3M5pMxtG2IR/3xDvBxSBZq1Y agent
De nuevo, comprueba que aparezcan tus claves..
¿ Como qué usuario te has presentado ?
Identifica quién intentas ser en el equipo remoto en una linea como la siguiente:
debug1: Authenticating to atlas-scc.atica.um.es:22 as 'usrserver'
Métodos válidos de conexión
Aquí puede pasar que quieras conectarte con contraseña (password) y no esté permitido. También que quieras hacerlo con claves RSA (publickey) y no esté permitido. Esto es una configuración del administrador del servidor remoto
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
Debe estar el método que tu persigues utilizar. Más abajo, tu equipo local va ofreciendo las claves una por una:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/usrclient/.ssh/id_rsa_atlas_alternative RSA RSA SHA256:aYwyjlt0Tz7sOr57EqHwjTz7siRsxBdZKiGik explicit agent
Analiza lo que hace en tu caso.
Todo correcto, pero no me toma las claves
Revisa que exista el fichero $HOME/.ssh/authorized_keys con los permisos (MUY FRECUENTE) que hemos indicado arriba y como propietario el usuario con el que te conectas. El resumen:
En el equipo local:
$ ls -la $HOME/.ssh
-rw------- 1 usrclient usrclient 3389 sep 12 2022 id_rsa
-rw-r--r-- 1 usrclient usrclient 747 sep 12 2022 id_rsa.pub
En el equipo remoto:
$ ls -l $HOME/.ssh
-rw------- 1 usrserver usrserver 747 jul 4 12:59 authorized_keys
Eliminar complejidad para depurar
Si queremos estar seguros de que no usamos claves RSA o para un caso concreto no queremos hacerlo, usamos los flags de SSH siguientes:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password atlas
Estaríamos cogiendo del $HOME/.ssh/config todo menos la info de RSA.
Para estar 100% seguros de que no tenemos nada mal en la config que nos perjudica, podemos comentar la sección del servidor (el bloque "Host atlas" ... ) con "#" al inicio de la linea.
Además impedimos el uso default de claves RSA con los mismos flags.
ssh -vvv -o PubkeyAuthentication=no -o PreferredAuthentications=password usrserver@atlas-scc.atica.um.es
Revisa la salida de consola a la luz de los apartados anteriores.