ssh, scp o sftp a un nodo que no aparece en el archivo DNS o /etc/hosts es lento para establecer una conexión inicial. Una vez establecida la conexión, la velocidad es la esperada. Hay dos casos a considerar, ver más abajo. Tenga en cuenta que en la mayoría de los entornos este problema no ocurrirá ya que las direcciones IP estarán en /etc/hosts o DNS.
El tiempo se dedica a resolver la dirección IP del nombre de host de destino/origen o encontrar el nombre de host para la dirección IP de destino/origen y/o realizar la autenticación basada en los mismos datos. Hay dos síntomas detallados diferentes cuando usamos -vvv con ssh constituyendo dos casos diferentes.
Caso 1
# ssh -vvv 10.10.10.205 ... ... debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 10.10.10.205. debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found
En los sistemas CentOS/RHEL, el demonio SSH está configurado para usar Interfaz de programa de aplicación de servicios de seguridad genéricos (GSSAPI) autenticación por defecto. El GSSAPI por defecto realiza una búsqueda (a través de DNS u otros medios basados en /etc/resolv.conf) para la IP solicitada. Tenga en cuenta que la búsqueda ocurre incluso si usa direcciones IP. Eso es necesario para una autenticación segura/confiable.
Si consulta la página de manual de configuración de SSH:
# man ssh_config
...
GSSAPIAuthentication
Specifies whether user authentication based on GSSAPI is allowed. The default is no
... Si la IP/host no aparece en /etc/hosts o en la base de datos DNS, la consulta de búsqueda se agota, ya que vuelve a intentarlo, finalmente se da por vencido y continúa abriendo la conexión. El tiempo se gasta durante la búsqueda (50 segundos o más), hasta que se muestra la solicitud de contraseña. Este bloqueo solo ocurre en los hosts que están en la LAN local y no en el archivo DNS o /etc/hosts. Observe que el método de autenticación es GSSAPI.
Caso 2
# ssh -vvv 10.10.10.12 . . . debug1: Offering public key: /root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply --stalls for 8 seconds--
Aquí, el host remoto intenta realizar una búsqueda de DNS en la IP del nodo del cliente. Puede ser una nueva instalación de máquina física o virtual que no está actualizada en /etc/hosts o DNS y, por lo tanto, se detiene hasta que se agota el tiempo de espera de la consulta de DNS. Una vez más, se realiza la búsqueda de DNS/hosts (basada en /etc/resolv.conf en el cliente/servidor).
La solución
La solución admitida y adecuada para este problema es hacer que las búsquedas de nombre de host/IP tengan éxito. Para hacer eso, usted puede:
- Verifique su configuración en /etc/resolv.conf para la resolución de nombres y la configuración del servidor DNS.
- Si no está definido, defina el host / IP recién introducido que se incluirá en el servidor DNS
- Si es un problema o no vale la pena hacer definiciones de DNS (lo más probable es que la asignación sea temporal, es decir, un sistema de prueba, una máquina virtual temporal, etc.), asegúrese de que el par de nombre de host/dirección IP esté incluido en el origen y el destino archivo /etc/hosts de los entornos (esto es mucho más práctico)
Soluciones alternativas
Sin un DNS / hosts adecuado (o /etc/resolv.conf config para el caso), las conexiones SSH están destinadas a ser inicialmente lentas. Así se espera que sea en OEL. Alternativamente, la situación de espera puede solucionarse con algunos cambios de configuración.
Para Caso 1 la autenticación GSSAPI podría haberse deshabilitado. Aunque eso es posible, se desaconseja encarecidamente ya que el uso de GSSAPI es una de las funciones de seguridad fundamentales proporcionadas por SSH. SSH no solo permite que el contenido de la comunicación sea seguro, sino que también puede garantizar que ese objetivo sea el previsto. Esto se debe a que GSSAPIAuthentication está establecido en sí en OEL (aunque la página de manual dice que es "No" de manera predeterminada, pero es el valor predeterminado de los paquetes ssh principales, no la distribución específica). Aún así, es posible deshabilitarlo, si está perfectamente seguro de que está en una red cerrada y sabe lo que está haciendo:
Configuración temporal:solo para ver si funciona en la línea de comando:
# ssh -o "GSSAPIAuthentication no" 10.10.10.205
La solicitud de contraseña debería aparecer instantáneamente si el Caso 1 es su caso. Para configurar esto de forma permanente (a pesar de cualquier recomendación de lo contrario), puede cambiar GSSAPIAuthentication a no de una de estas formas en el cliente:
1. Agregue la siguiente línea al archivo de configuración ssh del directorio de inicio del usuario (~/.ssh/config ):
GSSAPIAuthentication no
2. Agréguelo al archivo de configuración SSH del sistema en el cliente. es decir – /etc/ssh/ssh_config y en el lado del servidor. Edite el archivo de configuración del lado del servidor (es decir, el sistema al que se está conectando, en este caso es 10.10.10.205) – /etc/ssh/sshd_config y reinicie sshd:
# service sshd restart
esto se puede hacer mientras ya hay conexiones SSH establecidas.
Para el Caso 2, si de alguna manera no puede/no desea modificar la configuración de DNS o los archivos /etc/hosts (a pesar de cualquier recomendación), puede solucionar la situación deshabilitando las búsquedas de DNS realizadas para el protocolo SSH. Puedes hacerlo configurando
UseDNS no
en el archivo de configuración SSH del servidor:/etc/ssh/sshd_config
y reinicie sshd en el servidor
# service sshd restart
esto se puede hacer mientras las conexiones están activas.