![[OpenSSH]](../images/smalltitle.gif){kind=small}
El cliente de OpenSSH usa puertos de baja numeración para autenticación de rhosts y rhosts-rsa debido a que el servidor necesita confiar en el nombre de usuario provisto por el cliente. Para evitar esto, puede añadir el ejemplo que sigue a su fichero ssh_config o ~/.ssh/config.
UsePrivilegedPort no
O puede especificar esta opción en la línea de órdenes, usando la opción -o con la orden ssh(1).
$ ssh -o "UsePrivilegedPort no" host.com
2.2 - ¿Por qué el programa cliente de ssh se instala como setuid root?
En relación con la pregunta anterior (2.1), OpenSSH necesita la autoridad del superusuario, root, para enlazar con puertos de numeración baja para poder facilitar la autenticación de rhosts. También se requiere un puerto con privilegios para la autenticación de rhosts-rsa con versiones de SSH más antiguas.
Además, tanto para la autenticación rhosts-rsa (en la versión 1 del protocolo) como para la autenticación basada en host (en la versión 2 del protocolo), el programa cliente de ssh necesita poder acceder a la clave privada del host para autenticar la máquina cliente ante el servidor. Por tanto, también es necesario el bit setuid root para estos métodos de autenticación.
Si no quiere usar estos métodos de autenticación puede eliminar el bit setuid del ejecutable de ssh sin peligro.
2.3 - ¿Por qué hay problemas de interoperabilidad entre SSH 2.3 y OpenSSH 2.1.1?
SSH 2.3 y las versiones anteriores contenían un error de diseño en su implementación de HMAC. Su código no pasaba todo el bloque de datos de la salida del resumen, y en su lugar siempre ofrecía 128 bits. Esto hacía que SSH 2.3 no pudiera interoperar con OpenSSH cuando los resúmenes eran más grandes.
OpenSSH 2.2.0 detecta este error de diseño en SSH 2.3. En el futuro, las próximas versiones de SSH tendrán este error solucionado. También puede añadir lo siguiente al fichero de configuración sshd2_config de ssh 2.3:
Mac hmac-md5
2.4 - ¿Por qué OpenSSH muestra el mensaje: Dispatch protocol error: type 20
Se han detectado problemas de interoperabilidad debidos a que las versiones antiguas de OpenSSH no disponían de soporte para rehacer las claves de sesión. Sin embargo, la versión comercial 2.3 de SSH intenta negociar esta funcionalidad, y es probable que en este caso experimente congelaciones o que vea el mensaje de error "Dispatch protocol error: type 20 ". Para solucionar este problema, actualice OpenSSH a una versión reciente o desactive "rekeying" añadiendo lo siguiente a los ficheros ssh2_config o sshd2_config de la versión comercial 2.3 de SSH.
RekeyIntervalSeconds 0
2.5 - Las versiones antiguas comerciales de SSH cifran las claves anfitrionas con IDEA.
Las versiones antiguas de SSH usaban un algortimo patentado para cifrar sus ficheros /etc/ssh/ssh_host_key. Este problema se manifiesta cuando sshd(8) no puede leer su clave anfitriona. Para evitarlo, use la orden que se cita a continuación y así convertir su ssh_host_key para que use 3DES. NOTA: Para esto use el programa ssh-keygen(1) del producto comercial SSH, *NO* el de OpenSSH:
# ssh-keygen -u -f /etc/ssh/ssh_host_key
2.6 - ¿Qué son esos mensajes de aviso sobre el tamaño de la clave?
El programa ssh-keygen(1) de la versión comercial de SSH contenía un error que, en ocasiones, generaba claves públicas de autenticación (RSA o DSA) con su MSB (Most Significant Bit) desactivado. Dichas claves aseguraban ser de tamaño completo, pero en realidad, la mitad de las veces, su tamaño era más pequeño de lo que aseguraban.
Siempre que OpenSSH encuentre una de estas claves, mostrará un mensaje de aviso. Si no desea ver este mensaje, edite sus ficheros known_hosts y substituya el tamaño incorrecto de la clave (que suele ser ´1024´) con el tamaño correcto (que suele ser ´1023´).
2.7 - X11 y/o el agente de reenvío no funcionan.
Compruebe sus ficheros ssh_config y sshd_config. Los ficheros con la configuración predefinida desactivan el agente de autenticación y el reenvío en X11. Para activarlos, añada esta línea a sshd_confif:
X11Forwarding yes
y añada las siguientes líneas a ssh_config:
ForwardAgent yes
ForwardX11 yes
NOTA: Para los usuarios de Linux Mandrake 7.2. Mandrake modifica la variable de entorno XAUTHORITY en /etc/skel/.bashrc, y por consiguiente la cualquier directorio de usuario de bash. Esta variable la configura OpenSSH, y para cada que funcione cada una de las opciones anteriores debe comentar la línea:
# export XAUTHORITY=$HOME/.Xauthority
2.8 - Después de actualizar OpenSSH he perdido el soporte para SSH2.
Es posible que se produzcan cambios en sshd_config o ssh_config entre versiones. Siempre que cambie de versión de OpenSSH debe comprobar si se ha producido alguno de estos cambios. A partir de la versión 2.3.0 en adelante, debe añadir lo siguiente a sshd_config:
HostKey /etc/ssh_host_dsa_key
HostKey /etc/ssh_host_rsa_key
2.9 - sftp/scp falla al conectar, per ssh funciona bien.
Es probable que sftp y/o scp fallen en el momento de la conexión si tenemos un fichero de inicio de la shell (.profile, .bashrc, .cshrc,, etc... ) que produzca una salida para sesiones no interactivas. Esta salida confunde al cliente de sftp/scp. Puede verificar si su shell está haciendo esto del modo siguiente:
ssh yourhost /usr/bin/true
Si la orden anterior produce cualquier tipo de salida, deberá modificar el fichero de inicio de su intérprete de órdenes (shell).
3.0 - Preguntas sobre la versión «portable» de OpenSSH
3.1 - Mensajes falsos de autenticación con PAM en los ficheros de registro.
La versión portable de OpenSSH generará falsos fallos en la autenticación en cada ingreso, como el siguiente:
"authentication failure; (uid=0) -> root for sshd service"
Estos mensajes se generan debido a que OpenSSH intenta antes que nada determinar si un usuario necesita autenticación para el ingreso (v.g. contraseña vacía). Desafortunadamente PAM registra todos los intentos de autenticación, incluido éste.
Si le molesta demasiado configure PermitEmptyPasswords no en el fichero sshd_config. Esto acallará el mensaje de error, pero a cambio desactivará la posibilidad de ingreso en cuentas que no tengan una contraseña activada. Si Vd usa el fichero de configuración del programa, esta opción viene predeterminada.
3.2 - La autenticación mediante PAM no permite contraseñas vacías.
Para activar las contraseñas vacías en una versión de OpenSSH compilada con PAM debe añadir el indicador nullok al final del módulo de verificación de la contraseña en el fichero /etc/pam.d/sshd. Por ejemplo:
auth required/lib/security/pam_unix.so shadow nodelay nullok
Además de esto debe configurar PermitEmptyPasswords yes en el fichero sshd_config.
Existe un pequeño problema cuando se usan contraseñas vacías con PAM: PAM permite el uso de cualquier contraseña cuando se autentica una cuenta con una contraseña vacía. Esto desarticula el proceso de comprobación que usa sshd(8) para determinar si una cuenta tiene o no la contraseña activada y permitir el acceso a los usuarios de la cuenta sin importarle la política especificada por PermitEmptyPasswords. Por este motivo se recomienda que no se añada la directiva nullok al fichero de configuración de PAM a menos que realmente desee permitir el uso de contraseñas vacías.
3.3 - ssh(1) tarda mucho en conectar con Linux/glibc 2.1
La biblioteca glibc que se incluye en Redhat 6.1 parece tardar mucho en resolver direcciones IPv6 ó IPv4 desde nombres de dominios. Esto se puede «trucar» con la opción de configuración --with-ipv4-default. Esta opción indica a OpenSSH que use sólo la resolución de direcciones IPv4 (la resolución de direcciones IPv6 se puede llevar a cabo especificando la opción -6 en este caso).
3.4 - Mensajes en los registros (log) de Linux: ´Can´t locate module net-pf-10´.
El núcleo Linux busca (por medio de modprobe) el protocolo ´family 10´ (IPv6). Para evitarlo puede cargar el módulo del núcleo adecuado e introducir el alias correcto en /etc/modules.conf, o bien desactivar IPv6 en /etc/modules.conf.
Por alguna estúpida razón, /etc/modules.conf también se puede llamar /etc/conf.modules.
3.5 - La autenticación de la contraseña no funciona en Slackware 7.0.
En Slackware 7.0 debe enlazar OpenSSH con libcrypt.
LIBS=-lcrypt ./configure [options]
3.6 - ´configure´ o sshd(8) se quejan de que falta el soporte para RSA.
Asegúrese de que las bibliotecas de OpenSSL se han compilado con el soporte para RSA o DSA incluido, bien de modo interno o a través de RSAref.
3.7 - Errores "scp: command not found".
scp(1) se debe encontrar especificado en el PATH predeterminado, tanto en el cliente como en el servidor. Es probable que deba usar la opción --with-default-path para especificar un camino ("path") personalizado de búsqueda en el servidor. Con esta opción se substituye el camino predeterminado, por lo que deberá especificar todos los directorios actuales en su camino, así como el directorio en donde haya instalado scp. Por ejemplo:
$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/camino/hasta/scp
3.8 - No puede leer la contraseña (´Cannot read passphrase´).
Algunos sistemas operativos configuran /dev/tty con modos incorrectos, haciendo que la lectura de contraseñas falle con el siguiente error:
You have no controlling tty. Cannot read passphrase.
La solución está en reconfigurar los permisos en /dev/tty con el modo 0666 e informar sobre el error al distribuidor de su sistema operativo.
3.9 - Falta configure o hay fallos durante make.
Si no existe el fichero configure dentro del archivo tar.gz que se haya bajado, o si make falla dando errores del tipo ´missing separators´, es probable que haya bajado la distribución de OpenSSH para OpenBSD y que esté intentando compilarla en otra plataforma. Por favor, mire la información que encontrará en la página de la versión portable.
3.10 - Al terminar, ssh se queda colgado
OpenSSH puede colgarse al salir del programa. Esto puede ocurrir cuando hay un proceso activo en segundo plano. Se conoce que sucede en Linux y HP-UX. El problema se puede verficar del siguiente modo:
En su lugar, intente lo siguiente:
$ sleep 20 & exit
$ sleep 20 < /dev/null > /dev/null 2>&1 &
Los usuarios de bash pueden evitarlo añadiendo la
línea "shopt -s huponexit" en el
fichero /etc/bashrc o ~/.bashrc. Si esto no
funcionara o si utiliza otro intérprete de órdenes,
consulte la página de manual de éste y busque una
opción para permitir que el intérprete envíe una
señal HUP a los procesos activos cuando acaben.
3.11 - ¿Por qué ssh se queda colgado al terminar?
Cuando se ejecuta
ssh necesita quedarse colgado, porque necesita esperar:
$ ssh host command
- hasta que esté seguro de que
commandya no necesita más entradas. - hasta que esté seguro de que
commandya no produce más salidas. - hasta que
commandabandone, ya que sshd precisa decommandpara pasar el estado de salida a ssh.
3.12 - Después de actualizar a OpenSSH 3.1, el reenvío de X11 ya no funciona.
A partir de la versión 3.1 de OpenSSH, el servidor de reenvío de X11, ssh, está predeterminado para estar a la escucha en el anfitrión local; mire la opción X11UseLocalhost de sshd para invertirlo al comportamiento anterior si sus clientes de X11 más viejos no funcionan con la configuración predeterminada.
Por lo general, los clientes de X11 que usan X11 R6 deberían funcionar con la configuración predeterminada. Algunos distribuidores, incluido HP, incluyen las bibliotecas de R6 y R6 con los clientes de X11, por lo que algunos clientes funcionarán y otros no. Esto es lo que ocurre con HP-UX 11.X.
www@openbsd.org
Originally [OpenBSD: faq.html,v 1.55 ]
$Translation: faq.html,v 1.36 2003/10/07 15:13:53 horacio Exp $
$OpenBSD: faq.html,v 1.38 2003/10/07 20:01:28 horacio Exp $