DNS timeout while logging in via SSH

In a computer which is in a isolated network, I have experienced a long delay while logging in via SSH. This is because a DNS timeout. It’s possible to disable the DNS lookups of sshd, modifying this setting in /etc/ssh/sshd_config:

UseDNS no
Advertisements

Ejecutar aplicaciones gráficas con otro usuario en una sesión X remota

Ocurre bastante a menudo que cuando te conectas a una máquina remota mediante SSH y necesitas lanzar un comando con otro usuario, te da un error semejante a este:

$ sudo virt-manager
[sudo] password for juan:
PuTTY X11 proxy: wrong authorisation protocol attemptedPuTTY X11 proxy: wrong authorisation protocol attemptedPuTTY X11 proxy: wrong authorisation protocol attemptedPuTTY X11 proxy: wrong authorisation protocol attemptedTraceback (most recent call last):
File "/usr/share/virt-manager/virt-manager.py", line 383, in <module>
main()
File "/usr/share/virt-manager/virt-manager.py", line 286, in main
raise gtk_error
RuntimeError: could not open display

Esto es debido a que el servidor X utiliza una cookie de autenticación que se guarda en el perfil del usuario en ~/.Xauthority
Para poder pasar esta autenticación a otro usuario, podemos utilizar los siguientes comandos:

Primero listamos las cookies que tenemos

$ xauth list
xenon.local/unix:11  MIT-MAGIC-COOKIE-1  32a84908586f4e23c0b68f4478a32578
xenon.local/unix:10  MIT-MAGIC-COOKIE-1  ba33662833233fe85ece9e4825c44d5d

Y luego localizamos la que nos interesa fijándonos en el valor de la variable DISPLAY y se la añadimos al otro usuario:

$ echo $DISPLAY
localhost:10.0
$ su -
Contraseña:
# xauth add xenon.local/unix:10  MIT-MAGIC-COOKIE-1  ba33662833233fe85ece9e4825c44d5d

Ahora ya podemos lanzar cualquier comando como root y las X se redirigirán por nuestra conexión SSH.

Cómo usar GPG agent

El agente de GPG es una herramienta muy útil para evitar estar metiendo continuamente las contraseñas para desbloquear las claves GPG o en las conexiones SSH. Por desgracia no suele estar habilitado por defecto en la consola, pero vamos a ver como solucionarlo. Esta solución está basada en este comentario.

El kit de la cuestión es que solo puede haber una instancia de gpg-agent por usuario y en cada sesión se tienen que configurar las variables de entorno necesarias. Estas variables las vamos a guardar en el archivo ~/.gpg-agent-info

Primero creamos dos entradas en nuestro crontab que se encargarán de lanzarlo:

$ crontab -e

@reboot         umask 0077; rm -f $HOME/.gpg-agent-info; pgrep -U $LOGNAME gpg-agent >/dev/null 2>&1 || gpg-agent --daemon --enable-ssh-support --write-env-file "${HOME}/.gpg-agent-info" >/dev/null 2>&1
*/5 * * * *     umask 0077; pgrep -U $LOGNAME gpg-agent >/dev/null 2>&1 || gpg-agent --daemon --enable-ssh-support --write-env-file "${HOME}/.gpg-agent-info" >/dev/null 2>&1

Con la primera línea borraremos este archivo al arrancar el sistema y lanzaremos el demonio. Con la segunda línea comprobamos cada 5 minutos que el demonio está corriendo y en caso contrario, lo lanzamos.

Ahora vamos a modificar el archivo ~/.bash_profile para configurar el entorno. Añadimos las siguientes líneas:

# Launch GPG Agent
GPG_TTY="$(tty)"
export GPG_TTY
if [ -n "$(pgrep -U $LOGNAME gpg-agent)" -a -f ${HOME}/.gpg-agent-info ]; then
   . ${HOME}/.gpg-agent-info
   export GPG_AGENT_INFO
   export SSH_AUTH_SOCK
   export SSH_AGENT_PID
   echo "GNU Privacy Guard Agent [ENABLED]"
else
   unset GPG_AGENT_INFO
   unset SSH_AUTH_SOCK
   unset SSH_AGENT_PID
   if [ -f ${HOME}/.gpg-agent-info ]; then
      rm -f ${HOME}/.gpg-agent-info
   fi
fi

Autenticación sin contraseñas en SSH

Todo un clásico, pero extremadamente útil cuando tienes varias máquinas para administrar.

$ ssh-keygen -t rsa -b 4096 -C "your_email@youremail.com" #Genera la clave
$ ssh-copy-id username@remote-host #Copia la clave al servidor remoto

Para los paranoicos es una buena idea tener anotados de antemano los fingerprints de los servidores. De esta forma si intentamos conectar alguna vez desde algún entorno no seguro donde no tengamos cacheada la clave en ~/.ssh/known_hosts podremos estar seguros de que no nos están haciendo un man in the middle.

$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 e7:1c:1b:2f:7b:e5:a2:b8:aa:01:d5:79:07:0f:e2:1a /etc/ssh/ssh_host_rsa_key.pub (RSA)