SSH

Acceso remoto mediante SSH. Generalidades

Acceso remoto mediante SSH. Generalidades

En ocasiones, si hemos cambiado el nombre o la dirección IP de la máquina a la que deseamos acceder, puede que al conectarnos nos aparezca el siguiente mensaje de aviso:

Warning: the ECDSA host key for 'pioneer' differs from the key for the IP address '192.168.1.x'
Offending key for IP in /home/david/.ssh/known_hosts:<n>
Are you sure you want to continue connecting (yes/no)?

Donde <n> es un número entero.

Se trata de un aviso estándar de seguridad que nos advierte de una posible brecha de seguridad. Obviamente, si estoy funcionando en mi red privada y soy consciente de que he estado haciendo cambios, este mensaje puede ignorarse con total tranquilidad. No obstante, si queremos deshacernos del mismo, hay dos maneras muy simples.

  1. Las máquinas a las cuales nos hemos conectado se guardan en el archivo mostrado en la ruta del mensaje (known_hosts). Si abrimos este archivo veremos que el formato no es muy amigable, pero tiene la ventaja de que cada host se guarda en una línea de archivo. Así que bastará con borrar la línea número <n> y ya estará.
  2. Lo anterior es sencillo si en dicho archivo tenemos una lista de tres o cuatro máquinas. Pero ¿qué pasa si, como me acaba de ocurrir, resulta que n = 61? Bien, siempre podemos editar el archivo de manera que nos muestre los números de línea, lo cual facilita mucho las cosas:
    nano ~/.ssh/known_host -l
  3. Y si no, siempre podemos usar el siguiente comando, que es de lo más molón:
    sed -i '61d' ~/.ssh/known_hosts
Publicado por David en Linux, SSH, 0 comentarios
Acceso remoto SSH con clave pública

Acceso remoto SSH con clave pública

El acceso a un servidor mediante el uso de clave pública es una alternativa cómoda y segura al tradicional acceso con contraseña. Para ello, lo primero que tenemos que hacer es generar un par de claves pública y privada en el mismo cliente desde el que queramos acceder al servidor por primera vez:

~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<USER>/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/<USER>/.ssh/id_rsa
Your public key has been saved in /home/<USER>/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:mU/wwq4it1/2pIYfl9o5hM4WughDxubXZuGDvR9vo78 engineer@home
The key's randomart image is:
+---[RSA 3072]----+
|                 |
|                 |
|        .        |
| .     . =       |
|  =   . S.o      |
| =   = oo+..     |
|  + o B=*o=      |
|  .+o+o*=@+.     |
|   oo+=**+E+     |
+----[SHA256]-----+

Al generar las claves podemos dejar todos las opciones por defecto, en cuyo caso se nos generarán los archivos correspondientes a una identidad genérica de nombre id_rsa en el directorio /home/<USER>/.ssh/ Sin embargo, es posible y, en ocasiones, aconsejable, utilizar un nombre personalizado para dichos archivos. De esta manera podemos crear varias identidades diferentes, lo que nos permitirá acceder a los servidores remotos bajo diferentes nombres de usuario. En nuestro ejemplo, los archivos creados son los siguientes:

ls ./.ssh/
id_rsa id_rsa.pub

Como podemos ver, la clave pública se guarda en un archivo con la extensión .pub, mientras que la clave privada está en un archivo sin extensión. Cada vez que generemos un nuevo par de claves, éste es el lugar en el que se almacenarán. Por supuesto, las claves pueden ser copiadas de una máquina a otra para poder conectarnos desde diferentes lugares.

En este sentido, es evidente que sólo será necesario generar un nuevo par de claves si no las hemos generado previamente en ésta o en cualquier otra máquina. En este caso, podemos saltarnos este paso y, simplemente, asegurarnos de tener las claves que queremos utilizar en este directorio.

Ahora ya podemos enviar nuestra clave pública al servidor al cual deseamos tener acceso para que nos reconozca a través de la clave privada, la cual permanecerá a buen recaudo en nuestro ordenador cliente.

ssh-copy-id <USERNAME>@<HOSTNAME>

O bien, si hemos especificado un nombre personalizado para el fichero (sin extensión):

ssh-copy-id -i <identidad> <USERNAME>@<HOSTNAME>

Obviamente, necesitamos tener acceso al servidor remoto mediante nombre de usuario y contraseña, los cuales se nos pedirán a continuación. El programa cliente ssh de nuestra máquina local conectará entonces con el servidor y transferirá la clave pública de la identidad especificada, la cual quedará almacenada en el servidor.

A veces, sobre todo si hemos elegido un nombre personalizado para la identidad, puede ser necesario especificar el directorio en el cual se encuentran las claves, es decir: ./.ssh/<identidad>

Insistimos en este punto: A pesar de que cuando especificamos la identidad en el comando anterior no ponemos la extensión, con lo que en realidad la ruta que hemos de escribir coincide con la de la clave privada, la única clave que se transfiere al servidor es la clave pública. Como regla general, una clave privada debe siempre permanecer en nuestro poder y jamás debería ser subida a ningún servidor público ni copiada a ninguna máquina que no está directamente bajo nuestro control y que sea lo bastante segura. Por algo se llama privada.

Y ya está. Sólo nos queda comprobar que podemos conectarnos sin problemas. Como al subir la identidad ésta queda asociada al nombre de usuario podemos, simplemente, escribir:

ssh <USERNAME>@<HOSTNAME>

¿Y si no puedo entrar?

En primer lugar, deberíamos comprobar que el servidor remoto ssh está correctamente configurado para aceptar conexiones mediante autenticación por clave pública. Ésta es la configuración por defecto, por lo que, en principio, no debería ser necesario. Sin embargo, cuando la cosa no funciona, éste uno de los puntos a comprobar, sobre todo si hemos estado toqueteando la configuración del servidor, la cual se encuentra en el siguiente archivo:

sudo nano /etc/ssh/sshd_config

Y comprobar que el parámetro PubkeyAuthentication no esté inadvertidamente configurado en no

Por cierto, ya que estamos, para incrementar la seguridad no está de más desactivar el acceso mediante contraseña:

PasswordAuthentication no

Otra causa frecuente por la que puede estar fallando es que el cliente no esté seleccionando de manera automática la identidad correcta. Esto puede pasar cuando ya llevo un tiempo creando y borrando identidades para entrar en distintos servidores bajo diferentes cuentas. En cualquier caso, la manera de asegurar el tiro es tan sencillo como explicitar la identidad de la que se trata:

ssh -i .ssh/identidad <USERNAME>@<HOSTNAME>
Publicado por David en Linux, Seguridad, SSH, 0 comentarios
Acceso remoto SSH con clave pública y Google 2FA

Acceso remoto SSH con clave pública y Google 2FA

Las dos maneras más populares de asegurar una conexión SSH son el acceso mediante clave pública y la autenticación en dos pasos (2FA). La primera es la que más tradición tiene y la que llevo años utilizando en mis máquinas domésticas. La segunda es algo más reciente y nunca la había utilizado antes, así que me apeteció probarla para aumentar la seguridad. Hay decenas de tutoriales que explican el procedimiento, bastante sencillo, por cierto. Pero como el objeto de este blog es facilitarme las cosas a mí mismo y evitarme el ponerme a rebuscar, aquí dejo el enlace a la guía oficial de ubuntu sobre el tema: Configure SSH to use 2FA

La verdad es que el acceso mediante 2FA es una chulada. Metes la contraseña y te pide un código del Google Authenticator. Sin embargo, una vez disipada la ilusión inicial pensé que no estaría de más sustituir el paso de introducir la contreña por una autenticación mediante clave pública. Mucho más cómodo y, sobre todo, mucho más seguro. Así que configuré un par de claves RSA para entrar al servidor (proceso que, aunque he realizado decenas de veces, siempre se me olvida, así que también lo describiré por aquí).

La sorpresa vino cuando intenté la conexión. El hecho de haber configurado el acceso mediante clave hizo que la entrada al servidor fuera inmediata, sin solicitar el código de validación. Investigando un poco me entero de que, al parecer, el acceso mediante clave anula por defecto cualquier otro método de autenticación. Toda la configuración para el Google 2FA a hacer puñetas. Menudo chasco!

Así que vuelta a investigar la manera de poder mantener ambos modos de authenticación aunque, eso sí, sin necesidad de introducir la contraseña. De momento, dos factores ya me parecen suficientes. Mejor dejar la autenticación multifactor (MFA) para más adelante.

Partimos de la configuración previa del archivo del servidor SSH, que coloco aquí mientras le busco un sitio mejor

sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication yes
PermitRootLogin prohibit-password

La cuestión es que si deseamos mantener ambos métodos de autenticación, de manera que ya no nos pida la contraseña (gracias a la clave RSA) pero nos continúe pidiendo el código de verificación, deberemos indicárselo explícitamente. Para ello, añadiremos una línea especificando dos posibles vías de autorización: O proporcionamos una clave pública y una contraseña, o bien una clave pública y un código de verificación.Las dos posibilidades están descritas en forma de dos listas de métodos. Las listas están separadas por un espacio. Y en cada lista, los métodos requeridos están separados por comas. Si los requisitos de una lista no se dan, entonces se pasa a la siguiente.
Como la configuración de este parámetro parece algo liosa, dejo aquí este enlace en el que lo explican todo muy bien y de manera muy detallada.

AuthenticationMethods publickey,password publickey,keyboard-interactive

Luego debemos modificar el archivo de configuración de PAM para que no nos pida la contraseña

sudo nano /etc/pam.d/sshd

Y comentamos la siguiente línea

#@include common-auth

Y ya está. Si os estáis preguntando por qué es necesario decirle a PAM que no pida contraseña en lugar de quitarla directamente de la lista de los métodos de autorización, os diré que yo me pregunto lo mismo. Lo único que sé es que hice la prueba y no funcionó, pero con el método descrito va como la seda.

Publicado por David en Blog, Seguridad, SSH, 0 comentarios