Capítulo 32: El Servidor SSH

Capítulo 32:

El Servidor SSH
• Introducción.
• ¿Por qué usar OpenSSH?
• ¿Dónde se encuentra la información de configuración de ssh?
• Configurar un servidor OpenSSH.
• Configuración de un cliente OpenSSH.
• Conexión segura desde Windows.
• Recursos adicionales.


 Sistema Operativo Linux


 Capítulo 32: El Servidor SSH

El servidor SSH
32.1. Introducción
OpenSSH es una implementación gratuita y de código libre del protocolo SSH (Secure SHell),
que permite el acceso remoto hacia sistemas. Ésto sustituye a:

telnet ftp rlogin rsh rcp

Con herramientas seguras y de conectividad de la red encriptada.

Su principal ventaja radica en que se utiliza un túnel seguro para la transmisión de datos, algo de
lo que carecen protocolos como FTP y Telnet, que son precisamente los protocolos que se usan
mucho y se desea reemplazar.

32.2. ¿Por qué usar OpenSSH?

Hay dos razones fundamentales:
1. Incrementar la seguridad de su sistema:
Se incrementa la seguridad de su sistema debido a que las herramientas OpenSSH encriptan
toda la comunicación. Telnet y ftp utilizan contraseñas de texto plano y envían toda la
información sin encriptar; y esta puede ser interceptada por un hacker o un cracker o cualquier
persona con algún magro interés. Entonces la seguridad del sistema se ve comprometida. Si
usted utiliza las herramientas OpenSSH se evitará estos problemas de seguridad.

Figura 32.1 OpenSSH y la seguridad.


 Sistema Operativo Linux

2. Re-envio automático de la variable DISPLAY:

OpenSSH automáticamente reenvía la variable DISPLAY a la máquina cliente. En otras
palabras, si está ejecutando el sistema X Window en su máquina local, e ingresa a una máquina
remota usando el comando ssh, cuando ejecute un programa en la máquina remota que requiera
X, será visualizado en su equipo local. Esta característica, es conveniente si prefiere utilizar
las herramientas gráficas del sistema pero no siempre tiene acceso al servidor.

32.2.1. ¿Cuáles son las amenazas que obligan a incrementar la

seguridad del sistema?
Los pseudo usuarios como los hackers y crackers tienen a su disposición una variedad de
herramientas para interceptar y redirigir el tráfico de la red para ganar acceso al sistema. En
términos generales, estas amenazas se pueden catalogar del siguiente modo:
• Intercepción de la comunicación entre dos sistemas: En este escenario, existe un tercero en
algún lugar de la red entre entidades en comunicación que hace una copia de la información
que pasa entre ellas. La parte interceptora puede interceptar y conservar la información, o
puede modificar la información y luego enviarla al recipiente al cual estaba destinada. Este
ataque se puede montar a través del uso de un paquete sniffer o una utilidad de red muy
común.
• Personificación de un determinado host o con esta estrategia, un sistema interceptor
finge ser el recipiente a quien está destinado un mensaje. Si funciona la estrategia, el
cliente no se da cuenta del engaño y continúa la comunicación con el interceptor como si su
mensaje hubiese llegado a su destino satisfactoriamente.
Esto se produce con técnicas como el envenenamiento del DNS o IP spoofing.
Ambas técnicas causan que se intercepte información, posiblemente con propósitos hostiles.
El resultado puede ser catastrófico.
Si se utiliza SSH para inicios de sesión de shell remota y para copiar archivos, estas amenazas
a la seguridad se pueden disminuir notablemente. Esto es porque el cliente SSH y el servidor
usan firmas digitales para verificar su identidad. Adicionalmente, toda la comunicación entre
los sistemas cliente y servidor es encriptada. No servirán de nada los intentos de falsificar la
identidad de cualquiera de los dos lados de la comunicación ya que cada paquete está cifrado
por medio de una clave conocida sólo por el sistema local y el remoto.
Nota:
IP spoofing ocurre cuando un intruso manda paquetes de red que parecen provenir de hosts
de confianza de la red.


 Capítulo 32: El Servidor SSH

32.2.2. ¿Cómo funciona SSH?

La siguiente serie de eventos lo ayudan a proteger la integridad de la comunicación SSH entre
dos hosts.
• Se lleva a cabo un 'handshake’ (apretón de manos) encriptado para que el cliente pueda
verificar que se está comunicando con el servidor correcto.
• La capa de transporte entre el cliente y la máquina remota es encriptada mediante un código
simétrico.
• El cliente se autentica ante el servidor.
• El cliente remoto puede ahora con tranquilidad interactuar con la máquina remota sobre la
conexión encriptada.

32.2.3. Autenticación
Cuando la capa de transporte haya construido un túnel seguro para transmitir información entre
los dos sistemas, el servidor le dirá al cliente de los diferentes métodos de autenticación soportados,
tales como el uso de firmas privadas codificadas con claves o la inserción de una contraseña.
El cliente entonces intentará autenticarse ante el servidor mediante el uso de cualquiera de los
métodos soportados.

32.3. Información de configuración de ssh

La información de configuración SSH para todo el sistema está almacenada en el directorio
/etc/ssh/:
• moduli: Contiene grupos Diffie-Hellman usados para el intercambio de la clave Diffie-
Hellman que es imprescindible para la construcción de una capa de transporte seguro. Cuando
se intercambian las claves al inicio de una sesión SSH, se crea un valor secreto y compartido
que no puede ser determinado por ninguna de las partes individualmente. Este valor se usa
para proporcionar la autentificación del host.
• ssh_config: El archivo de configuración del sistema cliente SSH por defecto que se sobrescribe
si hay alguno ya presente en el directorio principal del usuario (~/ssh/config).
• sshd_config: El archivo de configuración para el demonio sshd.
• ssh_host_dsa_key: La clave privada DSA usada por el demonio sshd.
• ssh_host_dsa_key.pub: La clave pública DSA usada por el demonio sshd.
• ssh_host_key: La clave privada RSA usada por el demonio sshd para la versión 1 del protocolo.
SSH.


 Sistema Operativo Linux

• ssh_host_key.pub. La clave pública RSA usada por el demonio sshd para la versión 1 del
protocolo SSH.
• ssh_host_rsa_key. La clave privada RSA usada por el demonio sshd para la versión 2 del
protocolo SSH.
• ssh_host_rsa_key.pub. La clave pública RSA usada por el demonio sshd para la versión 2
del protocolo SSH.

32.4. Configurar un servidor OpenSSH

Para poner en funcionamiento un servidor OpenSSH, debe asegurarse primero que su sistema
tiene los paquetes RPM instalados.
Se requiere el paquete openssh-server que depende a su vez del paquete openssh.
Para saber si tiene el paquete RPM, ejecute:
[root@fedora3 ~]# rpm -qa openssh-server

openssh-server-3.9p1-7

Se puede apreciar que Linux Fedora Core 3 implementa la vesrsión 3.9p1-7 de OpenSSH.
El demonio OpenSSH usa el archivo de configuración /etc/ssh/sshd_config. Elija un editor y
edite /etc/ssh/sshd_config, para complementar la configuración.

32.4.1. Parámetros de /etc/ssh/sshd_config

Se analizará sólo tres parámetros que pondrán expedito nuestro servidor SSH, veamos:
• Parámetro ListenAddress:
Por defecto SSHD escuchará peticiones por todas las interfaces del sistema. En algunos casos
es posible que no se desee esto y se prefiera limitar el acceso sólo a través de una interfaz
que sólo se pueda acceder desde la red local. Para tal fin puede establecerse lo siguiente,
considerando que el servidor a configurar posee la dirección IP 192.168.1.243:
ListenAddress 192.168.1.243
• Parámetro PermitRootLogin:
Este parámetro sirve para establecer si se va a permitir el acceso directo del usuario root al
servidor SSH. Si se va a permitir el acceso hacia el servidor desde redes públicas, resultará
prudente utilizar este parámetro con el valor no.
PermitRootLogin no


 Capítulo 32: El Servidor SSH

• Parámetro X11Forwarding
Este parámetro establece si se permite o no la ejecución remota de aplicaciones gráficas. Si
se va a acceder hacia el servidor desde red local, este parámetro puede quedarse con el valor
yes. Si se va a permitir el acceso hacia el servidor desde redes públicas, resultará prudente
utilizar este parámetro con el valor no.
X11Forwarding yes
Ahora veamos su implementación en /etc/ssh/sshd_config:
[root@fedora3 ~]# cat /etc/ssh/sshd_config

# $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
ListenAddress 192.168.1.243
#
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO


 Sistema Operativo Linux

# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
PermitRootLogin no
#
#StrictModes yes
#MaxAuthTries 6
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don’t read the user’s ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
# Set this to ‘yes’ to enable PAM authentication, account processing,


 Capítulo 32: El Servidor SSH

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# “PermitRootLogin without-password”. If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server


 Sistema Operativo Linux

32.4.2. Probando los cambios

El demonio sshd puede inicializarse, detenerse o re-inicializarse a través de un guión similar a
los del resto del sistema. De modo tal, podrá inicializarse, detenerse o re-inicializarse a través
del comando /sbin/service y añadirse al arranque del sistema en un nivel o niveles de corrida en
particular con el comando /sbin/chkconfig.
Para ejecutar por primera vez el servicio, ejecute:
[root@serverlx ~]# /sbin/service sshd start
Para hacer que los cambios hechos a la configuración surtan efecto, ejecute:
[root@serverlx ~]# /sbin/service sshd restart
Para detener el daemon, ejecute:
[root@serverlx ~]# /sbin/service sshd stop
Por defecto sshd está incluido en todos los niveles de corrida con servicio de red. Para deshabilitar
el servicio sshd de los niveles de corrida 2, 3, 4 y 5, ejecute:
[root@serverlx ~]# /sbin/chkconfig --level 2345 sshd off
El siguiente mensaje aparecerá, cuando sus clientes se conecten a un re-instalado sistema Linux
Fedora, en donde se ha vuelto a configurar OpenSSH:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Esto sucede a que el sistema ha creado un nuevo conjunto (set) de claves de identificación para
su sistema; de ahí, el aviso de que la clave RSA del host ha cambiado.
Si desea mantener las claves del host generadas para el sistema, haga una copia de seguridad de
los archivos /etc/ssh/ssh_host*key* y restáurelos después de reinstalar.
Este proceso retiene la identidad del sistema, y cuando los clientes traten de conectarse al sistema
después de la instalación, éstos no recibirán el mensaje de aviso.

10
 Capítulo 32: El Servidor SSH

32.5. Configuración de un cliente OpenSSH

Para conectarse a un servidor OpenSSH desde una máquina cliente, debe tener los paquetes
openssh-clients y openssh instalados en la máquina cliente. Usemos el comando rpm para
averiguar esto:
[root@fedora3 ssh]# rpm -qa openssh*
openssh-clients-3.9p1-7
openssh-askpass-3.9p1-7
openssh-3.9p1-7
openssh-askpass-gnome-3.9p1-7
openssh-server-3.9p1-7

32.5.1. Uso del comando ssh

El comando ssh le permite inicar sesiones y ejecutar comandos en máquinas remotas, es un
reemplazo seguro para los comandos rlogin, rsh, y telnet.
Para acceder a través del shell hacia un servidor, basta con ejecutar desde el sistema cliente el
comando ssh definiendo el usuario a utilizar y el servidor al cual conectar. La sintaxis es: ssh
usuario@servidor.
Ejemplos:
Si su sistema resuelve nombres de direcciones:
[root@serverlx ~]# ssh hharagons@fedora3.iciuni.edu.pe
Si su sistema no resuelve nombres de direcciones:
[root@serverlx ~]# ssh hharagons@192.168.1.243
La primera vez que ejecute ssh a una máquina remota, verá un mensaje similar al siguiente:
[invitado@serverlx ~]$ ssh hharagons@192.168.1.243

The authenticity of host ‘192.168.1.243 (192.168.1.243)’ can’t be established.

RSA key fingerprint is 93:f7:c6:76:3e:98:8e:eb:ba:b8:48:b8:d3:a9:de:16.
Are you sure you want to continue connecting (yes/no)? yes

Escriba yes para continuar. Ésto le permitirá agregar el servidor en su lista de host conocidos
como se muestra en el siguiente mensaje:

Warning: Permanently added ‘192.168.1.243’ (RSA) to the list of known hosts.

11
 Sistema Operativo Linux

Luego, verá un indicador de comandos preguntándole por su contraseña. Después de ingresar su

contraseña, se encontrará en el indicador de comandos de la máquina remota.

hharagons@192.168.1.243’s password:
Last login: Sat Jan 21 18:53:40 2006 from 192.168.1.32
[hharagons@fedora3 ~]$

Si no específica un nombre de usuario, el nombre de usuario con el que se ha validado como la

máquina local se validará en la máquina remota.
También puede usar la sintaxis: ssh -l usuario servidor.
Por ejemplo:
[root@serverlx ~]# ssh –l hharagons fedora3.iciuni.edu.pe.
El comando ssh se puede utilizar para ejecutar un comando en una máquina remota sin acceder
al indicador de comandos. La sintaxis es ssh servidor comando.
Veamos un ejemplo:
[invitado@serverlx ~]$ ssh fedora3.iciuni.edu.pe uptime

invitado@fedora3.iciuni.edu.pe’s password:

Una vez que introduzca la contraseña correcta, visualizará el despliegue del comando uptime y
regresará al shell de su equipo local, como se muestra a continuación:

19:30:25 up 9:42, 3 users, load average: 0.04, 0.03, 0.00

[invitado@serverlx ~]$

32.5.2. Uso del comando scp

El comando scp (secure copy) puede ser usado para transferir archivos entre máquinas sobre una
conexión encriptada y segura. Es parecido al comando rcp.
La sintaxis general para transferir el archivo local a un sistema remoto es como sigue a continuación:
scp <archivo local> usuario@servidor:/ruta
Donde: archivo local específica la fuente, y usuario@servidor:/ruta específica el destino. Ejemplo:
para transferir el archivo local login.sh a su cuenta en fedora3.iciuni.edu.pe (192.168.1.243), digite
en la línea de comandos:
[root@serverlx ~]# scp login.sh hharagons@192.168.1.243:/home/hharagons

hharagons@192.168.1.243’s password:
login.sh 100% 2326 2.3KB/s 00:00

12
 Capítulo 32: El Servidor SSH

Se puede especificar múltiples archivos como fuentes. Por ejemplo, para transferir el contenido
del directorio /downloads del servidor serverlx a un directorio existente llamado /uploads en la
máquina remota fedora3.iciuni.edu.pe, teclee lo siguiente desde el intérprete de comandos:

[root@serverlx ~]# scp /downloads/* hharagons@192.168.1.243:/uploads/

32.5.3. Uso del comando sftp

OpenSSH incluye además un servidor de archivos en modo seguro que permite sustituir las
transferencias a través de protocolo FTP, el cual envía todos los datos en texto simple. Para
acceder a través de sftp hacia el servidor, basta con ejecutar desde el sistema cliente el comando
sftp definiendo el usuario a utilizar y el servidor al cual conectar, bajo la siguiente sintaxis: sftp
usuario@servidor.
Ejemplos:
Si su sistema resuelve nombres de direcciones:
[root@serverlx ~]# sftp hharagons@fedora3.iciuni.edu.pe
Si su sistema no resuelve nombres de direcciones:
[root@serverlx ~]# sftp hharagons@192.168.1.243
El shell es casi idéntico al de FTP y tiene las mismas funcionalidades.

13
 Sistema Operativo Linux

32.6. Conexión segura desde Windows

PuTTY es una implementación de Telnet y SSH para plataformas Win32, Unix y Linux, trabajando
con un emulador de terminal xterm. Fue escrito por inicialmente por Simon Tatham. A continuación
el front end de esta aplicación corriendo en un soporte de base Windows 98.

Figura 32.2. Pantalla inicial de Putty.

Para poder conectarnos a un servidor remoto, se debe ingresar la dirección IP de este servidor o su
nombre completo. Por ejemplo, si deseo acceder a mi Intranet, cuya dirección IP es 192.168.1.8,
entonces ingresaré en el campo Host Name (or IP address): 192.168.1.8; elegiré también el valor
del puerto de comunicaciones que por defecto es 22, ésto en el campo Port.
Después presionaré Open y el sistema me conectará con el servidor (osea mi Intranet).
Nota:
SSH (Secure Shell) corre sobre TCP y usa el puerto well known (bien conocido) 22.

14
 Capítulo 32: El Servidor SSH

Figura 32.3. Conexión a serverlx (intranet).

32.7. Recursos adicionales

32.7.1. Documentación instalada
Páginas de manual de ssh, scp, sftp, sshd, y ssh-keygen — estas páginas incluyen información
sobre cómo usar estos comandos así como también los parámetros que se puede usar con ellos.

32.7.2. Sitios web útiles

• http://www.openssh.com:
La página principal de OpenSSH, con una sección FAQ, informe de errores (bugs), listas
de correo, objetivos del proyecto y una explicación más técnica de las características de
seguridad.
• http://www.freessh.org:
Software de cliente SSH para otras plataformas.

15
 Sistema Operativo Linux

16