![[OpenSSH]](../images/smalltitle.gif){kind=small}
OpenSSH es casi totalmente compatible con la versión comercial SSH 1.2.x. Sin embargo, hay unas cuantas excepciones que tendrá que recordar cuando actualice la versión comercial con OpenSSH, o cuando vaya a añadir OpenSSH a un sistema en el que no venga ya incluido por definición.
El cliente de OpenSSH usa puertos de baja numeración para la autenticación de rhosts y rhosts-rsa, debido a que el servidor necesita confiar en el nombre de usuario que dé el cliente.
Para prevenir que ssh use puertos de baja numeración, añanda
UsePrivilegedPort noa sus ficheros ssh_config o ~/.ssh/config, elimine el modo setuid del ejecutable de ssh o añada
-o "UsePrivilegedPort no"a su línea de órdenes de ssh o scp.
El cliente ssh necesita estar ligado a un puerto de baja numeración para la autenticación de rhosts y rhosts-rsa. Puede eliminar sin problemas el modo setuid del ejecutable de ssh si no va a usar estos métodos de autenticación.
Markus Friedl añadió a OpenSSH 2.3.0 el soporte para un servidor SFTP que implementa el protocolo SFTP utilizado por varios clientes comerciales de SSH. Para más información vea la opción Subsystem en la página de manual de sshd.
Las versiones 2.3 y anteriores de SSH contienen un error de diseño en su implementación de HMAC. Su código no proveía todos los datos del bloque desde el resumen ("digest"), y en lugar de eso proveía siempre 128 bits. A causa de esto, SSH 2.3 no podía interoperar con OpenSSH con resúmenes mayores.
OpenSSH 2.2.0 detecta el error de SSH 2.3. Las versiones venideras de SSH tendrán este error solucionado.
En modo SSH1, sólo se pueden seleccionar
3DES y Blowfish. En modo SSH2,
sólo se pueden seleccionar actualmente 3DES,
Blowfish, CAST128 ó
Arcfour. No hay soporte para el algoritmo
patentado IDEA. Esta diferencia se puede
manifestar cuando invoque la orden
ssh
y ésta se niegue a leer los ficheros de
configuración dejados por una instalación previa
de la versión comercial de SSH.
Solución:
Edite /etc/ssh/ssh_config y seleccione un opción
Cipher (esto es, un «algoritmo de
cifrado») diferente (3des o
blowfish).
Las versiones antiguas de SSH usaban un algoritmo patentado para cifrar /etc/ssh/ssh_host_key. Este problema se pone de manifiesto cuando sshd no puede leer la clave anfitriona ("host key").
Solución: Necesita ejecutar la versión comercial de ssh-keygen sobre la clave privada del anfitrión:
# ssh-keygen -u -f /etc/ssh/ssh_host_key
De este modo «actualizará» la clave a
3DES.
OpenSSH extiende el formato del fichero sshd_config de varias formas. En la actualidad hay un cambio incompatible con la versión comercial de SSH.
La versión comercial de SSH controlaba el ingreso en el sistema ("login") usando las directivas QuietMode y FascistLogging. OpenSSH introduce un juego de opciones de ingreso más general, SyslogFacility y LogLevel. Vea la página de manual de sshd para una información más detallada.
El programa ssh-keygen de la versión comercial
de SSH contenía un error por el que generaba
ocasionalmente claves RSA que tenían su
«Bit Más Significativo» (MSB, "Most
Significant Bit") desactivado. Este tipo de claves se
anunciaban como de tamaño completo, pero en realidad son
la mitad del tiempo, la mitad del tamaño que publican.
OpenSSH mostrará mensajes de aviso cuando se encuentre con claves de este tipo. Para evitar este mensaje, edite sus ficheros known_hosts y substituya el tamaño de clave incorrecto (generalmente "1024") por el tamaño correcto (generalmente "1023"). Sin embargo, como se ha dicho anteriormente, estas claves son menos seguras, por lo que es mejor generar unas nuevas.
La versión portable de OpenSSH generará fallos de autenticación falsos en cada ingreso, parecidos a:
"authentication failure; (uid=0) -> root for sshd service"Estos mensajes son debidos a que OpenSSH intenta primero determinar si un usuario necesita autenticación para el ingreso (v.g. una contraseña vacía). Desafortunadamente, a PAM le gusta guardar toda la información sobre sucesos de autenticación, incluido éste.
Si le molesta demasiado, configure PermitEmptyPasswords a "no" en sshd_config. De este modo silenciará el mensaje de error a cambio de desactivar los ingresos a las cuentas sin una contraseña activada. Si usa el fichero sshd_config modelo, ésta será la configuración por definición.
Para aceptar las contraseñas vacías con una versión de OpenSSH compilada con PAM, debe añadir el indicador nullock al final del módulo de comprobación de la contraseña en el fichero /etc/pam.d/sshd. Por ejemplo:
auth required/lib/security/pam_unix.so shadow nodelay nullokAdemás debe configurar PermitEmptyPasswords a "yes" en el fichero sshd_config.
Existe un problema al usar contraseñas vacías con autenticación PAM: PAM aceptará cualquier contraseña al autenticar una cuenta con una contraseña vacía. De este modo se carga la comprobación que usa sshd para determinar si una cuenta tiene o no configurada la contraseña y permite el acceso de los usuarios a la cuenta sin tener en cuenta la política especificada por PermitEmptyPasswords. Por este motivo, se recomienda que no añada la directiva nullok a su fichero de configuración de PAM, a menos que desee permitir el acceso con contraseñas vacías de forma específica.
Verifique sus ficheros ssh_config y sshd_config. Los ficheros de configuración predefinidos desactivan el agente de autenticación y el reenvío en X11.
Mandrake Linux 7.2 también modifica la variable de entorno XAUTHORITY en /etc/skel/.bashrc, y en consecuencia cualquier directorio de usuario de bash. Esto rompe el reenvío en X11 a menos que se desactive la línea: "export XAUTHORITY=$HOME/.Xauthority".
La biblioteca glibc que viene con Redhat 6.1 parece que tarda mucho tiempo en resolver direcciones "IPv6 ó IPv4" de los nombres de dominio. Esto se puede solventar con la opción de configuración --with-ipv4-default (los "lookups" de IPv6 se pueden hacer especificando la opción -6).
Selected cipher type idea not supported by server
Este error se genera cuando la versión comercial de ssh,
configurada para usar el algoritmo de cifrado 'idea', intenta
conectar a un servidor de OpenSSH. Para solucionar esto,
seleccione un algoritmo de cifrado diferente en
ssh_config o en ~/.ssh/config
(3des para seguridad o blowfish para
velocidad).
El núcleo de Linux busca (a través de 'modeprobe') la familia de protocolos 10 (IPv6). Cargue el módulo del núcleo apropiado, o bien introduzca el alias correcto en /etc/modules.conf, o bien desactive IPv6 en /etc/modules.conf.
Por alguna razón estúpida, el fichero /etc/modules.conf también se puede llamar /etc/conf.modules.
Enlace OpenSSH con libcrypt:
LIBS=-lcrypt ./configure [opciones]
Asegúrese de que sus bibliotecas OpenSSL hayan sido
compiladas para incluir soporte para RSA, bien de
forma interna o a través de RSAref.
scp se debe encontrar en el camino (PATH) predefinido, tanto en el cliente como en el servidor. Es posible que necesite usar la opción --with-default-path para especificar que busque un camino personalizado en el servidor. Esta opción substituye al camino predefinido, por lo que también debe especificar todos los directorios actuales en su camino, así como la ubicación de scp. Por ejemplo:
./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
Algunos sistemas operativos configuran /dev/tty con modos incorrectos, haciendo que la lectura de las contraseñas falle mostrando el siguiente error:
You have no controlling tty. Cannot read passphrase.La solución a esto es reconfigurar los permisos en /dev/tty al modo 0666 e informar sobre el error al distribuidor de su sistema operativo.
Si no existe el fichero 'configure' en el archivo tar.gz, lo puede bajar, y si make falla dando un mensaje de error "missing separator", es probable que se haya bajado la distribución de OpenSSH para OpenBSD y que esté intentando compilarlo en otra plataforma. Por favor, mire la información en la versión portable.
OpenSSH tiene soporte para los protocolos SSH1 y SSH2.
El protocolo SSH1 usa el algoritmo RSA, que estuvo sujeto a una patente en EE.UU., hasta el 21 de septiembre de 2.000. Fuera de los EE.UU., esos problemas no eran aplicables.
El protocolo SSH2 usa DH y DSA, otros dos algoritmos, que no se encuentran bajo ninguna patente. Si evita el uso del protocolo SSH1 y sólo usa el protocolo SSH2, no tiene porqué preocuparse. Sin embargo tendrá que encontrar clientes y servidores compatibles con SSH2 para sus otras máquinas. Para algunos usuarios esto puede representar un pequeño problema, ya que en este preciso instante no conocemos ningún cliente de SSH libre para Windows.
Pero como la patente sobre RSA ya ha caducado, no existen restricciones sobre el uso del software que utilice el algoritmo RSA, incluido OpenBSD.
www@openbsd.org