Historial de página

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

...

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 uadminusrclient uadminusrclient  3389 sep 12  2022 id_rsa
-rw-r--r-- 1 uadminusrclient uadminusrclient   747 sep 12  2022 id_rsa.pub

...

Mantendremos siempre bajo custodia 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.

...

$ ssh-keygen -t rsa -b  4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/uadminusrclient/.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 esa 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/wibndwswindows/mac y no es engorroso, pero si seguro.

...

En nuestro equipo local tenemos en este momento los ficheros id_rsa e id_rsa.pub  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 jhidalgousrserver jhidalgousrserver   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. 600 funcionan y son segurosComo 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== jhidalgo@escritorioXXuserclient@escritorioXX
ssh-rsa AAAAB3NzaC1+a9M3coKxKeDTYc1Ge+a9M3coKxKeDTYc1Ge+8pLR9I.........7br3KLo77br3LPQ== jhidalgo@escritorioYYuserclient@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.

...

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 atlasserver
   HostName atlas-sccserver.aticadominioxx.um.es
   User jhidalgousrserver
  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 alias de la confignombre del bloque en la configuración. NO ES EL NOMBRE DEL SERVIDOR REMOTO. Gracias a ello, en este caso podemos hacer "ssh atlasserver" y por defecto tomará el usuario "jhidalgousrserver" y el nombre de host "atlas-sccserver.aticadominioxx.um.es". La alternativa a no tener este bloque es por tanto escribir siempre "ssh jhidalgo@atlas-scc.aticausrserve@server.dominioxx.um.es" equivalente gracias a config a "ssh atlasserver"
• Estamos diciendo que de todas las parejas de claves RSA utilice la privada id_rsa_altas y  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

...

de un par de claves

Además del uso del fichero "$HOME/.ssh/config" podemos , existe la posibilidad de indicar en linea de comandos qué clave usaremos para un destino concreto usando el flag "-iii"  :

ssh -i $HOME/.ssh/id_rsa__específica jhidalgo@atlas-scc.aticaalternativa usrserver@server.dominioxx.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"

Identifica 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 server

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 server.dominioxx.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

...

 type 0
debug1: identity file /home/

...

usrclient/.ssh/id_rsa_

...

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

...

_alternative RSA SHA256:1+Owg1wFhPfMpzyBZwFhPfMpzNV0Cg97wG0s explicit agent
debug1: Will attempt key: /home/

...

usrclient/.ssh/id_rsa

...

 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..

...

Identifica quién intentas ser en el equipo remoto en una linea como la siguiente:

debug1:

...

 Authenticating to server.dominioxx.um.es:22 as '

...

usrserver'

Métodos válidos de conexión

...

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 De estar permitido "publickey", te remito al apartado donde se ven las claves RSA que se ofrecen y el orden en el que lo hace cada una:

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jhidalgousrclient/.ssh/id_rsa_atlas_alternative RSA RSA SHA256:aYwyjlt0Tz7sOr57EqHwjTz7siRsxBdZKiGik explicit agent

Analiza lo que hace ocurre en tu caso.

Todo parece correcto, .... pero no me toma las claves

Muy frecuentemente es un problema de permisos en las claves. Sobre todo pasa en los ficheros que copiamos de un sitio a otro o que creamos manualmente.

Revisa que tu equipo local tiene las claves con los permisos adecuados:

$ 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, revisa que exista el fichero $HOME/.ssh/authorized_keys con los permisos que correctos que hemos indicado arriba y como propietario el usuario con el que te conectas. El resumen:

En el equipo local (el usuario remoto también es "jhidalgo")

En el equipo remoto (el usuario remoto también es "jhidalgo")

$ ls -l $HOME/.ssh

-rw------- 1 jhidalgousrserver jhidalgousrserver   747 jul  4 12:59 authorized_keys

...

$ ls -ld $HOME
-rw------- 1 usrserver usrserver   747 jul  4 12:59  /home/usrserver

Si no entiendes nada: elimina complejidad para depurar de nuevo

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  

...

server

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 config local que hace referencia a la forma de conectar con el servidor en cuestión (el bloque "Host atlasserver" ... ) con "#" al inicio de la linea. 

Además impedimos el uso default de claves RSA con los mismos flags .SSH:

ssh -vvv -o PubkeyAuthentication=no -o PreferredAuthentications=password  

...

usrserver@server.

...

dominioxx.um.es

Revisa la salida de consola a la luz de los apartados anteriores.

• No consigo conectarme con la clave pública

Permisos incorrectos:if not goto begin: