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

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.

243

Capa de transporte

18.3.1. Capa de transporte

El papel principal de la capa de transporte es facilitar una comunicación segura 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.

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 hecho para 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

infraestructura bá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.

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.

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.

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>

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á disponible en 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.

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

usando ssh 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 cualquier puerto 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:

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.

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.

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 pueden utilizar 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.

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 utility can 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:

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.