Your SlideShare is downloading. ×
El servidor ssh (cap32)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

El servidor ssh (cap32)

418
views

Published on

SSh en linux

SSh en linux

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
418
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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. 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: 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
  • 4. 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.
  • 5. 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 RSAusada por el demonio sshd para la versión 1 del protocolo. SSH.
  • 6. 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
  • 7. 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
  • 8. 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,
  • 9. 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
  • 10. 10 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.
  • 11. 11 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.
  • 12. 12 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
  • 13. 13 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.
  • 14. 14 Sistema Operativo Linux 32.6. Conexión segura desde Windows PuTTYes 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 SimonTatham.Acontinuació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 IPaddress): 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.
  • 15. 15 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.
  • 16. 16 Sistema Operativo Linux