SSH

Secure Shell, tambin llamado SSH, es un

protocolo utilizado para login y ejecucin de
procesos remotos [1].

PROCESO REMOTO: Aquel que se
ejecuta en otra mquina que no es
donde est la terminal.

Entre otras cosas, SSH permite:
Iniciar sesiones (login) en servidores
remotos.
Ejecutar comandos remotamente.
Copiar archivos entre distintos hosts
[1].

SSH no es solo un reemplazo de telnet,
rlogin, rexec, ftp, XDMCP y otros. Adems de
brindar todas estas posibilidades con,
bsicamente, un nico programa, brinda
comunicaciones seguras (cifradas) entre el
cliente y el servidor [1].

Siempre que los datos se envan por un
ordenador a la red, SSH encripta los datos
automticamente (codifica el mensaje).
Entonces, cuando los datos llegan a su
destinatario, SSH descifra automticamente
(decodifica) el mensaje. El resultado es la
encriptacin transparente: los usuarios
pueden trabajar con normalidad, sin darse
cuenta de que sus comunicaciones estn
codificadas de manera segura en la red [2].


CONEXIN

Al conectarse un cliente de SSH con el
servidor, se realizan los siguientes pasos [3],
[4]:

1. El cliente abre una conexin TCP al
puerto 22 del host servidor.
2. El cliente y el servidor acuerdan la
versin del protocolo a utilizar, de
acuerdo a su configuracin y
capacidades.
3. El servidor posee un par de claves
pblica/privada de RSA (llamadas
claves de host. El servidor enva al
cliente su clave pblica.
4. El cliente compara la clave pblica
de host recibida con la que tiene
almacenada, para verificar su
autenticidad. Si no la conociera
previamente, pide confirmacin al
usuario para aceptarla como vlida.
5. El cliente genera una clave de sesin
aleatoria y selecciona un algoritmo
de cifrado simtrico.
6. El cliente enva un mensaje
conteniendo la clave de sesin y el
algoritmo seleccionado, cifrado con
la clave pblica de host del servidor
usando el algoritmo RSA.


PROTOCOLOS ASEGURADOS POR SSH

SSH es un protocolo que permite establecer
un canal seguro entre el el equipo local y un
equipo remoto. Sirve como un canal
fundamental para los protocolos asociados,
tales como Secure Shell, SFTP o SCP. Si
bien es posible ejecutar (ligeramente
modificado) el viejo y simple protocolo FTP
sobre SSH, por suerte, esto no es muy
comn. La transferencia de archivos a travs
de SSH casi siempre se realiza utilizando
SFTP o SCP.

1. SFTP: es un protocolo de transferencia
de archivos que utiliza SSH para
asegurar los comandos y los datos que
se transfieren entre el cliente y el
servidor. Los datos transferidos con FTP
estndar no estn cifrados, lo que los
hace vulnerables a escuchas furtivas,
interferencias o falsificaciones [5].

Con SFTP, los datos transferidos entre el
cliente y el servidor estn cifrados, lo que
evita que usuarios no autorizados tengan
acceso a ellos. Es recomendable usar
SFTP cuando se necesite transferir datos
confidenciales o de carcter crtico entre
un cliente y un servidor configurado para
usar SSH en transferencias seguras [5].

Existen dos componentes bsicos para la
transferencia de archivos SFTP;
validacin del servidor y autenticacin del
cliente. Estos dos componentes usan
claves pblicas y privadas para
autenticar la comunicacin entre el
cliente y el servidor. Se valida el servidor
comparando su clave pblica con las
claves pblicas almacenadas en el
equipo cliente. La clave pblica del
servidor est habitualmente almacenada
en un archivo llamado "known_hosts" en
el servidor, y la clave pblica del cliente
est almacenada en un archivo cifrado
en el equipo local [5].

En conclusin, tiene varias ventajas:
1.1. Es seguro, utilizando un canal
protegido SSH para la transferencia
de datos.
1.2. Mltiples comandos para la copia de
archivos y la manipulacin pueden
ser invocados en una sola sesin
sftp, mientras scp abre una nueva
sesin cada vez que se invoca.

En aplicaciones de software que
ejecutan un cliente FTP en el fondo,
se puede intentar sustituir sftp,
asegurando as las transferencias
de archivos de esa aplicacin.
Puede que tenga que ejecutar un
agente, sin embargo, los programas
que normalmente invocan ftp
podran no reconocer el smbolo
contrasea sftp, o se puede esperar
a que haya suprimido solicitud de
contrasea de FTP (utilizando un
archivo .netrc, por ejemplo) [2].

2. SCP: El comando scp es conveniente y
til, pero muchos usuarios ya estn
familiarizados con FTP (File Transfer
Protocol), una tcnica ms ampliamente
utilizado para la transferencia de archivos
a travs de Internet [2].

SCP ha sido reemplazado en su mayora
por el protocolo SFTP ms completo [6].

Permite copiar ficheros entre dos
mquinas. Utiliza ssh para la transmisin
de la informacin, por lo que ofrece la
misma seguridad que el ssh. De la
misma manera utiliza los mtodos de
autenticacin de ssh. Este comando
reemplaza al rcp, ftp [7].


LOGIN

1. SSH admite el inicio de sesin sin login y
contrasea, al hacer uso de ssh-agent,
que es un programa que almacena en
cach las claves privadas. Es decir, al
escribirse la contrasea una sola vez la
clave privada luego es almacenada en la
memoria por el agente. Mientras dure la
sesin, los clientes de SSH entran en
contacto automticamente con el agente
para todas las operaciones a realizar [8].

Su inseguridad radica en que podra
permitir a un usuario
malintencionado/pirata informtico en el
mismo host local iniciar una sesin en un
servidor remoto como el usuario que
utiliza ssh, teniendo la posibilidad de
estar ejecutndose como superusuario o
root, y llevar a cabo la comprobacin de
permisos suficientes, que luego puede
incorrectamente acceder a servicios o
programas en una mquina host [2].

2. PermitRootLogin: es la opcin que
permite iniciar sesin remotamente
utilizando la cuenta de root. Es una
prctica absolutamente desaconsejable,
ya que toda mquina Unix o Linux tiene
un usuario root, y a nuestro atacante ya
no le hara falta obtener un nombre de
usuario, slo la contrasea.

No obstante, el inicio de sesin basado en
Clave se considera mucho ms seguro que
los inicios de sesin basados en
contraseas, pues cuando se mira desde la
perspectiva de un intento de fuerza bruta
para acceder desde otro sistema: las
posibilidades para romper una clave son
prcticamente nulas, mientras que las malas
contraseas son demasiado comunes [9].


VULNERABILIDADES

1. Existe una vulnerabilidad que puede ser
explotada en forma remota, en las
versiones anteriores a la 3.7.1 de
OpenSSH. Esto puede permitir que un
usuario malicioso pueda provocar un
desbordamiento de bfer, provocando un
ataque de denegacin de servicio (DoS),
e incluso la ejecucin arbitraria de cdigo
[10].

Si bien no se han aportado detalles
definidos de los mecanismos que
producen el desbordamiento de bfer, el
resultado del ataque a un sistema
vulnerable puede comprometer
seriamente su seguridad. Aunque se
tiene que la vulnerabilidad est
solucionada en la versin 3.7.1 de
OpenSSH, por lo que se sugiere la
inmediata actualizacin del producto [10].

Otra alternativa de mitigacin es
realizando la caracterstica de separacin
de privilegios (privesep) disponible en
OpenSSH, para disminuir el impacto de
esta accin, esto se logra creando un
usuario /privsep/ que utilice un entorno
protegido /chroot/ y agregando la
siguiente lnea al archivo
//etc/ssh/sshd_config/:
UsePrivilegeSeparation yes

Esto no est disponible en todos los
casos, y solo sirve para minimizar la
accin de un intruso que se aproveche
de la falla, no para evitarla [10].

2. Existe tambien una vulnerabilidad al
ataque Man-in-the-middle. Hay tres
casos de ataques man-in-the-middle a
considerar. La primera es cuando un
atacante coloca un dispositivo entre el
cliente y el servidor antes de que la
sesin se inicie [3].

En ese caso, el usuario debe dar una
advertencia de que la clave de host
ofrecido no coincide con la clave de host
almacenada en su cach de cliente. No
obstante, el usuario puede tener la
libertad de aceptar el nuevo y continuar
la sesin. Se RECOMIENDA que la
advertencia proporciona informacin
suficiente para que el usuario del
dispositivo cliente pueda tomar una
decisin informada [3].

El segundo caso que se debe considerar
es similar a la primera,en el que tambin
se produce en el momento de la
conexin, pero en este caso el cliente no
sabe si est hablando con el servidor
deseado [3].

Debido a que el protocolo es extensible,
futuras extensiones del protocolo pueden
ofrecer mejores mecanismos para hacer
frente a la necesidad de conocer la clave
de host del servidor antes de conectarse
[3].

En el tercer caso-man-in-the-middle, los
atacantes pueden intentar manipular
paquetes en trnsito entre los
compaeros despus de que la sesin
se ha establecido [3].

Para evitar esto, se recomienda
implementar algoritmos MAC
comnmente aceptados, y se anima a los
administradores participar de la literatura
y las discusiones de la criptografa actual
para asegurarse de que no estn
utilizando un algoritmo de MAC que
contenga una vulnerabilidad o debilidad
recientemente encontrada [3].


BIBLIOGRAFA

[1] J. Smaldone, Introduccin a Secure
Shell, vol. 0.2, pp. 115, 20-Jan-2004
[Online]. Available:
http://es.tldp.org/Tutoriales/doc-ssh-
intro/introduccion_ssh-0.2.pdf
[2] D. J. Barrett, R. E. Silverman, and R.
G. Byrnes, SSH, The Secure Shell:
The Definitive Guide - 2nd Edition,
OREILLY. United States of America:
Safari, 2005, pp. 1668 [Online].
Available:
http://bin.sc/Readings/Programming/S
SH_Second_Edition.pdf
[3] SSH Communications Security
Corporation and The Internet Society,
The Secure Shell (SSH) Protocol
Architecture. pp. 129, 2006 [Online].
Available:
http://www.ietf.org/rfc/rfc4251.txt
[4] S. M. Bellovin, E. Androulaki, and I.
Muqattash, Secure Shell: SSH,
Columbia University, Columbia, 2006
[Online]. Available:
https://www.cs.columbia.edu/~smb/cla
sses/f06/l12.pdf
[5] Rocket Sotware, Transferencia de
Archivos Asegurada con SSH por
SFTP, PASSPORT Terminal
Emulation, 2013. [Online]. Available:
http://www.zephyrcorp.com/es/transfer
encia-archivos-asegurada-ssh.htm
[6] REBEX, Communication protocols.
[Online]. Available:
https://www.rebex.net/kb/secure-
ftp/default.aspx
[7] Universitat Jaume, Comandos
bsicos de ssh. [Online]. Available:
http://www3.uji.es/~galdu/ssh_vs_rsh/
x165.html
[8] SARA TM, SSH Agent
Vulnerabilities, 2010. [Online].
Available: http://www-
arc.com/sara/cve/SSH_vulnerabilities.
html
[9] Are passwordless SSH logins more
secure?, Inf. Secur., 2011 [Online].
Available:
http://security.stackexchange.com/que
stions/9870/are-passwordless-ssh-
logins-more-secure
[10] VSAntivirus, Grave vulnerabilidad en
el manejo del bfer de OpenSSH,
VSAntivirus, 2003. [Online]. Available:
http://www.vsantivirus.com/vul-
openssh.htm