El documento describe el protocolo SSH y cómo proporciona comunicaciones seguras entre sistemas. SSH encripta la sesión de conexión para hacer imposible obtener contraseñas no encriptadas. También reemplaza aplicaciones menos seguras como telnet o rsh. OpenSSH usa la versión 2 de SSH, la cual tiene un algoritmo de intercambio de llaves mejorado.

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.