Historia

La primera versin del protocolo y el programa eran libres y los cre un finlands llamado Tatu Ylnen, pero su licencia fue cambiando y termin apareciendo la compaa SSH Communications Security, que lo ofreca gratuitamente para uso domstico y acadmico, pero exiga el pago a otras empresas. En 1999 se empez a escribir una versin que se convertira en la implementacin libre por excelencia, la de OpenBSD, llamada OpenSSH. El objetivo de la versin 1 del protocolo (SSH1), propuesta en 1995, era ofrecer una alternativa a las sesiones interactivas tales como Telnet, rsh, rlogin y rexec. Sin embargo, este protocolo tena un punto dbil que permita a los hackers introducir datos en los flujos cifrados. Por este motivo, en 1997 se propuso la versin 2 del protocolo (SSH2) como un anteproyecto del IETF (Fuerza de Tareas de Ingeniera de Internet).

Secure Shell
SSH, o "Secure Shell" es tanto una aplicacin como un protocolo, que permite conectar dos ordenadores a travs de una red, ejecutar comandos de manera remota y mover ficheros entre los mismos. SSH considera la red como un medio hostil en el que no se puede confiar. Un atacante, podr forzar a que SSH se desconecte, pero no podr descifrar o reproducir el trfico, o introducirse en la conexin. El puerto por defecto para el servidor es el 22.

Aplicaciones
Proporciona autentificacin fuerte y comunicaciones seguras sobre canales no seguros y pretende ser un reemplazo seguro para aplicaciones tradicionales no seguras, como telnet, rlogin, rsh y rcp. Su versin 2 (SSH2) proporciona tambin sftp, un reemplazo seguro para FTP. SSH permite establecer conexiones seguras a servidores XWindows, realizar conexiones TCP seguras y realizar acciones como sincronizacin de sistemas de ficheros (rsync) y copias de seguridad por red de manera segura. SSH permite, adems, solventar problemas de seguridad que pueden derivarse del hecho de que usuarios tengan acceso como root a ordenadores de la red, o acceso al cable de comunicaciones, de modo que podran interceptar contraseas que se transmiten por la red. Esto no puede ocurrir con SSH, ya que SSH nunca enva texto plano, sino que la informacin siempre viaja cifrada. 1 Servicios de Red Adrin Martinez

Versiones
Existen dos versiones, SSH1 y SSH2 (SSH2 soluciona problemas de seguridad de SSH1). SSH1 tiene fallos estructurales que le hacen vulnerable a ciertos tipos de ataques. SSH1 puede sufrir un ataque del tipo "Man In The Middle" (intercepcin de las claves pblicas en el intercambio de las mismas). SSH1 est soportado en ms plataformas que SSH2. SSH1 permite autentificacin de tipo .rhosts (propuesta en SSH2) SSH1 permite mtodos de autentificacin ms diversos (AFS, Kerberos, etc.). SSH1 tiene mejor rendimiento que SSH2.

Version SSH1
Algoritmos
SSH, dependiendo de su versin utiliza diferentes algoritmos de cifrado: SSH1: DES, 3DES, IDEA, Blowfish SSH2: 3DES, Blowfish, Twofish, Arcfour, Cast128-cbc El cifrado utilizado para cuestiones de autentificacin utiliza RSA para SSH1 y DSA para SSH2.

Autentificacin
SSH permite autentificarse utilizando uno o varios de los siguientes mtodos: Password. Sistema de clave pblica. Kerberos (SSH1). Basado en el cliente (por relaciones de confianza en SSH1 y sistema de clave pblica en SSH2).

Ataques que previene

IP Spoofing: un ordenador trata de hacerse pasar por otro ordenador (en el que confiamos) y nos enva paquetes "procedentes" del mismo. SSH es incluso capaz de proteger el sistema contra un ordenador de la propia red que se hace pasar por el router de conexin con el exterior. Enrutamiento de la IP de origen: un ordenador puede cambiar la IP de un paquete procedente de otro, para que parezca que viene desde un ordenador en el que se confa. DNS spoofing: un atacante compromete los registros del servicio de nombres. Intercepcin de passwords y datos a travs de la red. Manipulacin de los datos en ordenadores intermediarios. Ataques basados en escuchar autentificacin contra servidores XWindows remotos. 2 Servicios de Red Adrin Martinez

Nota: Hay que tener en cuenta que SSH no sirve de nada si el atacante consigue hacerse con el control de la mquina como root, ya que podr hacer que SSH quede inutilizado. Si algn atacante tiene acceso al directorio "home" de un usuario de la mquina, la seguridad es ya inexistente.

Arquitectura
El software se compone de un programa servidor en una mquina servidora, y un programa cliente en la mquina cliente (junto con algunos programas auxiliares). Las mquinas se conectan a travs de una red IP no segura.

Proceso
1. La conexin siempre se inicia por parte del cliente. El servidor est escuchando un puerto determinado, esperando la conexin, y puede atender a varios clientes. 2. Cuando el cliente se conecta al servidor, el servidor acepta la conexin y responde enviando su identificacin de versin, a lo que el cliente responde enviando la suya. Esta informacin valida que la conexin se realiz en el puerto correcto, establece la versin del protocolo utilizada, y la versin del software utilizada por cada uno de ellos. Esta informacin no se enva cifrada, y es perfectamente legible. Si cualquier lado de la conexin no acepta o no entiende esta informacin, se cierra la conexin. 3. Una vez ha terminado la fase de identificacin, ambos lados comienzan una transmisin segn un protocolo binario. 4. El servidor enva su clave de equipo (la clave RSA del propio equipo), la clave del servidor (una clave RSA generada cada hora), y otras informaciones al cliente. 5. El cliente genera una clave de sesin de 256 bits, la cifra utilizando ambas claves RSA y enva la clave cifrada, junto con el tipo de cifrado seleccionado al servidor. 6. Ambos lados comienzan ahora a enviar datos cifrados mediante la clave generada y el algoritmo seleccionado. El servidor enva un mensaje de confirmacin cifrado al cliente. 7. Tras eso, el cliente se autentifica utilizando uno de los mtodos de autentificacin soportados. 8. Tras una correcta autentificacin, el cliente enva una serie de peticiones para comenzar la sesin, como establecer una sesin de consola remota o de un puerto TCP/IP, ejecutar un comando, etc. 9. Al ejecutar una consola o un comando, la sesin entra en modo interactivo. En este modo, se envan datos en ambos sentidos, pueden abrirse nuevas conexiones, etc.

Formato de paquetes
Tras el envo de los strings de identificacin, ambas partes envan paquetes con el siguiente formato: Tamao del paquete: 32 bits. Es el tamao del paquete, sin incluir el campo tamao, y el relleno. El mximo es de 262144 bytes. Relleno: 1 - 8 bytes de datos aleatorios (o ceros si no se utiliza cifrado). El tamao del relleno es de (8 - (tamao % 8)) bytes. El hecho de que este relleno sea aleatorio dificulta los ataques.

3 Servicios de Red Adrin Martinez

Tipo de paquete: 8 bits. El valor 255 est reservado para futuras ampliaciones. Datos: con un tamao igual al valor del campo "tamao" menos 5. Bytes de chequeo: CRC con el polinomio 0xedb88320 del relleno, tipo de paquete y datos. Se calcula antes del cifrado.

La longitud de la parte cifrada (relleno + tipo + datos + chequeo) es siempre mltiplo de 8 bytes.

Compresin de paquetes
El tipo de paquete y los datos se comprimen utilizando el algoritmo gzip. En este caso, el tamao del paquete indica el tamao de los datos comprimidos, ms 4 para el CRC. El relleno se calcula segn los datos comprimidos, para que los datos cifrados sean mltiplo de 8 bytes.

Version SSH2
SSH2 es un protocolo que permite servicios de red y conexiones seguras sobre una red insegura. Consta de tres componentes: Capa de protocolo de transporte: proporciona autentificacin del servidor, confidencialidad e integridad y, opcionalmente, compresin. Generalmente se ejecutar sobre una conexin TCP/IP. Capa de protocolo de autentificacin: autentifica al cliente contra el servidor. Se ejecuta sobre la capa del protocolo de transporte. Capa del protocolo de conexin: multiplexa el canal cifrado en mltiples canales lgicos. Se ejecuta sobre la capa de enlace.

El cliente enva una peticin de servicio una vez que se ha establecido una conexin segura en la capa de transporte, y una segunda peticin tras la autentificacin del usuario. El protocolo de conexin proporciona canales que pueden utilizarse para diferentes propsitos, como abrir sesiones interactivas, redireccionar puertos TCP/IP (tunneling) y conexiones X11.

Arquitectura
Claves de equipo
Cada servidor debera de tener una clave de equipo. Es posible tener varias, con distintos algoritmos, e incluso varios equipos pueden compartir la misma clave. Si un equipo tiene claves, al menos debe de tener una clave utilizando el algoritmo obligatorio (DSS). La clave se utiliza para verificar que el cliente est conectado al servidor correcto, para lo que el cliente debe conocer de antemano la clave pblica del servidor.

4 Servicios de Red Adrin Martinez

Existen dos modelos: 1. El cliente tiene una base de datos que asocia servidores con sus correspondientes claves pblicas. 2. Las asociaciones vienen dadas por una autoridad de certificacin.

Extensibilidad
El protocolo est diseado de manera que pueda resultar fcilmente extensible, aadiendo nuevos algoritmos, protocolos, etc.

Propiedades de seguridad
Los algoritmos de integridad, cifrado y clave pblica utilizados son conocidos y ampliamente probados. Los algoritmos utilizan claves lo suficientemente largas como para resistir durante dcadas los ms fuertes ataques de criptoanlisis. Como los algoritmos se negocian, si uno se ve comprometido es posible negociar el uso de otro sin cambiar el protocolo.

Establecimiento de la conexin
Puerto
Sobre TCP/IP, el servidor generalmente escucha conexiones en el puerto 22.

Versin del protocolo

Cuando se establece la conexin, ambos lados deben enviar un string de identificacin con el formato:

"SSH-versin_protocolo-versin_software comentarios\r\n"

Formato de los paquetes

Cada paquete tiene el siguiente formato:

uint32 byte byte[n1] byte[n2] byte[m]

tamao paquete tamao relleno datos; n1 = tamao paquete - tamao relleno 1 relleno aleatorio; n2 = tamao relleno mac (message authentication code); m = tamao_mac

Tamao del paquete: el tamao del paquete sin incluir el campo MAC ni el propio campo tamao. Tamao del relleno: el tamao del relleno datos: los datos tiles del paquete. Si la compresin est activada, est comprimido. Inicialmente, la compresin debe de estar desactivada ("NONE").

5 Servicios de Red Adrin Martinez

 Relleno aleatorio: relleno para que el tamao de todo el paquete, excepto el campo mac, tenga un tamao mltiplo de 8, o el tamao del bloque de cifrado, lo que sea mayor. Tiene que tener, como mnimo, 4 bytes, y cmo mximo 255. mac: bytes para la autentificacin del mensaje. El tamao mnimo del paquete es 16 bytes, y el tamao mximo del paquete debe de poder enviar 32768 bytes de datos sin comprimir, con un tamao total del paquete de 35000 bytes.

Compresin
Si se ha negociado la compresin, el campo de datos estar comprimido segn el algoritmo negociado. El campo del tamao y la MAC se calcularn segn los datos comprimidos. El cifrado se realizar tras la compresin. La compresin debe de poder negociarse independientemente para cada sentido de la transmisin. Es obligatorio no soportar compresin, y opcional soportar compresin con el algoritmo "zlib".

Cifrado
El algoritmo de cifrado se negociar durante el intercambio de claves. Los campos cifrados sern: tamao del paquete, tamao del relleno, datos y relleno. Los datos enviados en una direccin deberan de ser tratados como un flujo continuo de datos, y las claves de los algoritmos deberan tener, al menos 128 bits. Los algoritmos pueden ser diferentes en cada direccin de la comunicacin. El nico algoritmo requerido es el 3des-cbc. Es tambin posible especificar que el trfico no sea cifrado, con lo que se perdera la confidencialidad.

Integridad de los datos

En cada paquete se introduce un cdigo de autentificacin de mensaje (MAC) calculado a partir de una clave compartida por el cliente y el servidor, el nmero de secuencia del paquete, y el contenido del mismo. El nico algoritmo que ha de implementarse de manera obligatoria es el algoritmo hmac-sha1.

Intercambio de claves
Especifican cmo se generan las claves de sesin, y cmo se autentifica el servidor. El nico algoritmo obligatorio es el Diffie-Hellman. El intercambio produce dos valores: una clave secreta K, y un valor de intercambio H. El valor H del primer intercambio de claves es tambin el identificativo de sesin, y se genera a partir de una funcin HASH.

6 Servicios de Red Adrin Martinez

El intercambio de claves termina con el envo de un comando SSH_MSG_NEWKEYS. Este mensaje se enva utilizando las claves y algoritmos que se utilizaban hasta ese Tras su envo, todos los dems paquetes que se enven lo harn con estas nuevas claves y algoritmos. En el caso del intercambio de claves Diffie-Hellman, se calcula una clave secreta, compartida por ambos equipos, que no puede determinarse sino es por colaboracin de ambos. El intercambio de claves se combina con una firma utilizando la clave del host del servidor para autentificar a ste.

Autentificacin
Todas las peticiones de autentificacin deben de tener el siguiente formato:
byte string string string datos cdigo de comando (SSH_MSG_USERAUTH_REQUEST) nombre de usuario nombre del servicio mtodo de autentificacin dependientes del mtodo

Si el servidor rechaza la peticin, enviar un mensaje de fallo con los mtodos de autentificacin portados. En caso de que la autentificacin se acepte, se enviar un mensaje indicndolo. Si la autentificacin consta de varios pasos, se responder a cada paso individual con un mensaje de fallo, que contendr un campo "xito parcial" a verdadero.

Mtodo de autentificacin none

Este mtodo no debera estar activo para ningn usuario, pero en ciertos casos puede estarlo. El cliente puede solicitarlo, para recibir un mensaje de fallo con todos los mtodos permitidos. Si el servidor est configurado para aceptar el mtodo "none" desde ese cliente, deber enviar un mensaje de xito. En caso contrario, un mensaje de fallo con los mtodos aceptados, que no deben incluir nunca el mtodo "none" (aunque se acepte).

Mensaje de aviso
En ciertas jurisdicciones, puede ser necesario enviar un mensaje de aviso al comenzar la sesin para obtener asistencia legal. Este protocolo permite al servidor enviar un mensaje (como en sistemas UNIX) al cliente, para que este lo muestre, tras cualquier autentificacin que se haya llevado a cabo con xito.

Mtodo de autentificacin por clave publica

Es el nico mtodo requerido en todas las implementaciones. Con ste mtodo, la autentificacin se prueba si se posee una clave privada. Se enva una firma creada con la clave privada del usuario. El servidor comprueba que la clave es vlida para el usuario, y que la firma tambin es vlida. 7 Servicios de Red Adrin Martinez

Este es el proceso: 1. El cliente enva al servidor la peticin de autentificacin con su clave pblica. Si el servidor no acepta el mtodo, enva un mensaje de fallo. En caso contrario, enva un mensaje de aceptacin del mtodo pedido. 2. Si se acepta, el cliente enviar un nuevo paquete de peticin de autentificacin de clave pblica, pero incluyendo una firma creada con su clave privada, que firma todos los dems campos del mensaje, incluyendo el identificativo de sesin como campo firmado. 3. Cuando el servidor recibe este mensaje, comprueba que la clave proporcionada es correcta, y si lo es, comprueba tambin la firma. El servidor entonces responder con un mensaje de xito o fallo. En el ordenador cliente, es necesario crear un par de claves pblica/privada (utilizando ssh-keygen), y copiar la parte pblica en el directorio $HOME/.ssh2/ del servidor. Una vez hecho esto, es necesario incluir la siguiente lnea en el fichero $HOME/.ssh/authorization del servidor: key id_dsa_1024_a.pub # nombre_del_fichero_con_la_clave_pblica y en el fichero $HOME/.ssh/identification del servidor: idkey id_dsa_1024_a # nombre_del_fichero_con_la_clave_privada

Mtodo de autentificacin por password

El cliente enva un mensaje de autentificacin con su password, con el formato:
byte string string string boolean string SSH_MSG_USERAUTH_REQUEST user name service "password" FALSE plaintext password

Generalmente, el servidor responder con xito o fallo, pero en el caso de que el password haya caducado, enviar el siguiente mensaje:
byte string string SSH_MSG_USERAUTH_PASSWD_CHANGEREQ prompt language tag

En este caso, el cliente puede continuar con un mtodo de autentificacin diferente, o pedir un nuevo password al usuario y volver a intentarlo, con el siguiente mensaje:
byte string string string boolean string string SSH_MSG_USERAUTH_REQUEST user name service "password" TRUE plaintext old password plaintext new password

8 Servicios de Red Adrin Martinez

Utilizacion de SSH
SSH1
Para abrir esta sesin con el mismo usuario con el que estamos conectados a nuestro ordenador local: $ ssh ordenador.remoto.org Para utilizar un nombre de usuario diferente: $ ssh -l nombreusuario ordenador.remoto.org Utilizar SSH1 para enviar un comando a otro ordenador, de manera segura: $ ssh ordenador.remoto.org comando Tambin es posible especificar el tipo de cifrado, activar la compresin en la transmisin de datos, definir la localizacin de los ficheros de configuracin, reenviar comandos, y muchas otras utilidades. Por ejemplo, para utilizar ssh sin cifrado (no se recomienda) podramos utilizar: $ ssh -o cipher=none ordenador.remoto.org

SSHD1
Este comando permite activar el daemon SSH1 en el ordenador, y generalmente es ejecutado por el usuario "root": $ sshd Este comando puede recibir multitud de parmetros, para definir ficheros de configuracin, puerto por defecto, etc.

SSH-AGENT1
Este comando permite cargar las claves pblicas en memoria, para que puedan ser utilizadas. De modo que todos los programas que se ejecuten utilicen de manera automtica el agente para autentificarse mediante RSA a los ordenadores remotos usando SSH. Su uso es muy sencillo, aunque admite parmetros: $ ssh-agent

SSH2
El comando ssh2 es muy similar al comando ssh de SSH1, pero con opciones adicionales, como activar el forwarding de la autentificacin o el trfico de XWindows. $ ssh2 remote.example.org

SSHD2
Similar al comando sshd, arranca el daemon de SSH2. Permite especificar parmetros de funcionamiento. Lo ms habitual es ejecutarlo como el usuario "root". $ sshd2

9 Servicios de Red Adrin Martinez

SSH-AGENT2
Su utilizacin es similar a la utilizacin de ssh-agent1 en SSH1: $ ssh-agent2

SSH-ADD2
Permite gestionar las identidades del agente SSH2. $ ssh-add2 identidad

SFTP2
Este comando permite realizar transacciones ftp de manera segura, cifrando tanto la conexin de datos como la conexin de control. $ sftp servidor_remoto usuario El servidor remoto tiene que estar ejecutando el daemon sshd2.

Configuracin de OpenSSH
Archivo sshd_config En este archivo se describe la configuracin del servidor SSH. Las opciones ms relevantes: Port: Esta opcin permite especificar el puerto TCP que utilizar el servidor. El valor usual es 22. Protocol: Versin del protocolo a utilizar. Usaremos solamente el valor 2. HostKey: Clave privada de RSA o DSA del host. Normalmente las claves de host son generadas en el momento de la instalacin de OpenSSH, y el valor de esta opcin es /etc/ssh/ssh_host_rsa_key. PubkeyAuthentication: Si el valor de esta opcin es yes, entonces se permite la autenticacin de usuarios mediante clave pblica. AuthorizedKeysFile: Mediante esta opcin se indica al servidor en donde estn almacenadas las claves pblicas de los usuarios. El valor por defecto es %h/.ssh/authorized_keys, e indica que deben buscarse en el archivo authorized_keys, del directorio .ssh dentro del directorio home de cada usuario. PasswordAuthentication: Si el valor de esta opcin es yes, se permite la autenticacin de usuarios mediante contraseas. X11Forwarding: Si el valor de esta opcin es yes, se habilita el reenvo de X11 a travs de la conexin SSH.

10 Servicios de Red Adrin Martinez

Archivo ssh_config En este archivo se describe la configuracin del cliente SSH. Las opciones ms importantes son: Host: Esta opcin acta como un divisor de seccin. Puede repetirse varias veces en el archivo de configuracin. Su valor, que puede ser una lista de patrones, determina que las opciones siguientes sean aplicadas a las conexiones realizadas a los hosts en cuestin. Port: Es el puerto de TCP que utiliza el servidor (normalmente, 22). Protocol: Es la versin del protocolo utilizada (normalmente 2,1, pero se recomienda solamente 2). PubkeyAuthentication: Autenticacin mediante clave pblica (se recomienda yes). IdentityFile: Archivo que contiene la clave pblica (en caso de usar RSA, lo usual es ~/.ssh/id_rsa). PasswordAuthentication: Autenticacin mediante contraseas (yes o no). StrictHostKeyChecking: Define que har el cliente al conectarse a un host del cual no se dispone de su clave pblica. El valor no hace que sea rechazara la clave del servidor (y por lo tanto, se aborte la conexin), el valor yes hace que se acepte automticamente la clave recibida, y el valor ask hace que se pida confirmacin al usuario. Ciphers: Algoritmos de cifrado simtrico soportados para su uso durante la sesin. ForwardX11: Reenvo de aplicaciones X11 (los posibles valores son yes o no).

Otras aplicaciones de SSH

Usar SSH tras un firewall
Para poder utilizar SSH tras un firewall, tan slo es necesario tener abierto un puerto en el firewall, y hacer que el daemon remoto SSH escuche el trfico de ese puerto. Por defecto se utiliza el puerto 22 (estndar de SSH) pero puede utilizarse cualquier otro puerto que est permitido por el firewall. Para ello, en el servidor, tan slo es necesario arrancar el daemon SSH en el puerto deseado: # sshd -p 443 Y establecer la conexin desde el cliente abriendo una conexin a ese puerto: $ ssh -p 443 host.remoto.org 11 Servicios de Red Adrin Martinez

Tunneling con SSH

El tunneling con SSH permite enviar datos basados en protocolos no seguros a travs de un canal SSH seguro. De este modo, protocolos como POP3, o FTP pueden utilizarse sin peligro de que datos como los passwords sean enviados como texto plano, e interceptados a travs de la red. En cada uno de los extremos del tnel estn las aplicaciones estndar (un demonio POP3 estndar, nuestro cliente de correo favorito...) y la comunicacin se asegura haciendo uso de toda la potencia criptogrfica de SSH.

Mediante SSH se produce un reenvo de los datos gracias a una tcnica denominada "portforwarding". SSH recoge los datos que el cliente quiere enviar y los reenva por el tnel o canal seguro, al otro lado del tnel se recogen los datos y se reenvan al servidor conveniente.

Utilizando los comandos proporcionados por la implementacin libre OpenSSH, la manera de hacer esto sera la siguiente: Si queremos utilizar el puerto 1110 para crear una conexin segura al puerto 110 de una mquina remota, haremos: $ ssh -P -L 1110:popmail.correo.net:110

Implementaciones Windows
Los siguientes implementaciones "libres de SSH que se recomiendan para interoperar con OpenSSH desde sistemas Windows:

PuTTY es una implementacin de SSH1 + SSH2. Aade PSCP, un simil a scp, programa al estilo de Windows. PuTTY est disponible bajo la licencia MIT (BSD). PuTTY es una implementacin libre de Telnet y SSH para plataformas Win32, escrito y mantenido principalmente por Simon Tatham, que vive en Gran Bretaa.

TTSSH (SSH1) es una implementacin slo para SSH1, de Robert O'Callahan. "TTSSH es un cliente SSH gratuito para Windows. Est implementado como una extensin DLL para Teraterm Pro. Teraterm Pro es un excelente emulador 12 Adrin Martinez

Servicios de Red

de terminal libre / Telnet cliente para Windows, y su codigo fuente est disponible. TTSSH aade capacidades SSH para Pro Teraterm sin sacrificar cualquiera de las funcionalidades existentes. TTSSH tambin es gratuito para descargar y usar, y su cdigo fuente est disponible tambin con una licencia de cdigo abierto. Adems, TTSSH ha sido desarrollado ntegramente en Australia".

Referencias
Garaizar Sagarminaga, Pablo. SSH Tunneling. http://130.206.100.150/docs/articulo.ssh.html, 2004 Secure Shell FAQ, http://www.ayahuasca.net/ssh/, 2004 Marn Illera, lvaro. OpenSSH, http://www.eghost. deusto.es/docs/TutorialOpenSSH.html, 2004 T. Ylonen. The SSH (Secure Shell) Remote Login Protocol, http://www.snailbook.com/docs/protocol-1.5.txt, 1995 T. Ylonen. SSH Protocol Architecture, http://www.snailbook.com/docs/architecture.txt, 2003 T. Ylonen. SSH Transport Layer Protocol, http://www.snailbook.com/docs/transport.txt, 2003 T. Ylonen. SSH Authentication Protocol, http://www.snailbook.com/docs/userauth.txt, 2002 T. Ylonen. SSH Connection Protocol, http://www.snailbook.com/docs/connection.txt, 2003 SSH, http://es.wikipedia.org/wiki/SSH, 2004 (Bitvise) SSH Port http://www.openssh.com/windows.html

13 Servicios de Red Adrin Martinez