Sugerencias de productividad para trabajar con servidores remotos con SSH

SSH tiene muchas características que son útiles cuando se trabaja regularmente con archivos en servidores remotos; Se puede dar un gran incremento en la productividad con el buen uso de SSH su usa regularmente y se configura su entorno correctamente. Su vida puede que se haga un poco más fácil.

Múltiples Conexiones

A menudo es útil tener múltiples conexiones al mismo servidor, por ejemplo, para editar un archivo, ejecutar algunos comandos del sistema de archivos y ver un archivo de registro en diferentes ventanas de terminal. Excepto que a veces puede parecer demasiado complicado, terminando mareados entre tantas ventanas, y tecleando muchas veces el password.

Afortunadamente, OpenSSH tiene una función que hace que sea mucho más ágil obtener otro terminal en un servidor al que ya estás conectado: compartir la conexión. OpenSSH es la implementación de SSH que viene con muchos sistemas operativos Unix, incluidas todas las distribuciones comunes de Linux y Mac OSX.

Para habilitar el uso compartido de la conexión, edite (o cree) su configuración personal de SSH, que está almacenada en el archivo ~/.ssh/config , y agregue estas líneas:

A continuación, salga de cualquier conexión SSH existente y establezca una nueva conexión con un servidor. Ahora en una segunda ventana ejecture SSH a ese mismo servidor.

 

El segundo prompt del terminal debe aparecer casi instantáneamente, y si se le solicitó una contraseña en la primera conexión  no lo hará en el segunda.

Un problema con el uso compartido de conexiones es que, en ocasiones, si la conexión finaliza de forma anómala, el archivo ControlPath no se elimina.

Luego, al volver a conectar OpenSSH, ve el archivo anterior, se da cuenta de que no está actualizado, por lo tanto, lo ignora y, en su lugar, establece una conexión no compartida. Se muestra un mensaje de advertencia como este:

En tales circunstancias, el único remedio que he encontrado al ver dicho mensaje es salir de la conexión, remover el archivo (rm) y luego volver a conectar. Cualquier consejo para hacer esto menos tedioso sería recibido con gratitud.

¿Qué pasa con los usuarios de Windows?

Algunas de estas características de productividad son específicas de OpenSSH, por lo tanto, no trabaje con otros clientes SSH, como Putty. Sin embargo, OpenSSH está disponible para Windows. Si algunas de estas sugerencias de OpenSSH le parecen útiles, puede valer la pena intentar OpenSSH para Windows (o cambiar a un sistema operativo diferente …).

Copiando documentos

Las conexiones compartidas no son solo una bendición para múltiples ventanas de terminal; también hacen que copiar archivos hacia y desde servidores remotos sea muy fácil.

Si usa SSH en un servidor y luego utiliza el comando scp para copiar un archivo en él, scp hará uso de su conexión SSH existente. Y en Bash incluso puede tener el nombre del archivo con Tab en archivos remotos, con el paquete Bash Completion.

Las conexiones también se comparten con rsync, git y cualquier otro comando que use SSH para la conexión.

Conexiones repetidas

Si se encuentra haciendo múltiples conexiones consecutivas al mismo servidor (hace algo en un servidor, cierra la sesión y luego, un poco más tarde, se conecta de nuevo a el), pues creo que es mejor que habilite las conexiones persistentes.

Esta es simplemente una línea más en su configuración (además de las dos anteriores para conexiones compartidas):

Eso hará que las conexiones permanezcan durante 4 horas (o el tiempo que se especifique) después de cerrar la sesión, listo para volver a la vida si solicita otra conexión al mismo servidor durante ese tiempo.

De nuevo, realmente acelera la copia de múltiples archivos; una serie de comandos git push o scp no requiere autenticarse con el servidor cada vez. Tenga en cuenta que la opción ControlPersist requiere OpenSSH 5.6 o posterior.

No escriba contraseñas

Si actualmente escribe una contraseña al hacer una conexión SSH, puede hacer que la conexión sea mucho más agradable configurando las teclas SSH.

Con las claves, se le solicita una frase de contraseña, pero esto solo ocurre una vez por cada inicio de su computadora, en lugar de hacerlo en cada conexión. Con OpenSSH  genere usted mismo una clave privada con:

y sigue las instrucciones. Proporcione una frase de contraseña, de modo que su clave privada esté cifrada en el disco. Luego, debe copiar la parte pública de su clave a los servidores a los que desea conectarse. Si su sistema tiene ssh-copy-id, entonces es tan simple como:

De lo contrario, debe hacerlo de forma manual:

  • Encuentra la clave pública. La salida de ssh-keygen debería decir dónde está, probablemente ~/.ssh/id_rsa.pub .
  • En cada uno de sus servidores remotos inserte el contenido de ese archivo en ~/.ssh/authorized_keys .
  • Asegúrese de que solo su usuario pueda escribir tanto en el directorio como en el archivo.

Algo como esto debería funcionar:

Luego, puede enviar SSH a los servidores, copiar archivos y codificar todos sin tener que usar contraseñas.

Llaves SSH con Putty

Putty también puede hacer claves SSH. Descargue PuttyGen desde el sitio web de Putty, use PuttyGen para generar una clave, cópiela a los servidores remotos .ssh/authorized_keys  como se indica arriba, y luego ejecute Pageant. Ingresar su clave privada, y este seguirá ejecutándose en segundo plano. Putty detectará esto y automáticamente usará la clave proporcionada para las nuevas peticiones en lugar de solicitarle una contraseña. Los detalles completos se encuentran en los capítulos 8 y 9 del manual de Putty.

No escriba nombres de host completos

Es tedioso tener que escribir nombres de host completos para servidores. Normalmente, un grupo de servidores tiene nombres de host que son subdominios de un nombre de dominio particular. Por ejemplo, puede tener estos servidores:

  • www1.ejemplo.org.ar
  • www2.ejemplo.org.ar
  • mail.ejemplo.org.ar
  • intranet.internal.ejemplo.org.ar
  • backup.internal.ejemplo.org.ar
  • dev.internal.ejemplo.org.ar

Es posible que su red esté configurada para que los nombres cortos, como “intranet”, se puedan usar para referirse a ellos. De lo contrario, puede hacerlo usted mismo, incluso sin la cooperación de los administradores de su red local. Exactamente cómo hacer esto depende de su sistema operativo. Esto es lo que funcionó para mí en una instalación reciente de ARCH: editando /etc/dhcp/dhclient.conf , que se adecua al que se encuentra en /usr/share/dhclient/dhclient.conf.example .

Lo importante es añadiendo la siguiente línea:

y reiniciar la red.

Alias de nombre de host

También puede definir alias de nombre de host en su configuración de SSH, aunque esto puede implicar enumerar cada nombre de host. Por ejemplo:

Puede usar comodines para agrupar nombres de host similares, usando% h en el nombre de dominio completo:

No escriba nombres de usuario

Si su nombre de usuario en un servidor remoto es diferente de su nombre de usuario local, especifique esto en su configuración SSH también:

Ahora, aunque mi nombre de usuario local es userspc , puedo hacer lo siguiente:

y SSH se conectará a la cuenta de carlos en el servidor. Los usuarios de Putty pueden guardar los nombres de usuario en su configuración de sesión para evitar que se les solicite en cada conexión.

Conexiones hacia adelante

A veces es útil conectarse de un servidor remoto a otro, particularmente para transferir archivos entre ellos sin tener que hacer una copia local y hacer la transferencia en dos etapas, tales como:

(Aparte: observe cuán útil es $ PWD al copiar entre servidores con diseños de directorio comunes). Incluso si tiene su clave pública instalada en ambos servidores, esto aún solicitará una contraseña de manera predeterminada: la conexión se inicia desde el primer servidor remoto , que no tiene su clave privada para autenticarse contra la clave pública en el segundo servidor.

No “solucione” esto copiando su clave privada a servidores remotos; no quiere tener copias de esas almacenadas en los discos de los servidores, y de todos modos no ayuda mucho porque todavía necesita proporcionar una frase de contraseña para descifrarlo. En su lugar, use el reenvío del agente, con esta línea en su .ssh/config :

Las conexiones flexibles

Puede ser irritante si una interferencia de red termina sus conexiones SSH. Se le puede decir a OpenSSH que ignore las interrupciones cortas (aunque esto también significa que toma más tiempo detectar interrupciones permanentes). Los números precisos para usar son una cuestión de preferencia, pero poner algo así en tu configuración SSH puede que le funcione bien:

Si la red desaparece, su conexión se bloqueará, pero si vuelve a aparecer con 10 minutos, continuará funcionando.

Reiniciar conexiones

Algunas veces su conexión terminará por completo, por ejemplo, si suspende su computadora de un día para otro o la lleva a algún lado, o no hay acceso a Internet. Cuando tenga conectividad nuevamente, la conexión debe reiniciarse. AutoSSH puede detectar cuándo fallaron las conexiones y reiniciarlas automáticamente; no hace esto si una conexión ha sido cerrada por solicitud del usuario. El AutoSSH funciona como un reemplazo directo para ssh. Esto requiere que ServerAliveInterval  y ServerAliveCountMax  se configuren en su configuración SSH, y (algo irritante) esta variable de entorno en su configuración de shell:

Luego puede escribir autossh  en lugar de ssh  para hacer una conexión que se reiniciará en caso de falla. Si quieres esto para todas tus conexiones, puedes evitar el tipeo extra haciendo que AutoSSH sea tu comando ssh. Por ejemplo, si tiene un directorio ~/bin/  en su ruta (y antes de los directorios de todo el sistema) puede hacer:

Ahora simplemente escribiendo ssh le dará un comportamiento AutoSSH. Si está utilizando un sistema basado en Debian, incluido Ubuntu, probablemente debería vincularlo a este archivo, en caso de que alguna vez desee utilizar la opción ssh -M :

AutoSSH no soluciona el problema mencionado anteriormente con archivos obsoletos de ControlPath  (aunque tampoco lo empeora).

Procesos remotos persistentes

Algunas veces desea que un proceso remoto continúe ejecutándose incluso si la conexión SSH está cerrada, y luego volver a conectarse al proceso más tarde con otra conexión SSH. Esto podría ser para activar una tarea que tardará mucho tiempo en ejecutarse y en la que le gustaría desconectarse y volver a consultarla más adelante. O podría ser para proporcionar resistencia contra una conexión escamosa (o batería de computadora portátil), por lo que si se corta abruptamente en el medio de algo, puede recogerlo más tarde una vez que haya recuperado el acceso.

Dtach puede ser de utilidad para esto casos; proporciona la función de procesos separados persistentes de la pantalla. Puedes usarlo así:

La primera vez que ejecute eso, se iniciará un nuevo proceso mutt. Si tu conexión muere (escribe <strong>Enter</strong> ~.  Para que eso suceda) Mutt seguirá funcionando. Vuelva a conectarse al servidor y ejecute el comando anterior una segunda vez; detectará que ya se está ejecutando, y cambiará a él. Si estuvo en algún momento respondiendo un correo electrónico, se lo restablecerá precisamente en ese punto.

 

 

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.