Your SlideShare is downloading. ×
18  open ssh
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

18 open ssh

169
views

Published on

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
169
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
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. 241 OpenSSH SSH™ (o Secure SHell) es un protocolo que facilita las comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor que permite a los usuarios conectarse a un host remotamente. A diferencia de otros protocolos de comunicación remota tales como FTP o Telnet, SSH encripta la sesión de conexión, haciendo imposible que alguien pueda obtener contraseñas no encriptadas. SSH está diseñado para reemplazar aplicaciones de terminal anteriores y menos seguras que eran utilizadas para registrarse remotamente, tales como telnet o rsh. Un programa relacionado, el scp, reemplaza otros programas diseñados para copiar archivos entre hosts como rcp. Ya que estas aplicaciones antiguas no encriptan contraseñas entre el cliente y el servidor, evite usarlas en lo posible. El uso de métodos seguros para registrarse remotamente a otros sistemas reduce los riesgos de seguridad tanto para el sistema cliente como para el sistema remoto. 18.1. Características de SSH El protocolo SSH proporciona los siguientes tipos de protección: • Después de la conexión inicial, el cliente puede verificar que se está conectando al mismo servidor al que se conectó anteriormente. • El cliente transmite su información de autenticación al servidor usando una encriptación robusta de 128 bits. • Todos los datos enviados y recibidos durante la sesión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremadamente difícil de descifrar y leer. • El cliente tiene la posibilidad de reenviar aplicaciones X11 1 desde el servidor. Esta técnica, llamada reenvío por X11, proporciona un medio seguro para usar aplicaciones gráficas sobre una red. Ya que el protocolo SSH encripta todo lo que envía y recibe, se puede usar para asegurar protocolos inseguros. El servidor SSH puede convertirse en un conducto para asegurar los protocolos inseguros, como por ejemplo POP, mediante el uso de una técnica llamada reenvío por puerto. Utilizando este método se incrementa la seguridad del sistema en general y la seguridad de los datos. El servidor y cliente OpenSSH pueden también ser configurados para crear un túnel similar a una red privada virtual para el tráfico entre el cliente y el servidor. Red Hat Enterprise Linux contiene el paquete general de OpenSSH (openssh) así como también los paquetes del servidor OpenSSH (openssh-server) y del cliente (openssh-clients). Tenga en cuenta que los paquetes OpenSSH requieren el paquete OpenSSL (openssl). OpenSSL instala varias bibliotecas criptográficas importantes, permitiendo que OpenSSH pueda proporcionar comunicaciones encriptadas. 18.1.1. ¿Por qué usar SSH? Los usuarios malignos tienen a su disposición una variedad de herramientas que les permiten 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, el atacante puede estar en algún lugar de la red entre entidades en comunicación que hace una copia de la información
  • 2. 242 Capa de transporte que pasa entre ellas. El atacante 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 realizar a través del uso de un paquete sniffer —una utilidad de red muy común. • Impersonation of a particular host — Using this strategy, an attacker's system is configured to pose as the intended recipient of a transmission. If this strategy works, the user's system remains unaware that it is communicating with the wrong host. Este ataque puede realizarse con técnicas como el envenenamiento del DNS 2 o spoofing de IP (engaño de direcciones IP) 3 Ambas técnicas interceptan información potencialmente confidencial y si esta intercepción se realiza 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, se pueden disminuir notablemente estas amenazas a la seguridad. 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á 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 llave conocida sólo por el sistema local y el remoto. 18.2. Versiones del protocolo SSH The SSH protocol allows any client and server programs built to the protocol's specifications to communicate securely and to be used interchangeably. En la actualidad existen dos variedades de SSH (versión 1 y versión 2). La suite OpenSSH bajo Red Hat Enterprise Linux utiliza por defecto la versión 2 de SSH, la cual tiene un algoritmo de intercambio de llaves mejorado que no es vulnerable al hueco de seguridad en la versión 1. Sin embargo, la suite OpenSSH también soporta las conexiones de la versión 1. Importante Se recomienda que sólo se utilicen servidores y clientes compatibles con la versión 2 de SSH siempre que sea posible. 18.3. Secuencia de eventos de una conexión SSH La siguiente serie de eventos lo ayudan a proteger la integridad de la comunicación SSH entre dos host. 1. Se lleva a cabo un "apretón de manos" encriptado para que el cliente pueda verificar que se está comunicando con el servidor correcto. 2. La capa de transporte de la conexión entre el cliente y la máquina remota es encriptada mediante un código simétrico. 3. El cliente se autentica ante el servidor. 4. El cliente remoto interactúa con la máquina remota a través de la conexión encriptada.
  • 3. 243 Capa de transporte 18.3.1. Capa de transporte El papel principal de la capa de transporte es facilitar una comunicaciónsegura entre los dos hosts durante la autenticación y la subsecuente comunicación. La capa de transporte lleva a cabo esta tarea manejando la encriptación y decodificación de datos y proporcionando protección de integridad de los paquetes de datos mientras son enviados y recibidos. La capa de transporte proporciona compresión de datos, lo que acelera la transmisión de la información. Al contactar un cliente a un servidor por medio del protocolo SSH se negocian varios puntos importantes para que ambos sistemas puedan construir la capa de transporte correctamente. Durante el intercambio se producen los siguientes pasos: • Intercambio de claves • Se determina el algoritmo de encriptación de la clave pública • Se determina el algoritmo de la encriptación simétrica • Se determina el algoritmo autenticación de mensajes • Se determina el algoritmo del hash During the key exchange, the server identifies itself to the client with a unique host key. If the client has never communicated with this particular server before, the server's host key is unknown to the client and it does not connect. OpenSSH gets around this problem by accepting the server's host key. This is done after the user is notified and has both accepted and verified the new host key. In subsequent connections, the server's host key is checked against the saved version on the client, providing confidence that the client is indeed communicating with the intended server. If, in the future, the host key no longer matches, the user must remove the client's saved version before a connection can occur. Precaución Un atacante podría enmascararse como servidor SSH durante el contacto inicial ya que el sistema local no conoce la diferencia entre el servidor en cuestión y el servidor falso configurado por un agresor. Para evitar que esto ocurra, debería verificar la integridad del nuevo servidor SSH contactando con el administrador del servidor antes de conectarse por primera vez o en el evento de que no coincidan las claves. SSH fue ideado para funcionar con casi cualquier tipo de algoritmo de clave pública o formato de codificación. Después del intercambio de claves inicial se crea un valor hash usado para el intercambio y un valor compartido secreto, los dos sistemas empiezan inmediatamente a calcular claves y algoritmos nuevos para proteger la autenticación y los datos que se enviarán a través de la conexión en el futuro. Después de que una cierta cantidad de datos haya sido transmitida con un determinado algoritmo y clave (la cantidad exacta depende de la implementación de SSH), ocurre otro intercambio de claves, el cual genera otro conjunto de valores de hash y un nuevo valor secreto compartido. De esta manera aunque un agresor lograse determinar los valores de hash y de secreto compartido, esta información sólo será válida por un periodo de tiempo limitado.
  • 4. 244 Capa de transporte 18.3.2. 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. Los servidores y clientes SSH se pueden configurar para permitir varios tipos de autenticación, lo cual le concede a cada lado la cantidad óptima de control. El servidor podrá decidir qué métodos de encriptación soportará basado en su pauta de seguridad; el cliente puede elegir el orden en que intentará utilizar los métodos de autenticación entre las opciones a disposición. 18.3.3. Canales Luego de una autenticación exitosa sobre la capa de transporte SSH, se abren múltiples canales a través de la técnica llamada multiplexing 4 . Cada uno de estos canales manejan la conexión para diferentes sesiones de terminal y para sesiones de reenvío X11. Ambos clientes y servidores pueden crear un canal nuevo. Luego se le asigna un número diferente a cada canal en cada punta de la conexión. Cuando el cliente intenta abrir un nuevo canal, los clientes envían el número del canal junto con la petición. Esta información es almacenada por el servidor y usada para dirigir la comunicación a ese canal. Esto es hechopara que diferentes tipos de sesión no afecten una a la otra y así cuando una sesión termine, su canal pueda ser cerrado sin interrumpir la conexión SSH primaria. Los canales también soportan el control de flujo, el cual les permite enviar y recibir datos ordenadamente. De esta manera, los datos no se envían a través del canal sino hasta que el host haya recibido un mensaje avisando que el canal está abierto y puede recibirlos. El cliente y el servidor negocian las características de cada canal automáticamente, dependiendo del tipo de servicio que el cliente solicita y la forma en que el usuario está conectado a la red. Esto otorga una gran flexibilidad en el manejo de diferentes tipos de conexiones remotas sin tener que cambiar la infraestructurabásica del protocolo. 18.4. Configurar un servidor OpenSSH Para poner en funcionamiento un servidor OpenSSH, primero debe asegurarse de que su sistema tiene los paquetes RPM instalados. Se requiere el paquete openssh-server que depende a su vez del paquete openssh. El demonio OpenSSH usa el archivo de configuración /etc/ssh/sshd_config. El archivo de configuración por defecto debería ser suficiente para la mayoría de los propósitos. Si quiere configurar su propio demonio de otra manera que no sea la proporcionada por defecto en el sshd_config, lea la página del manual de sshd para una lista de palabras reservadas que pueden ser definidas en su archivo de configuración. Si reinstala un sistema, el sistema reinstalado crea un nuevo conjunto de llaves de identificación. Cualquier cliente que se haya conectado al sistema con alguna de las herramientas OpenSSH, verán el siguiente mensaje antes de la reinstalación: Una conexión multiplexada consiste de muchas señales que se envian sobre un medio común, compartido. Con SSH, canales diferentes son enviados sobre una conexión común segura.
  • 5. 245 Requiriendo SSH para conexiones remotas @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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. If you want to keep the host keys generated for the system, backup the /etc/ssh/ssh_host*key* files and restore them after the reinstall. This process retains the system's identity, and when clients try to connect to the system after the reinstall, they will not receive the warning message. 18.4.1. Requiriendo SSH para conexiones remotas For SSH to be truly effective, using insecure connection protocols, such as Telnet and FTP, should be prohibited. Otherwise, a user's password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Algunos servicios a deshabilitar incluyen: • telnet • rsh • rlogin • vsftpd Para desactivar métodos de conexión inseguros al sistema, use el programa de línea de comandos chkconfig, el programa basado en ncurses ntsysv, o la Services Configuration Tool (system- config-services). Todas estas herramientas requieren prioridades de root. 18.5. Archivos de configuración de OpenSSH OpenSSH tiene dos conjuntos diferentes de archivos de configuración: uno para clientes (ssh, scp y sftp) y otro para el demonio del servidor (sshd). 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 autenticación del host. • ssh_config — The system-wide default SSH client configuration file. It is overridden if one is also present in the user's home directory (~/.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.
  • 6. 246 Requiriendo SSH para conexiones remotas • 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. User-specific SSH configuration information is stored in the user's home directory within the ~/.ssh/ directory: • authorized_keys — Este archivo contiene una lista de claves públicas autorizadas. Cuando un cliente se conecta al servidor, el servidor autentica al cliente chequeando su clave pública firmada almacenada dentro de este archivo. • id_dsa — Contiene la clave privada DSA del usuario. • id_dsa.pub — la clave pública DSA del usuario. • id_rsa — La clave RSA privada usada por ssh para la versión 2 del protocolo SSH. • id_rsa.pub — La clave pública RSA usada por ssh para la versión 2 del protocolo SSH. • identity — La clave privada RSA usada por ssh para la versión 1 del protocolo SSH. • identity.pub — La clave pública RSA usada por ssh para la versión 1 del protocolo SSH. • known_hosts — Este archivo contiene las claves de host DSA de los servidores SSH a los cuales el usuario ha accedido. Este archivo es muy importante para asegurar que el cliente SSH está conectado al servidor SSH correcto. Importante If an SSH server's host key has changed, the client notifies the user that the connection cannot proceed until the server's host key is deleted from the known_hosts file using a text editor. Before doing this, however, contact the system administrator of the SSH server to verify the server is not compromised. Consulte las páginas man para ssh_config y sshd_config para obtener información acerca de las directivas disponibles en los archivos de configuración SSH. 18.6. 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.
  • 7. 247 Uso del comando ssh 18.6.1. Uso del comando ssh El comando ssh es un reemplazo seguro para los comandos rlogin, rsh y telnet. Le permite inicar sesiones y ejecutar comandos en máquinas remotas. Inicie una sesión en una máquina remota con ssh que es muy parecido a utilizar el comando telnet. Para iniciar una sesión remota a una máquina llamada penguin.example.net, escriba el comando siguiente en el intérprete de comandos de la shell: ssh penguin.example.net La primera vez que ejecute ssh a una máquina remota, verá un mensaje similar al siguiente: The authenticity of host 'penguin.example.net' can't be established. DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c. Are you sure you want to continue connecting (yes/no)? Escriba yes para continuar. Esto añadirá el servidor en su lista de host conocidos (~/.ssh/ known_hosts/) como se muestra en el siguiente mensaje: Warning: Permanently added 'penguin.example.net' (RSA) to the list of known hosts. Luego, verá un intérprete de comandos preguntándole por su contraseña. Después de ingresar su contraseña, se encontrará en el intérprete de comandos de la máquina remota. Si no especifica un nombre de usuario, el nombre de usuario con el que se ha validado en la máquina local se utilizará en la máquina remota. Si quiere especificar un nombre de usuario use el comando siguiente: ssh username@penguin.example.net También puede usar la sintaxis ssh -l nombre-usuario penguin.example.net. El comando ssh se puede utilizar para ejecutar un comando en una máquina remota sin acceder al intérprete de comandos. La sintaxis es ssh nombre-host command. Por ejemplo, si quiere ejecutar el comando ls /usr/share/doc en la máquina remota penguin.example.net, escriba el comando siguiente en la línea de comandos de la shell: ssh penguin.example.net ls /usr/share/doc Una vez que introduzca la contraseña correcta, verá el contenido del directorio /usr/share/doc, y regresará a la shell de su equipo local. 18.6.2. Usando el comando scp El comando scp 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 <localfile> username@tohostname:<remotefile>
  • 8. 248 Uso del comando ssh The <localfile> specifies the source including path to the file, such as /var/log/maillog. The <remotefile> specifies the destination, which can be a new filename such as /tmp/hostname- maillog. For the remote system, if you do not have a preceding /, the path will be relative to the home directory of username, typically /home/username/. Para transferir un archivo local shadowman al directorio principal de su cuenta en penguin.example.net, escriba en la línea de comandos (reemplace nombre-usuario con su nombre de usuario): scp shadowman username@penguin.example.net:shadowman Esto transferirá el archivo local shadowman a /home/nombre_usuario/shadowman en penguin.example.net. También puede dejar por fuera la parte final de shadowman en el comando scp. La sintaxis general para transferir un archivo remoto al sistema local es como sigue: scp username@tohostname:<remotefile> <newlocalfile> The <remotefile> specifies the source including path, and <newlocalfile> specifies the destination including path. Se pueden especificar múltiples archivos como las fuentes. Por ejemplo, para transferir el contenido del directorio downloads/ a un directorio existente llamado uploads/ en la máquina remota penguin.example.net, teclee lo siguiente desde el intérprete de comandos: scp downloads/* username@penguin.example.net:uploads/ 18.6.3. Uso del comando sftp La utilidad sftp puede ser usada para abrir una sesión segura interactiva de FTP. Es similar a ftp excepto que ésta utiliza una conexión encriptada segura. La sintaxis general es sftp nombre- usuario@hostname.com. Una vez autentificado, podrá utilizar un conjunto de comandos similar al conjunto utilizado por el comando FTP. Consulte las páginas del manual de sftp para obtener un listado de todos estos comandos. Para consultar el manual ejecute el comando man sftp en el intérprete de comandos. La utilidad sftp sólo está disponibleen las versiones 2.5.0p1 de OpenSSH y superiores. 18.7. Más que un Shell seguro Una interfaz de línea de comandos segura es sólo el inicio de las muchas maneras de usar SSH. Dada una cantidad apropiada de ancho de banda, las sesiones X11 se pueden dirigir por un canal SSH. O usando reenvío TCP/IP, se pueden asignar conexiones de puerto entre sistemas que previamente eran inseguras a canales SSH específicos. 18.7.1. Reenvío por X11 Abrir una sesión X11 a través de una conexión SSH es tan fácil como conectarse a un servidor SSH utilizando la opción -Y y ejecutar un programa X en una máquina local.
  • 9. 249 Reenvío del puerto ssh -Y <user>@example.com Cuando un programa X se ejecuta desde un intérprete de comandos de shell segura, el cliente y el servidor SSH crean un nuevo canal seguro; los datos del programa X se envían a través de ese canal a la máquina cliente de forma transparente. El reenvío por X11 puede ser muy útil. Por ejemplo, se puede usar el reenvío por X11 para crear una sesión segura e interactiva de la Printer Configuration Tool. Para hacer esto, conéctese al servidor usandossh y escriba: system-config-printer & Después de proporcionar la contraseña de root para el servidor, la Printer Configuration Tool aparecerá y le permitirá al usuario remoto configurar de una forma segura la impresora en el sistema remoto. 18.7.2. Reenvío del puerto Con SSH puede asegurar los protocolos TCP/IP a través del reenvío de puertos. Cuando use esta técnica, el servidor SSH se convierte en un conducto encriptado para el cliente SSH. El reenvío de puertos funciona mediante el mapeado de un puerto local en el cliente a un puerto remoto en el servidor. SSH le permite mapear cualquierpuerto desde el servidor a cualquier puerto en el cliente; los números de puerto no necesitan coincidir para que esto funcione. Para crear un canal de reenvío de puerto TCP/IP que escucha conexiones del localhost, utilice el siguiente comando: ssh -L local-port:remote-hostname:remote-port username@hostname Nota La configuración del reenvío de puertos para escuchar puertos bajo 1024 requiere acceso de root. Para verificar correo-e en un servidor llamado mail.example.com usando POP3 a través de una conexión encriptada, use el comando siguiente: ssh -L 1100:mail.example.com:110 mail.example.com Una vez que el canal de reenvío de puerto está entre la máquina cliente y el servidor de correo, puede direccionar su cliente de correo POP3 para usar el puerto 1100 en su host local para comprobar el nuevo correo. Cualquier petición enviada al puerto 1100 en el sistema cliente será dirigida seguramente al servidor mail.example.com. Si mail.example.com no está ejecutando un servidor SSH, pero otra máquina en la misma red si, SSH todavía puede ser usado para asegurar parte de la conexión. Sin embargo, un comando ligeramente diferente es necesario:
  • 10. 250 Reenvío del puerto ssh -L 1100:mail.example.com:110 other.example.com En este ejemplo, se está reenviando las peticiones POP3 desde el puerto 1100 en la máquina cliente a través de una conexión SSH en el puerto 22 al servidor SSH, other.example.com. Luego, other.example.com se conecta al puerto 110 en mail.example.com para verificar correo nuevo. Observe que usando esta técnica, sólo la conexión entre el sistema cliente y el servidor SSH other.example.com es segura. El reenvío del puerto se puede usar para obtener información segura a través de los cortafuegos de red. Si el cortafuegos está configurado para permitir el tráfico SSH a través del puerto estándar (22) pero bloquea el acceso a través de otros puertos, es posible todavía una conexión entre dos hosts usando los puertos bloqueados al redireccionar la comunicación sobre una conexión SSH establecida. Nota Si se utiliza el reenvío de puerto para reenviar conexiones de este modo, cualquier usuario en el sistema cliente puede conectarse a ese servicio. Si el cliente está en riesgo o está comprometido,un agresor puede también acceder a los servicios reenviados. Los administradores de sistemas pueden desactivar la funcionalidad de reenvío de puerto en el servidor si especifican No en la línea AllowTcpForwarding en /etc/ssh/sshd_config. El servicio sshd debe ser reiniciado después de esta modificación. 18.7.3. Generar pares de claves Si no quiere introducir su contraseña cada vez que se conecte a una máquina remota con ssh, scp o sftp, puede generar un par de claves de autorización. Las claves deben ser generadas para cada usuario. Para generar las claves de un usuario debe seguir los siguientes pasos como el usuario que quiere conectarse a máquinas remotas. Si completa los siguentes pasos como root, sólo root será capaz de utilizar estas claves. Arrancar con la versión 3.0 de OpenSSH, ~/.ssh/authorized_keys2, ~/.ssh/known_hosts2, y /etc/ssh_known_hosts2 se ha quedado obsoletas. Los protocolos 1 y 2 de SSH comparten los archivos ~/.ssh/authorized_keys, ~/.ssh/known_hosts y /etc/ssh/ssh_known_hosts. Red Hat Enterprise Linux 5.2 uses SSH Protocol 2 and RSA keys by default. Tip Si reinstala y quiere guardar los pares de llaves generados, haga una copia de respaldo del directorio .ssh en su directorio principal (home). Después de la reinstalación, copie este directorio de vuelta a su directorio principal. Este proceso puede realizarse para todos los usuarios de su sistema, incluyendo root.
  • 11. 251 Generar pares de claves 18.7.3.1. Generar un par de claves RSA para la versión 2 Siga los siguientes pasos para generar un par de claves RSA para la versión 2 del protocolo SSH. Esto es lo predeterminado para iniciar con OpenSSH 2.9. 1. Para generar un par de claves RSA para trabajar con la versión 2 del protocolo, teclee el siguiente comando desde el intérprete de comandos de la shell: ssh-keygen -t rsa Acepte la localización por defecto del archivo ~/.ssh/id_rsa. Introduzca una contraseña diferente de la contraseña de su cuenta y confírmela introduciéndola nuevamente. La clave pública se escribe a ~/.ssh/id_rsa.pub. La clave privada está escrita a ~/.ssh/ id_rsa. No distribuya la clave privada a nadie. 2. Cambie los permisos de su directorio .ssh usando el comando siguiente: chmod 755 ~/.ssh 3. Copie los contenidos de ~/.ssh/id_rsa.pub al archivo ~/.ssh/authorized_keys en la máquina en la que se quiere conectar. Si el archivo ~/.ssh/authorized_keys existe, puede añadir los contenidos del archivo ~/.ssh/id_rsa.pub al archivo ~/.ssh/authorized_keys en la otra máquina. 4. Cambie los permisos del archivo authorized_keys usando el comando siguiente: chmod 644 ~/.ssh/authorized_keys 5. If you are running GNOME or are running in a graphical desktop with GTK2+ libraries installed, skip to Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”.If you are not running the X Window System, skip to Sección 18.7.3.5, “Configuración de ssh-agent”. 18.7.3.2. Generación de un par de claves DSA para la versión 2 Use los siguientes pasos para generar un par de claves DSA para la versión 2 del protocolo SSH. 1. Para generar un par de claves DSA para trabajar con la versión 2 del protocolo, escriba el siguiente comando en el intérprete de comandos de la shell: ssh-keygen -t dsa Acepte la localización por defecto del archivo ~/.ssh/id_dsa. Introduzca una frase secreta diferente a la contraseña de su cuenta y confirme ésta introduciéndola de nuevo.
  • 12. 252 Generar pares de claves Tip Una frase secreta es una cadena de caracteres o palabras utilizadas para autentificar a un usuario. Las frases secretas se diferencian de las contraseñas en que se puedenutilizar espacios o tabuladores en la primera. Las frases secretas son generalmente más largas que las contraseñas porque ellas son habitualmente frases. Algunas veces estos dos términos se usan indistintamente. La clave pública es escrita a ~/.ssh/id_dsa.pub. La clave privada es escrita a ~/.ssh/ id_dsa. Es de suma importancia que no de la clave privada a nadie. 2. Cambie los permisos de su directorio .ssh usando el comando siguiente: chmod 755 ~/.ssh 3. Copie los contenidos de ~/.ssh/id_dsa.pub a ~/.ssh/authorized_keys en la máquina a la cual quiere conectarse. Si el archivo ~/.ssh/authorized_keys existe, añada los contenidos del archivo ~/.ssh/id_dsa.pub al archivo ~/.ssh/authorized_keys en la otra máquina. 4. Cambie los permisos del archivo authorized_keys usando el comando siguiente: chmod 644 ~/.ssh/authorized_keys 5. If you are running GNOME or a graphical desktop environment with the GTK2+ libraries installed, skip to Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”.If you are not running the X Window System, skip to Sección 18.7.3.5, “Configuración de ssh-agent”. 18.7.3.3. Generación de un par de claves RSA para la versión 1.3 y 1.5 Siga los siguientes pasos para generar un par de claves RSA la cual es usada por la versión 1 del protocolo SSH. Si sólo se está conectando entre sistemas que usan DSA, no necesita una par de claves de versión RSA 1.3 o RSA versión 1.5. 1. Para generar un par de claves RSA (para la versión de protocolos 1.3 y 1.5), escriba el comando siguiente en la línea de comandos de la shell: ssh-keygen -t rsa1 Acepte la localización por defecto del archivo (~/.ssh/identity). Introduzca una contraseña diferente a la contraseña de su cuenta y confirme ésta introduciéndola de nuevo. La clave pública está escrita en ~/.ssh/identity.pub. La clave privada está escrita a ~/.ssh/identity. No entregue su clave a nadie. 2. Cambie los permisos de su directorio .ssh y su clave con los comandos chmod 755 ~/.ssh y chmod 644 ~/.ssh/identity.pub.
  • 13. 253 Generar pares de claves 3. Copie los contenidos de ~/.ssh/identity.pub al archivo ~/.ssh/authorized_keys en la máquina a la cual se desea conectar. Si el archivo ~/.ssh/authorized_keys no existe, puede copiar el archivo ~/.ssh/identity.pub al archivo ~/.ssh/authorized_keys en el equipo remoto. 4. If you are running GNOME, skip to Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”.If you are not running GNOME, skip to Sección 18.7.3.5, “Configuración de ssh-agent”. 18.7.3.4. Configurando ssh-agent con una interfaz gráfica The ssh-agent utilitycan be used to save your passphrase so that you do not have to enter it each time you initiate an ssh or scp connection. If you are using GNOME, the gnome-ssh-askpass package contains the application used to prompt you for your passphrase when you log in to GNOME and save it until you log out of GNOME. You will not have to enter your password or passphrase for any ssh or scp connection made during that GNOME session. If you are not using GNOME, refer to Sección 18.7.3.5, “Configuración de ssh-agent”. Para guardar su contraseña durante una sesión GNOME, siga los pasos siguientes: 1. Verifique que el paquete openssh-askpass-gnome esté instalado usando el comando rpm -q openssh-askpass.Si no está instalado, hágalo desde su conjunto de CDs de Red Hat Enterprise Linux, desde un sitio espejo FTP de Red Hat o usando Red Hat Network. 2. Select Main Menu Button (on the Panel) > Preferences > More Preferences > Sessions, and click on the Startup Programs tab. Click Add and enter /usr/bin/ssh-add in the Startup Command text area. Set it a priority to a number higher than any existing commands to ensure that it is executed last. A good priority number for ssh-add is 70 or higher. The higher the priority number, the lower the priority. If you have other programs listed, this one should have the lowest priority. Click Close to exit the program. 3. Cierre la sesión y luego vuelva a GNOME; en otras palabras, reinicie X. Después de arrancar GNOME, aparecerá una ventana de diálogo pidiéndole su frase secreta. Introduzca ésta. Si tiene pares de claves DSA y RSA, ambas configuradas, lo estará ejecutando para ambas. A partir de este momento,no debería introducir ninguna contraseña para ssh, scp o sftp. 18.7.3.5. Configuración de ssh-agent The ssh-agent can be used to store your passphrase so that you do not have to enter it each time you make a ssh or scp connection. If you are not running the X Window System, follow these steps from a shell prompt. If you are running GNOME but you do not want to configure it to prompt you for your passphrase when you log in (refer to Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”),this procedure will work in a terminal window, such as an XTerm. If you are running X but not GNOME, this procedure will work in a terminal window. However, your passphrase will only be remembered for that terminal window; it is not a global setting. 1. Desde el intérprete de comandos de la shell, teclee el siguiente comando: exec /usr/bin/ssh-agent $SHELL 2. Luego escriba el comando:
  • 14. 254 Generar pares de claves ssh-add e ingrese su contraseña. Si tiene más de un par de claves configuradas, se le pedirá información para ambas. 3. Su contraseña será olvidada cuando termine la sesión. Debe ejecutar estos dos comandos cada vez que abra una consola virtual o abra una ventana de terminal. 18.8. Recursos adicionales Los proyectos OpenSSH y OpenSSL están en constante desarrollo. La información más actualizada está disponible desde sus sitios web. Las páginas de manuales para las herramientas OpenSSH y OpenSSL también son una buena fuente de información detallada. 18.8.1. Documentación instalada • Páginas man 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. 18.8.2. Sitios web útiles • http://www.openssh.com — La página de FAQ de OpenSSH, 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.openssl.org — La página FAQ de OpenSSL, con listas de correo y una descripción del objetivo del proyecto. • http://www.freesshd.com/ — SSH client software for other platforms.