Ssh on Apuntes de root

DNS timeout while logging in via SSH

jorti@pm.me (Juan Orti Alcaine) — Fri, 08 Feb 2013 00:00:00 +0000

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

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

jorti@pm.me (Juan Orti Alcaine) — Tue, 24 Apr 2012 00:00:00 +0000

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

Cómo usar GPG agent

jorti@pm.me (Juan Orti Alcaine) — Wed, 05 Oct 2011 00:00:00 +0000

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

Autenticación sin contraseñas en SSH

jorti@pm.me (Juan Orti Alcaine) — Tue, 04 Oct 2011 00:00:00 +0000

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.