SSH sin password

El objetivo es establecer una conexión SSH sin necesidad de teclear una password, evidentemente no a costa de la seguridad, claro está.

Esto puede resultar de utilidad para lo siguiente:

  • Administramos varias máquinas y estamos hartos de teclear.
  • Necesitamos lanzar comandos remotos de manera automática (CRON, script, …).

Esto lo podemos conseguir generando una clave RSA en la máquina cliente, y dejando la parte pública de dicha clave en el servidor, de modo que cuando el cliente intente conectarse al servidor, este se fíe del cliente.

Supongamos que tenemos la siguiente topología de máquinas y usuarios:

[graphviz name=Topologia_maquinas_y_usuarios_para_SSH_sin_password]
node [shape=record];
cliente [label=”{cliente|usuario1}”];
servidor [label=”{servidor|usuario2}”];
cliente -> servidor [label=”SSH”];
[/graphviz]

PASOS A SEGUIR:

  1. Generar la clave RSA en el cliente, desde la cuenta del usuario1:
    ssh-keygen -t rsa
    Esto generará lo siguiente (Pulsa la tecla Enter donde aparezca el texto [ENTER]):
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/usuario1/.ssh/id_rsa): [ENTER]
    Enter passphrase (empty for no passphrase): [ENTER]
    Enter same passphrase again: [ENTER]
    Your identification has been saved in /home/usuario1/.ssh/id_rsa.
    Your public key has been saved in /home/usuario1/.ssh/id_rsa.pub.
    The key fingerprint is:
    67:da:cf:b6:31:8f:3a:a8:aa:fb:96:d6:03:96:fd:82 usuario1@cliente

    Tal y como el log del comando indica esto nos ha generado 2 ficheros: ~/.ssh/id_rsa clave privada, ~/.ssh/id_rsa.pub clave pública.
  2. Copiaremos la clave pública al servidor:
    scp ~/.ssh/id_rsa.pub usuario2@servidor:
    Esto mostrará lo siguiente (introducir la password de usuario2 en [PASSWORD]):
    usuario2@servidor's password: [PASSWORD]
    id_rsa.pub 100% 402 0.4KB/s 00:00
  3. Ahora añadiremos la clave pública del cliente en la lista de claves autorizadas del servidor, para lo cual desde la sesión de usuario2 en el servidor, teclearemos lo siguiente:
    if [ ! -d ~/.ssh ]; then mkdir ~/.ssh; fi
    chmod 700 ~/.ssh
    if [ ! -e ~/.ssh/authorized_keys ]; then touch ~/.ssh/authorized_keys; fi
    chmod 600 ~/.ssh/authorized_keys
    echo ~/id_rsa.pub >> ~/.ssh/authorized_keys

Con estos pasos, ya podremos hacer un SSH desde el cliente al servidor sin que se nos pregunte por una password.

RESOLUCIÓN DE PROBLEMAS:

Lo mejor para solucionar problemas es usar el log, para ello tenemos dos vías:

  1. En el cliente, lanzar el cliente de SSH con toda la traza posible:
    ssh -v -v -v -v cliente2@servidor
  2. En el servidor, ver la traza del servidor de SSH:
    tail /var/log/auth.log

Algunos de los problemas que pueden darse son:

  • No has generado bien la clave en el cliente (repasa el paso 1).
  • Los permisos de la carpeta ~/.ssh o del fichero ~/.ssh/authorized_keys en el servidor no son correctos (repasa el paso 3).
  • La versión de SSH del cliente no corresponde con la del servidor, lo cual puede causar un fallo, para detectarlo y solucionarlo ver las trazas como se ha indicado previamente, y lo normal sería actualizar ambas máquinas.
  • El cliente es más viejo que el servidor, y ha generado una clave que el servidor considera vulnerable. Este error es muy difícil de de detectar, dado que hay que ver en profundidad las trazas del servidor, pero se puede prevenir fácilmente ejecutando el comando en el servidor que nos dirá si tenemos alguna clave en la máquina vulnerable:
    ssh-vulnkey -a
    Si la clave del cliente fuera marcada como vulnerable, tenemos dos opciones:

    • Actualizar el cliente y repetir el proceso sobreescribiendo las claves.
    • Indicar en el servidor que acepte las claves vulnerables, esto lo hacemos editando el fichero de configuración del servidor de SSH del servidor añadiendo la línea (si es que no existe previamente):
      PermitBlacklistedKeys yes

Si tenéis algún problema adicional, no dudéis en enviar un comentario, e intentaré ayudaros. También si alguien ha tenido algún problema con esto, y ha encontrado solución, se agradecería un comentario indicando cuál fue el problema y su solución, de este modo ayudaremos a gente que pudiera tener dicho problema…

9 comentarios

  1. solanye dice: Responder

    Tu pagina es muy buena. pero he tratado de hacer lo mismo que dice en los foros pero no ha sido posible configurar bien el acceso sin contraseña, siempre me la pide. por favor pido ayuda urgente.

    Gracias

  2. juan dice: Responder

    disculpa que te haga esta consulta
    lo que pasa es que trabajo con ubuntu y un amigo me esnseño a huzar ssh pero lo que pasa es que ahora no puedo ingresar desde el servidor a los usuarios y de los usuarios si puedo ingresar al servidor
    cuando trato de ingresar del servidor a un pc de usuario me sale este mensaje:

    Es posible que alguien está haciendo algo malo!
    Alguien podría espiar a usted ahora mismo (“man-in-the-middle ataque)!
    También es posible que la clave RSA acaba de ser cambiado.

    La huella de la clave RSA enviado por el host remoto
    6f: 5c: 9 quater: 30: A6: 68:61:67: b2: 6b: 98: fd: 2e: 43: b0: ee.
    Por favor, póngase en contacto con el administrador del sistema.
    Añadir clave de host correcta en / home / Telecentro / .ssh para deshacerse de este mensaje.
    Ofender clave en / home / Telecentro / .ssh: 3
    clave RSA de acogida para 192.168.10.101 ha cambiado y que ha requerido la comprobación estricta.
    verificación de clave de host ha fallado.

    no se si lo que tu explicas con este tutorial me sirva para poder ingresar a los pc de los usuarios, te dejo mi correo por cualquier solucion que tengas, si no es mucha las molestias, soy de chile y me llamo juan.

    juansho_21@hotmail.com este es mi correo por si me puedes ayudar porfavor y muchas gracias de antemano.

    1. Saludos, un poco tarde pero tal vez a alguien mas le sirva la respuesta.
      Lo que pasa es que la comunicación es unidireccional, es decir: tienes tu maquina cliente, con “un programa cliente de ssh” que se conecta a un servidor con “un servidor ssh (ya no es un cliente ssh es un servidor ssh)”. Para empezar, primero tendrias que instalar en tus maquinas clientes “un servidor ssh” que permita valga la redundancia servir a clientes ssh. otra cosa, tendrias que generar una llave publica al servidor para que se conecte tambien a la maquina cliente y en la maquina cliente generar las llaves primarias.

      Espero les sirva, saludos.

  3. Pablo Javier dice: Responder

    Hola, tengo un servidor y dos clientes, todos debian. Con el primer cliente no tuve nigun problema, con el segundo, siguiendo los mismos pasos, me pide la passphrase, que hice mal?

  4. Una consulta que pasa si en el servidor se usan cuentas nis o ldap y me cambian la contraseña cada 15 dias, esa llave que genere deja de usarse ?? como hace le tema de la autentificacion si me caduca mi clave..

    1. Entiendo que la clave pública y privada no dependen para nada de tu clave de usuario, de modo que no veo por qué habrías de tener problemas; no obstante pruébalo y dentro de 15 días nos cuentas a ver si no has tenido problemas.

  5. andreas dice: Responder

    Bastante util!! Gracias!! Lo has probado Cuando la maquina servidor es windows y el cliente unix?

    1. No, pero entiendo que con Cygwin será posible.

  6. Muchísimas gracias por tu post. Sobre todo por lo de usar “-v -v -v -v” y lo de ver las trazas del servidor (en mi RHEL4 están en /var/log/secure).

    En mi caso, todo el problema se resume a los permisos del $HOME del usuario que recibía las peticiones (sevidor). Tenía un 777 al /home/usuario y así fallaba. Al ponerle 755 se arregló el problema. Por si sirve de algo, añado las líneas del log de sshd donde me avisaba del tema de los permisos:

    Dec 4 14:04:51 serviline4 sshd[25309]: Authentication refused: bad ownership or modes for directory /home/usuario
    Dec 4 13:04:51 serviline4 sshd[25310]: Failed publickey for sybase from ::ffff:172.xxx.yyy.zzz port 52953 ssh2
    Dec 4 13:04:52 serviline4 sshd[25310]: Connection closed by ::ffff:172.xxx.yyy.zzz

Deja un comentario