El servidor ssh (cap32)

�

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.

2

Sistema Operativo Linux

3


El servidor SSH

32.�. IntroducciónOpenSSH 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:

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.

telnet ftp rlogin rsh rcp

�


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.�. ¿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óndeundeterminadohostoconestaestrategia,unsistemainterceptorfingeserelrecipienteaquienestádestinadounmensaje. 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 IPspoofing.

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.

�


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 firmasprivadascodificadas 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 sshLa 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.

�


• 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.�. Configurar un servidor OpenSSHPara 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-qaopenssh-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.�.�. 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

�


• 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.0ListenAddress 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 AUTHSyslogFacility AUTHPRIV#LogLevel INFO

�


# Authentication:

#LoginGraceTime 2m#PermitRootLogin yesPermitRootLogin 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 noPasswordAuthentication yes

# Change to no to disable s/key passwords#ChallengeResponseAuthentication yesChallengeResponseAuthentication no

# Kerberos options#KerberosAuthentication no#KerberosOrLocalPasswd yes#KerberosTicketCleanup yes#KerberosGetAFSToken no

# GSSAPI options#GSSAPIAuthentication noGSSAPIAuthentication yes#GSSAPICleanupCredentials yesGSSAPICleanupCredentials yes

# Set this to ‘yes’ to enable PAM authentication, account processing,

�


# 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 noUsePAM yes

#AllowTcpForwarding yes#GatewayPorts no#X11Forwarding noX11Forwarding 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 subsystemsSubsystem sftp /usr/libexec/openssh/sftp-server

�0


32.�.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--level2345sshdoff

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)!

ItisalsopossiblethattheRSAhostkeyhasjustbeenchanged.

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.

��


32.�. Configuración de un cliente OpenSSHPara 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-qaopenssh*

openssh-clients-3.9p1-7openssh-askpass-3.9p1-7openssh-3.9p1-7openssh-askpass-gnome-3.9p1-7openssh-server-3.9p1-7

32.�.�. 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 [email protected]

Si su sistema no resuelve nombres de direcciones:

[root@serverlx ~]# ssh [email protected]

La primera vez que ejecute ssh a una máquina remota, verá un mensaje similar al siguiente:

[invitado@serverlx ~]$ ssh [email protected]

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.

�2


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.

[email protected]’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

[email protected]’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.�.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 [email protected]:/home/hharagons

[email protected]’s password:login.sh 100% 2326 2.3KB/s 00:00

�3


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/* [email protected]:/uploads/

32.�.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 [email protected]

Si su sistema no resuelve nombres de direcciones:

[root@serverlx ~]# sftp [email protected]

El shell es casi idéntico al de FTP y tiene las mismas funcionalidades.

��


32.�. Conexión segura desde WindowsPuTTY 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.

��


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

32.�. Recursos adicionales

32.�.�. 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.�.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.

��


El servidor ssh (cap32)

Education

Transcript of El servidor ssh (cap32)