PDF de programación - Guía de OpenSSH

Guía de OpenSSH

Luciano Bello - luciano (arr@ba) linux.org.ar
Ver. 0.4 - 22 de Enero de 2004
La última versión está disponible en http://www.lucianobello.com.ar/openssh/

Partes incompletas o no revisadas, explicación de forwarding.

Tablero de cambios
0.1

0.2

10-
Ene-
04
13-
Ene-
04
15-
Ene-
04
0.4(current) 22-
Ene-
04

0.3

Correcciones ortográficas, de formato. Se completa parte del Apéndice I.

Menos errores de tipeo (thx Fedex!). Arreglo de links rotos. Validación W3Consortium
para HTML 4.01 Transitional. Optimización de los png (thx Sismo!).

Se hacen las pruebas de seguridad del forwarding. Se agregan los créditos de Dia y de
Gimp. Se agregan subsecciones en "(In)Seguridad en el forwarding". Se completan las
capturas de pantalla incompletas.

Copyright © 2004 Luciano Bello. Se permite la copia, distribución y/o modificación de este documento bajo
los términos de la GNU Free Documentation License, Versión 1.1 o cualquier otra versión publicada por la
Free Software Foundation; con la Sección Invariante siendo "Prefacio", con el Texto de Portada siendo "Guía
de OpenSSH", y sin Textos al respaldo de la página de título. Una copia de la licencia se puede encontrar aquí.

a Machu

Índice

Índice
Prefacio

Sobre este documento
Convenciones
Introducción a SSH
Introducción a OpenSSH
Tuneleando conexiones (Port Forwarding)

¿Porque tunelear conexiones?
A forwardear se a dicho

Forwarding Local simple
Forwarding Local a un servidor protegido/nateado
Forwarding Local de una red (Gateway al túnel)
Forwarding Remoto

Forwarding del X
¿Y que hago con el shell?(completar)
(In)Seguridad en el forwarding
Deshabilitar el forwarding

Resumen de Referencia

T.U.P.E.R. (Tips Útiles, Pequeños, Estúpidos y/o Rápidos)

Loguear conexiones entrantes y salientes (check!)
Proteger el acceso de root
Abrir X remotamente desde una sesión ssh (check!)
Ejecutar un comando remotamente

Tramos no encriptados
Multiusers en un forwardeo de localhost
GatewayPorts en todas las interfaces

Apéndice I (PuTTY)
Creando túneles

Port Forwarding
Caso de Estudio

Prefacio

Sobre este documento

El autor no se hace responsable de los daños o perdida de datos producidos por la libre aplicación de la

información contenida en este documento. De hecho, nadie se hace responsable. Que a mi me haya

funcionado no significa que respondo por los resultados.

Para un mejor seguimiento de cambios de este documento sugiero que quien lo modifique me avise, así
toda la comunidad puede hacer uso de ellos. Los créditos de los cambios serán respetados, como también los
créditos originales del autor. Si quiere hacer referencia a este documento o si quiere tener una copia en su
página ruego también se me avise.

El autor suele castellanizar palabras del inglés como "tunelear" (por "tunneling"), espero esto sea útil y no
moleste a nadie, pero hay palabras anglosajonas que no tienen su equivalente en el español. Tal vez, con el
tiempo, haga un pequeño glosario para los no argentinos.

Los dibujos están hecho en Dia y retocados con TheGimp se pueden agrandar haciendo un click sobre

ellos.

Este documento intenta ser una humilde guía práctica de OpenSSH, así como también un manual de

referencia para consultas rápidas. Críticas, preguntas o mejoras son bienvenidas y agradecidas.

Volver al índice

Convenciones

Si el segundo número de la versión es distinto a 0 es porque hay cosas no probadas, porque se hace
referencia a secciones que todavía no se escribieron o porque hay secciones incompletas. Cuando se agregen
nuevas secciones del nivel más alto, el primer número aumentará. Para detalles sobre los cambios en las
versiones puede seguir el "Tablero de cambios", en la parte superior de este documento

La jerarquía de títulos es la correspondiente a la etiqueta <h*> del código HTML.

Los nombres de host se escriben en italic. Por ejemplo: imap.utn.edu.ar. Los nombres de los archivos en
courier. Por ejemplo: /etc/ssh/sshd_config. Los comandos y salidas de terminales se expresan
con letras gruesas blancas sobre fondo negro, y sus comentarios con letras finas. En bold irán las palabras

claves o los conceptos que merezcan ser resaltados. Los canales seguros (o sea, encriptados por la sesión SSH)
se representan con una flecha de color gruesa. Los números de puertos a los que se hace referencia son todos
TCP, a menos que se aclare lo contrario.

Volver al índice

Introducción a SSH

Secure Shell es una solución basada en software que mantiene seguros los datos de la red. Muchos
usuarios de telnet, rlogin, ftp y otros programas parecidos, no se dan cuenta que sus contraseñas se están
transmitiendo sin cifrar a través de la red. SSH cifra todo el tráfico (incluidas las contraseñas) para
eliminar de un modo efectivo las "escuchas", los secuestros de las conexiones y otros ataques a nivel de red.
Además, SSH ofrece amplias posibilidades para la creación de túneles seguros, aparte de una variedad de
métodos de autenticación. Parece cosa de locos, pero Secure Shell no es un shell. No es un interprete, historial
de comandos, ni demás.

Pero sí hace cosas muy útiles por la seguridad de un sistema en entornos poco confiables. Algunas

"features":

Protocolo criptográfico en un modelo cliente/servidor
Autenticación de las más variadas formas:

Integración con sistemas de autenticación como:

por contraseña
por host
por sistema de llaves

Kerberos
SecurID
PGP
TIS Gauntlet
PAM

Seguriza los protocolos de aplicación de manera (casi) transparente
Implementación sobre la mayoría de los sistemas operativos y plataformas

Volver al índice

Introducción a OpenSSH

De la página de OpenSSH: «OpenSSH es una versión LIBRE del paquete de herramientas de
comunicación segura del protocolo SSH/SecSH para redes, una solución de seguridad que está ganando la
confianza de un número cada vez mayor de usuarios de Internet.[...] Está desarrollado principalmente por el
Proyecto OpenBSD, y su primera integración en un sistema operativo fue en OpenBSD 2.6. Estos programas
se desarrollan fuera de los EE.UU., usando código desarrollado en unos 10 países distintos. Este código es de
libre utilización bajo la licencia BSD.

La gestión de la distribución de OpenSSH está dividida entre dos equipos. Un equipo sólo lleva a cabo el
desarrollo basado en OpenBSD, y su objetivo es el de producir un código que sea tan limpio, simple y seguro
como sea posible. Estamos convencidos de que el sacrificio de la portabilidad en favor de la simplicidad
permite un mejor control de calidad y facilita la revisión del código. El otro equipo toma la versión "pura" y la
convierte en una versión portable, para que pueda funcionar en muchos otros sistemas operativos (estas
versiones se conocen como "versiones p", y se distinguen por nombre como OpenSSH 3.7p1). Esta es la lista
de Sistemas Operativos donde OpenSSH está portado:

AIX
HP-UX
Irix
Linux
NeXT
SCO
SNI/Reliant Unix
Solaris
Digital Unix/Tru64/OSF
Mac OS X
Cygwin
... y más que van siendo añadidos continuamente.»

Esta guía se basará en OpenSSH por ser LIBRE y por que muchos sistemas operativos y
productos lo tienen integrado al sistema base. Aunque la mayoría de los conceptos son igual de aplicables a
las implementaciones propietarias.

Volver al índice

Tuneleando conexiones (Port Forwarding)

¿Porque tunelear conexiones?

SSH no solo provee un login remoto de manera segura. También permite generar conexiones de
servicios inseguros (como ser http, imap, pop entre otros) sobre sesiones de SSH de manera (casi) transparente
para ellos. Esto es lo que se llama "Port Forwarding".

Pero... ¿por qué forwardear conexiones?

Porque necesito acceder a servicios TCP internos de una LAN con direcciones privadas
Porque no quiero que pasar mi clave en texto plano de FTP (canal de control y comandos), Telnet,
POP3, IMAP, SMTP o NNTP
Porque necesito atravesar un firewall donde solo servicio de SSH está permitido
Porque el relay del SMTP de mi ISP solo está abierto para las direcciones asignadas por él y quiero
usarlo para mandar mis mails
Porque quiero servicios X a través de una red insegura

Volver al índice

A forwardear se a dicho

Antes de poner en práctica el forwarding de puertos sugiero leer las implicaciones de seguridad que las

distintas técnicas conllevan.

Si los conceptos ya se conocen la sección "Resumen de Referencia" puede ser útil como ayuda memoria.

Cuando se genera una sesión SSH se puede hacer que ciertas aplicaciones pasen por el túnel encriptado
que se generó. Para las aplicaciones superiores es (casi) transparente y segurizar de esta manera es mucho
menos engorroso que levantar una VPN. Pero solo permite que aplicaciones TCP pasen por el túnel, ya que
son orientadas a conexión. UDP no maneja sesiones, por lo que este sistema no funciona para servicios como
DHCP, NFS, NetBIOS y TFTP entre otros. Tampoco se pueden forwardear protocolos no basados en IP,
como AppleTalk o IPX. Para resumir, solo TCP/IP está permitido, como ser: Telnet, HTTP, SMTP, HTTPS
(HTTP con encriptación SSL), POP, IMAP, ciertas características de DNS, SSH en sí mismo y FTP, este
último con algunas consideraciones /*que explicaré luego(ref!)*/.

Como ejemplo de forwarding voy a usar el servicio de IMAP. La situación es la siguiente: tengo, tras un
firewall, un servidor (que llamaremos "imap.utn.edu.ar") de IMAP (corriendo en el puerto 143/tcp) y de
OpenSSH (en el 22/tcp). En otra punta de InterNet (atravesando redes inseguras) está mi computadora (que
llamaremos home, con conexión y los cliente correspondientes de ambos servicios.

Si yo me conecto directamente tanto el nombre de usuario como la contraseña se transmiten en texto
plano. Pero al usar port forwarding la comunicación en su totalidad será encri