OpenSSH

Saltar a: navegación, buscar

OpenSSH (Open Secure Shell) es un conjunto de herramientas que proporcionan sesiones cifradas de comunicación en una red usando el protocolo SSH. Fue creado como alternativa abierta al software propietario Secure Shell. El proyecto es liderado por Theo de Raadt desde Calgary, Alberta.

Historia

OpenSSH fue creado por el equipo de OpenBSD como alternativa a SSH, que es software propietario. Los desarrolladores de OpenSSH reclaman que es más seguro que el original, debido a su política de producción de código limpia y auditada y el hecho, al que se refiere la palabra open en el nombre, de que está liberado bajo la licencia BSD de código abierto. Aunque el código fuente del SSH original está disponible, hay impuestas varias restricciones sobre su uso y distribución, lo que hace de OpenSSH un proyecto más atractivo para muchos desarrolladores.

OpenSSH aparece por primera vez en OpenBSD 2.6. OpenSSH 4.3 fue liberado el 1 de febrero de 2006 [1]Enlace en inglés.

Marca registrada

En febrero de 2001, Tatu Ylönen, presidente y CTO de SSH Communications Security informa en la lista de correo de OpenSSH, openssh-unix-dev@mindrot.org, que después de hablar con los desarrolladores clave de OpenSSH –Markus Friedl, Theo de Raadt, y Niels Provos– la compañía tendría que reclamar su propiedad sobre las marcas registradas SSH y Secure Shell para protegerlas. Tatu también pensaba cambiar las referencias al protocolo a algo como SecSH o secsh. Para poder mantener el control sobre el nombre, propuso cambiarlo a OpenSSH para evitar problemas legales. Theo de Raadt rechazó rotundamente cambiar el nombre del proyecto.

Al mismo tiempo, "SSH", "Secure Shell" y "ssh" se usaron en la documentación proponiendo el protocolo como un estándar abierto y esto fue supuesto así por mucha gente que la hacía, sin distinguir estos conceptos como las marcas registradas que eran. Tatu tuvo que renunciar a todos los derechos de exclusividad sobre estos nombres en cuanto al significado descrito en el protocolo. Esto es así porque en los Estados Unidos es obligatorio que las marcas se usen en copias publicitarias como adjetivos, nunca como nombres o verbos. El uso impropio de una marca registrada, o permitir a otros que usen una marca registrada incorrectamente, resulta en que la marca se convierta en un término genérico, como Kleenex o Aspirina, lo que abre la marca a su uso por otros, al dominio público.

También se pone en cuestión si el nombre "ssh" era una marca registrada, o se trataba sólo del logo (que usaba las letras minúsculas "ssh"). Muchos expertos creían todo esto, después de estudiar la base de datos de marcas USPTO y dudaban también de la validez de la reclamación, ya que transcurren nada menos que 6 años entre la creación de la compañía y el momento en que ésta empieza a reclamar su marca frente a alternativas libres como OpenSSH.

Se daba el caso que tanto desarrolladores de OpenSSH como el mismo Ylönen eran miembros del IETF, el grupo de trabajo que desarrollaba el nuevo estándar, que después de varias reuniones, deniega la propuesta de Ylonen para renombrar el protocolo, citando al respecto que éso sentaría un mal precedente para que otras marcas registradas reclamaran ante el IETF. Los participantes del grupo de trabajo sostuvieron que tanto Secure Shell como SSH eran términos genéricos y no marcas registradas.

Portabilidad

Debido a que OpenSSH es necesario para la autenticación, una característica interesante que tiene es que cuenta con implementaciones en distintos sistemas operativos, lo que requiere una infraestructura sustancial en cuanto a la portabilidad. Más que incluirlo directamente en OpenBSD, es desarrollado de forma separada como un añadido bajo el auspicio de el Equipo de Portabilidad de OpenSSH y liberado por lo que se conocen como "portable releases". Este modelo se usa igualmente en otros proyectos de OpenBSD, como OpenNTPD.

Componentes

La suite OpenSSH incluye las siguientes herramientas:

  • ssh, un sustituto para rlogin y telnet:
ssh user@example.com
  • scp (Secure Copy), un sustituto para rcp. Para copiar un archivo (o varios) de forma segura entre máquinas:
scp usuario@ejemplo.com:/ruta/remota/del/archivo /ruta/local/donde/copiarlo/
  • sftp (Secure File Transfer Program), un sustituto para ftp:
sftp usuario@ejemplo.com
  • sshd, el demonio SSH:
sshd

Túneles seguros

Reasignación de puertos

La mayoría de los programas hacen uso de conexiones TCP que pueden ser pasadas a través de un túnel seguro usando OpenSSH. También podemos hacer pasar múltiples conexiones TCP sobre una sola conexión ssh. Esto resulta práctico para disimular conexiones y cifrar protocolos que de otra manera serían inseguros, y para sortear cortafuegos. Las conexiones UDP pueden ser tuneladas en ciertas ocasiones con la ayuda de programas como netcat. Ejemplos de programas que se tunelan fácilmente son el X Window System, http usando un proxy y VNC. A menudo se crean túneles para X Window System entre dos sistemas Unix, para ejecutar cualquier aplicación gráfica de un sistema remoto, simplemente teclea su nombre:

ssh -Y usuario@maquinaremota
password:
$ xclock

Además, puede configurarse cierto software para automáticamente haga uso de OpenSSH para crear un túnel. Ejemplos de esto son DistCC, CVS, rsync, y fetchmail. Programas donde es posible hacer túneles aunque resulta complejo son ftp, que puede reemplazarse con sftp en todo caso, y SMB. En algunos sistemas operativos, pueden montarse sistemas de ficheros remotos sobre ssh usando shfsEnlace en inglés, lufsEnlace en inglés o podfukEnlace en inglés.

SOCKS

OpenSSH es capaz de crear un servidor proxy mediante SOCKS ad hoc para dar soporte de proxies de una forma más flexible de lo que es posible con un reasignación de puertos ordinario. Por ejemplo:

ssh -D1080 usuario@ejemplo.com

establece un servidor SOCKS local que escucha en "localhost:1080".

VPN basado en túneles

A partir de la versión 4.3, OpenSSH implementa túneles VPN en las capas 2/3 del modelo OSI. Esta es la más flexible de las capacidades para crear túneles de OpenSSH, ya que permite a las aplicaciones acceder a recursos de red remotos de forma transparente sin necesidad de sockets.

Autenticación

OpenSSH puede autenticar usuarios haciendo uso de sistemas que ya trae implementados:

Además, OpenSSH puede hacer uso también de métodos de autenticación disponibles en el sistema host. Esto incluye usar el sistema de autenticación BSD (bsd_auth) o PAM para habilitar la autenticación a través de métodos de autenticación única.

Las versiones de OpenSSH más antiguas que la 3.7 deben ser ejecutadas como root siempre que el soporte PAM esté activado, ya que se requieren permisos de root para activar el PAM. Las versiones más recientes de OpenSSH permiten desactivar el uso de PAM estando en ejecución. Mediante este sistema un usuario corriente puede ejecutar instancias de sshd.

Ver también

Enlaces externos