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