Scroll to navigation

SSH(1) General Commands Manual SSH(1)

NOMBRE

ssh — Cliente de sesión remota OpenSSH

SINOPSIS

ssh [-46AaCfGgKkMNnqsTtVvXxYyZ] [-B interfaz_de_enlace] [-b dirección_de_enlace] [-c especificación_de_cifrado] [-D [dirección_de_enlace:]puerto] [-E archivo_de_registro] [-e carácter_de_escape] [-F archivo_de_configuración] [-I pkcs11] [-i archivo_de_identidad] [-J destino] [-L dirección] [-l nombre_de_inicio_de_sesión] [-m especificación_mac] [-O orden_de_control] [-o opción] [-P etiqueta] [-p puerto] [-R dirección] [-S ruta_de_control] [-W host:puerto] [-w túnel_local[:túnel_remoto]] destino [orden [argumento ...]] ssh [-Q opción_de_consulta]

DESCRIPCIÓN

ssh (cliente SSH) es un programa para iniciar sesión en un equipo remoto y ejecutar órdenes en él. Su objetivo es proporcionar comunicaciones cifradas seguras entre dos equipos no confiables a través de una red insegura. También permite reenviar conexiones X11, puertos TCP arbitrarios y sockets UNIX-dominio a través del canal seguro.

ssh se conecta e inicia sesión en el destino especificado, que puede indicarse como [usuario@]nombre_de_equipo o mediante una URI con el formato ssh://[usuario@]nombre_de_equipo[:puerto]. El usuario debe demostrar su identidad al equipo remoto mediante uno de varios métodos (véase más adelante).

Si se especifica una orden, se ejecutará en el equipo remoto en lugar de iniciar una shell de sesión. Se puede indicar una línea de órdenes completa como orden, o bien añadir argumentos adicionales. Si se proporcionan, los argumentos se añadirán a la orden, separados por espacios, antes de enviarla al servidor para su ejecución.

Las opciones son las siguientes:

Obliga a ssh a usar solo direcciones IPv4.

Fuerza ssh a usar solo direcciones IPv6.

Permite el reenvío de conexiones desde un agente de autenticación como ssh-agent(1). Esto también se puede especificar para cada equipo en un archivo de configuración.

El reenvío del agente debe habilitarse con precaución. Los usuarios que puedan eludir los permisos de los archivos del equipo remoto (en el socket UNIX-dominio del agente) pueden acceder al agente local a través de la conexión reenviada. Sin embargo, un atacante no puede obtener el material de las claves del agente, aunque sí puede realizar operaciones con ellas que le permitan autenticarse utilizando las identidades cargadas en el agente. Una alternativa más segura puede ser utilizar un equipo de salto (consulte -J).

Deshabilita el reenvío de la conexión del agente de autenticación.

bind_interface
Enlaza a la dirección de interfaz_enlace antes de intentar conectarse al equipo de destino. Esto solo es útil en sistemas con más de una dirección.

bind_address
Usa dirección_enlace en el equipo local como dirección de origen de la conexión. Solo es útil en sistemas con más de una dirección.

Solicita la compresión de todos los datos (incluidos stdin, stdout, stderr y los datos de las conexiones X11, TCP y UNIX-dominio reenviadas). El algoritmo de compresión es el mismo que utiliza gzip(1). La compresión resulta conveniente en líneas de módem y otras conexiones lentas, pero solo ralentizará las cosas en redes rápidas. El valor predeterminado se puede establecer para cada equipo en los archivos de configuración; consulte la opción Compression en ssh_config(5).

cipher_spec
Selecciona la especificación de cifrado para cifrar la sesión. especificación_cifrado es una lista de cifrados separados por comas, ordenados según su preferencia. Consulte la palabra clave Ciphers en ssh_config(5) para obtener más información.

[dirección_enlace:]puerto
Especifica un reenvío dinámico de puerto local a nivel de aplicación. Funciona asignando un socket que escucha en el puerto local, opcionalmente enlazado a la dirección_enlace indicada. Cuando se establece una conexión con este puerto, se reenvía a través del canal seguro y el protocolo de la aplicación determina a qué destino conectarse desde el equipo remoto. Actualmente se admiten los protocolos SOCKS4 y SOCKS5, y ssh actúa como servidor SOCKS. Solo root puede reenviar puertos privilegiados. Los reenvíos dinámicos de puertos también se pueden especificar en el archivo de configuración.

Las direcciones IPv6 se pueden definir encerrándolas entre corchetes. Solo el administrador puede reenviar puertos privilegiados. De forma predeterminada, el puerto local se enlaza de acuerdo con el valor de GatewayPorts. Sin embargo, se puede utilizar una dirección_enlace explícita para enlazar la conexión a una dirección concreta. La dirección_enlace “localhost” indica que el puerto de escucha solo debe enlazarse para uso local, mientras que una dirección vacía o ‘*’ indica que el puerto debe estar disponible en todas las interfaces.

log_file
Añade los registros de depuración a archivo_registro en lugar de enviarlos a la salida de error estándar.

carácter_escape
Establece el carácter de escape para sesiones con un pty (predeterminado: ‘~’). El carácter de escape solo se reconoce al principio de una línea. El carácter de escape seguido de un punto ( (‘.’)) cierra la conexión; seguido de Control-Z la suspende; y seguido de sí mismo envía el carácter de escape una sola vez. Si se establece el carácter en “none”, se deshabilitan todos los escapes y la sesión se vuelve completamente transparente.

archivo_configuración
Define un archivo de configuración alternativo por usuario. Si se proporciona un archivo de configuración en la línea de órdenes, se ignorará el archivo de configuración de todo el sistema (/etc/ssh/ssh_config). El valor predeterminado del archivo de configuración por usuario es ~/.ssh/config. Si se establece en “none”, no se leerá ningún archivo de configuración.

Solicita a ssh que pase a segundo plano justo antes de la ejecución de la orden. Esto resulta útil si ssh va a solicitar contraseñas o frases de contraseña, pero el usuario desea que se ejecute en segundo plano. Esto implica -n. La forma recomendada de iniciar programas X11 en un sitio remoto es con algo como ssh -f equipo xterm.

Si la opción de configuración ExitOnForwardFailure está establecida en “yes”, un cliente iniciado con -f esperará a que se establezcan correctamente todos los reenvíos de puertos remotos antes de ejecutarse en segundo plano. Consulte la descripción de ForkAfterAuthentication en ssh_config(5) para obtener más detalles.

Hace que ssh muestre su configuración después de evaluar los bloques Host y Match y finalice.

Permite que los hosts remotos se conecten a puertos reenviados locales. Si se utiliza en una conexión multiplexada, esta opción debe especificarse en el proceso maestro.

pkcs11
Especifica la biblioteca compartida PKCS#11 que ssh debe utilizar para comunicarse con un token PKCS#11 que proporciona claves para la autenticación de usuarios.

archivo_identidad
Selecciona un archivo del cual se lee la identidad (clave privada) para la autenticación mediante clave pública. También es posible especificar un archivo de clave pública para utilizar la clave privada correspondiente que se encuentre cargada en ssh-agent(1), en caso de que el archivo de clave privada no esté disponible localmente. Los valores predeterminados son ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk y ~/.ssh/id_mldsa44_ed25519. También es posible especificar archivos de identidad para cada equipo en el archivo de configuración. Se pueden utilizar múltiples opciones -i (así como definir varias identidades en los archivos de configuración). Si no se han especificado certificados explícitamente mediante la directiva CertificateFile, ssh intentará cargar información de certificados a partir de los nombres de archivo resultantes de añadir -cert.pub a los nombres de los archivos de identidad.

destino
Se conecta al equipo de destino estableciendo primero una conexión ssh al equipo de salto descrito por destino y, a continuación, estableciendo un reenvío TCP al destino final desde allí. Se pueden definir varios saltos separados por comas. Las direcciones IPv6 se pueden indicar encerrándolas entre corchetes. Esto es un atajo para especificar una directiva de configuración ProxyJump. Tenga en cuenta que las directivas de configuración proporcionadas en la línea de órdenes generalmente se aplican al equipo de destino y no a los equipos de salto especificados. Utilice ~/.ssh/config para especificar la configuración de los equipos de salto.

Habilita la autenticación basada en GSSAPI y el reenvío (delegación) de credenciales GSSAPI al servidor.

Deshabilita el reenvío (delegación) de credenciales GSSAPI al servidor.

[dirección_enlace:]puerto:equipo:puerto_equipo
 
[dirección_enlace:]puerto:socket_remoto
 
socket_local:equipo:puerto_equipo
 
socket_local:socket_remoto
Define que las conexiones al puerto TCP o al socket Unix indicado en el equipo local (cliente) se reenvíen al equipo y puerto, o al socket Unix, del lado remoto. Esto funciona asignando un socket que escucha en el puerto o socket Unix local. Cada vez que se establece una conexión con este puerto o socket, la conexión se reenvía por el canal seguro y el equipo remoto se conecta al destino indicado.

Los reenvíos de puertos también se pueden definir en el archivo de configuración. Solo el administrador puede reenviar puertos privilegiados. Las direcciones IPv6 se pueden especificar encerrándolas entre corchetes.

De forma predeterminada, el puerto local se enlaza de acuerdo con el valor de GatewayPorts. No obstante, se puede utilizar una dirección_enlace explícita para enlazar la conexión a una dirección concreta. La dirección_enlace “localhost” indica que el puerto de escucha se enlaza únicamente para uso local, mientras que una dirección vacía o ‘*’ indica que el puerto debe estar disponible en todas las interfaces.

nombre_usuario
Especifica el usuario con el que se iniciará sesión en el equipo remoto. También se puede especificar para cada equipo en el archivo de configuración.

Pone el cliente ssh en modo “maestro” para compartir conexiones. Si se especifica -M varias veces, ssh entra en modo “maestro”, pero exige confirmación mediante ssh-askpass(1) antes de cada operación que cambie el estado de la multiplexación (por ejemplo, abrir o cerrar una sesión). Consulte la descripción de ControlMaster en ssh_config(5) para obtener más información.

mac_spec
Una lista de algoritmos MAC (códigos de autenticación de mensajes) separados por comas y ordenados por preferencia. Consulte la palabra clave MACs en ssh_config(5) para obtener más información.

No ejecuta ninguna orden remota. Resulta útil cuando solo se desea reenviar puertos. Consulte la descripción de SessionType en ssh_config(5) para obtener más información.

Redirige la entrada estándar desde /dev/null (en realidad, impide leer de la entrada estándar). Debe usarse cuando ssh se ejecuta en segundo plano. Un truco habitual es utilizar esta opción para ejecutar programas X11 en un equipo remoto. Por ejemplo, ssh -n shadows.cs.hut.fi emacs & iniciará Emacs en shadows.cs.hut.fi y la conexión X11 se reenviará automáticamente a través de un canal cifrado. El programa ssh se ejecutará en segundo plano. (Esto no funciona si ssh necesita solicitar una contraseña o frase de contraseña; consulte también la opción -f.)

ctl_cmd
Controla un proceso maestro activo de multiplexación de conexiones. Cuando se especifica la opción -O, el argumento orden_control se interpreta y se pasa al proceso maestro. Las órdenes válidas son:

Comprueba que el proceso maestro esté en ejecución.
Muestra información sobre la conexión maestra.
Muestra información sobre los canales abiertos.
Solicita reenvíos sin ejecutar ninguna orden.
Cancela los reenvíos.
Se conecta en modo proxy a un proceso maestro de multiplexación que esté en ejecución.
Solicita al proceso maestro que termine.
Solicita al proceso maestro que deje de aceptar nuevas solicitudes de multiplexación.

opción
Permite especificar opciones con el formato utilizado en el archivo de configuración. Resulta útil para indicar opciones que no tienen una opción específica en la línea de órdenes. Para obtener información detallada sobre las opciones y sus valores, consulte ssh_config(5).

etiqueta
Especifica un nombre de etiqueta que puede utilizarse para seleccionar la configuración en ssh_config(5). Consulte las palabras clave Tag y Match en ssh_config(5) para obtener más información.

puerto
Puerto al que conectarse en el equipo remoto. También se puede especificar para cada equipo en el archivo de configuración.

opción_consulta
Consulta los algoritmos admitidos para una de las siguientes características:

cifrados simétricos compatibles
cifrados simétricos compatibles que admiten cifrado autenticado
términos de consulta compatibles que se pueden usar con la opción -Q
códigos de integridad de mensajes compatibles
algoritmos de intercambio de claves
tipos de clave
algoritmos de firma de CA válidos para certificados
tipos de clave para certificados
tipos de clave que no son de certificado
todos los tipos de clave y algoritmos de firma
versiones del protocolo SSH compatibles
algoritmos de firma admitidos

Como alias de la opción query_option, también se puede usar cualquier palabra clave de ssh_config(5) o sshd_config(5) que acepte una lista de algoritmos.

Modo silencioso. Suprime la mayoría de los mensajes de advertencia y diagnóstico.

[dirección_enlace:]puerto:equipo:puerto_equipo
 
[dirección_enlace:]puerto:socket_local
 
socket_remoto:equipo:puerto_equipo
 
socket_remoto:socket_local
 
[dirección_enlace:]puerto
Especifica que las conexiones al puerto TCP o al socket Unix indicado en el equipo remoto (servidor) se reenvíen al lado local.

Esto se consigue asignando un socket que escucha en el puerto TCP o en un socket Unix del lado remoto. Cada vez que se establece una conexión con ese puerto o socket Unix, la conexión se reenvía por el canal seguro y se establece una conexión desde el equipo local hacia un destino explícito indicado por equipo y el puerto_equipo, hacia socket_local o, si no se ha indicado un destino explícito, ssh actúa como proxy SOCKS 4/5 y reenvía las conexiones a los destinos solicitados por el cliente SOCKS remoto.

Los reenvíos de puertos también se pueden especificar en el archivo de configuración. Solo se pueden reenviar puertos privilegiados si se inicia sesión como root en el equipo remoto. Las direcciones IPv6 se pueden especificar encerrándolas entre corchetes.

De forma predeterminada, los sockets TCP de escucha del servidor se enlazan únicamente a la interfaz de bucle local. Esto se puede cambiar especificando una dirección_enlace. Una dirección_enlace vacía o la dirección ‘*’ indica que el socket remoto debe escuchar en todas las interfaces. La especificación de una dirección_enlace remota solo tendrá éxito si está habilitada la opción GatewayPorts del servidor (consulte sshd_config(5)).

Si el argumento puerto es ‘0’, el servidor asignará dinámicamente el puerto de escucha e informará al cliente en tiempo de ejecución. Si se usa junto con -O forward, el puerto asignado se mostrará en la salida estándar.

ctl_path
Especifica la ubicación de un socket de control para compartir conexiones, o la cadena “none” para desactivar esta función. Consulte las descripciones de ControlPath y ControlMaster en ssh_config(5).

Se puede usar para solicitar la invocación de un subsistema en el sistema remoto. Los subsistemas facilitan el uso de SSH como transporte seguro para otras aplicaciones (por ejemplo, sftp(1)). El subsistema se especifica como la orden remota. Consulte la descripción de SessionType en ssh_config(5).

Desactiva la asignación de seudoterminal.

Fuerza la asignación de un seudoterminal. Esto permite ejecutar programas de pantalla arbitrarios en un equipo remoto, lo que puede resultar muy útil, por ejemplo, para implementar servicios de menús. Si se especifica -t varias veces, se fuerza la asignación de un terminal aunque ssh no tenga un terminal local.

Muestra el número de versión y termina.

Modo detallado. Hace que ssh muestre mensajes de depuración sobre su progreso. Esto ayuda a diagnosticar problemas de conexión, autenticación y configuración. Cada opción -v adicional aumenta el nivel de detalle. El máximo es 3.

equipo:puerto
Solicita que la entrada y la salida estándar del cliente se reenvíen a equipo en el puerto indicado a través del canal seguro. Implica -N, -T, ExitOnForwardFailure y ClearAllForwardings, aunque estas opciones se pueden modificar en el archivo de configuración o mediante opciones de la línea de órdenes con -o.

dispositivo_túnel_local[:dispositivo_túnel_remoto]
Solicita el reenvío de dispositivos de túnel mediante los dispositivos tun(4) especificados entre el cliente (dispositivo_túnel_local) y el servidor (dispositivo_túnel_remoto).

Los dispositivos se pueden indicar mediante un identificador numérico o la palabra clave “any”, que utiliza el siguiente dispositivo de túnel disponible. Si no se especifica dispositivo_túnel_remoto, su valor predeterminado es “any”. Consulte también las directivas Tunnel y TunnelDevice en ssh_config(5).

Si no se establece la directiva Tunnel, se utilizará el modo de túnel predeterminado, “point-to-point”. Si se desea otro modo de reenvío Tunnel, debe especificarse antes de -w.

Habilita el reenvío de X11. También se puede especificar para cada equipo en un archivo de configuración.

El reenvío de X11 debe habilitarse con precaución. Los usuarios que puedan eludir los permisos de archivo en el equipo remoto (en la base de datos de autorización X del usuario) pueden acceder a la pantalla X11 local mediante la conexión reenviada. Un atacante podría entonces realizar acciones como registrar las pulsaciones del teclado.

Por este motivo, el reenvío de X11 está sujeto de forma predeterminada a las restricciones de la extensión X11 SECURITY. Consulte la opción -Y de ssh y la directiva ForwardX11Trusted en ssh_config(5) para obtener más información.

(Específico de Debian: el reenvío de X11 no está sujeto de forma predeterminada a las restricciones de la extensión X11 SECURITY, porque actualmente demasiados programas se bloquean en este modo. Establezca la opción ForwardX11Trusted en “no” para restaurar el comportamiento de la versión original. Esto podría cambiar en el futuro en función de las mejoras del lado del cliente.)

Deshabilita el reenvío de X11.

Habilita el reenvío de X11 de confianza. Este tipo de reenvío no está sujeto a los controles de la extensión X11 SECURITY.

(Específico de Debian: en la configuración predeterminada, esta opción equivale a -X, ya que ForwardX11Trusted tiene el valor predeterminado “yes”, como se ha indicado más arriba. Establezca la opción ForwardX11Trusted en “no” para restaurar el comportamiento de la versión original. Esto podría cambiar en el futuro en función de las mejoras del lado del cliente.)

Envía la información de registro mediante el módulo del sistema syslog(3). De forma predeterminada, esta información se envía a la salida de error estándar.

Muestra, en orden de preferencia, las claves públicas que se intentarían para autenticar con el destino especificado y termina.

ssh también puede obtener datos de configuración de un archivo de configuración por usuario y de otro para todo el sistema. El formato del archivo y las opciones de configuración se describen en ssh_config(5).

AUTENTICACIÓN

El cliente SSH de OpenSSH admite el protocolo SSH 2.

Los métodos de autenticación disponibles son: autenticación basada en GSSAPI, autenticación basada en el host, autenticación mediante clave pública, autenticación interactiva mediante teclado y autenticación mediante contraseña. Los métodos se prueban en el orden indicado, aunque se puede cambiar el orden predeterminado con PreferredAuthentications.

La autenticación basada en el host funciona así: se permite considerar el inicio de sesión si el equipo desde el que se conecta el usuario aparece en /etc/hosts.equiv o /etc/ssh/shosts.equiv del equipo remoto, el usuario no es root y los nombres de usuario coinciden en ambos extremos; o si los archivos ~/.rhosts o ~/.shosts del directorio personal del usuario en el equipo remoto contienen una línea con el nombre del equipo cliente y el nombre del usuario en ese equipo. Además, el servidor poder verificar la clave del host cliente (consulte las descripciones de /etc/ssh/ssh_known_hosts y ~/.ssh/known_hosts más abajo) para permitir el inicio de sesión. Este método de autenticación cierra brechas de seguridad debidas a la suplantación de IP, DNS y rutas. [Nota para el administrador: /etc/hosts.equiv, ~/.rhosts y, en general, los protocolos rlogin/rsh son intrínsecamente inseguros y deben deshabilitarse si se desea seguridad.]

La autenticación mediante clave pública funciona así: el método se basa en criptografía de clave pública, con sistemas criptográficos en los que el cifrado y el descifrado utilizan claves distintas y no es factible deducir la clave de descifrado a partir de la de cifrado. Cada usuario crea un par de claves pública/privada para autenticarse. El servidor conoce la clave pública y solo el usuario conoce la clave privada. ssh implementa automáticamente la autenticación mediante clave pública con uno de los algoritmos ECDSA, Ed25519 o RSA.

El archivo ~/.ssh/authorized_keys enumera las claves públicas que permiten iniciar sesión. Al iniciar sesión, ssh indica al servidor qué par de claves desea utilizar para autenticarse. El cliente demuestra que tiene acceso a la clave privada y el servidor comprueba que la clave pública correspondiente está autorizada para acceder a la cuenta.

El servidor puede informar al cliente de los errores que impidieron completar correctamente la autenticación mediante clave pública después de que la autenticación se haya realizado con otro método. Estos errores se pueden consultar aumentando LogLevel a DEBUG o un nivel superior (por ejemplo, mediante la opción -v).

El usuario crea su par de claves ejecutando ssh-keygen(1). Esto guarda la clave privada en el siguiente archivo del directorio personal del usuario y la clave pública en el mismo directorio, con el sufijo .pub añadido al nombre:

~/.ssh/id_ecdsa
ECDSA
~/.ssh/id_ecdsa_sk
ECDSA alojada en un autenticador
~/.ssh/id_ed25519
Ed25519
~/.ssh/id_ed25519_sk
Ed25519 alojada en un autenticador
~/.ssh/id_mldsa44_ed25519
MLDSA44-ED25519
~/.ssh/id_rsa
RSA

A continuación, el usuario debe copiar la clave pública a ~/.ssh/authorized_keys en su directorio personal del equipo remoto. El archivo authorized_keys equivale al archivo convencional ~/.rhosts y contiene una clave por línea, aunque estas pueden ser muy largas. Después, el usuario podrá iniciar sesión sin introducir la contraseña.

Existe una variante de la autenticación mediante clave pública denominada autenticación mediante certificados: en lugar de un conjunto de claves pública/privada, se utilizan certificados firmados. Esto permite utilizar una única autoridad de certificación de confianza en lugar de muchas claves públicas/privadas. Consulte la sección CERTIFICATES de ssh-keygen(1) para obtener más información.

La forma más cómoda de utilizar la autenticación mediante clave pública o certificados puede ser mediante un agente de autenticación. Consulte ssh-agent(1) y, opcionalmente, la directiva AddKeysToAgent en ssh_config(5).

La autenticación interactiva mediante teclado funciona así: el servidor envía un texto de "desafío" arbitrario y solicita una respuesta, posiblemente varias veces. Entre los ejemplos de este método están la autenticación BSD (consulte login.conf(5)) y PAM (en algunos sistemas non-OpenBSD).

Por último, si fallan los demás métodos de autenticación, ssh solicita al usuario una contraseña. La contraseña se envía al equipo remoto para comprobarla; sin embargo, como todas las comunicaciones están cifradas, nadie que escuche en la red puede verla.

ssh mantiene y consulta automáticamente una base de datos con la identificación de todos los equipos con los que se ha utilizado. Las claves de equipo se guardan en ~/.ssh/known_hosts, dentro del directorio personal del usuario. También se consulta automáticamente el archivo /etc/ssh/ssh_known_hosts para identificar equipos conocidos. Los equipos nuevos se añaden automáticamente al archivo del usuario. Si cambia la identificación de un equipo, ssh lo advierte y deshabilita la autenticación mediante contraseña para evitar la suplantación del servidor o ataques de intermediario, que de otro modo podrían eludir el cifrado. La opción StrictHostKeyChecking permite controlar el inicio de sesión en equipos cuya clave de equipo se desconoce o ha cambiado.

Cuando el servidor acepta la identidad del usuario, ejecuta la orden indicada en una sesión no interactiva o, si no se ha especificado ninguna orden, inicia sesión en el equipo y proporciona al usuario una shell normal en una sesión interactiva. Toda comunicación con la orden o la shell remota se cifra automáticamente.

Si se solicita una sesión interactiva, ssh solo solicita de forma predeterminada un seudoterminal (pty) cuando el cliente dispone de uno. Las opciones -T y -t permiten cambiar este comportamiento.

Si se ha asignado un seudoterminal, el usuario puede utilizar los caracteres de escape que se describen a continuación.

Si no se ha asignado un seudoterminal, la sesión es transparente y permite transferir datos binarios de forma fiable. En la mayoría de los sistemas, establecer el carácter de escape en “none” también hace que la sesión sea transparente aunque se utilice un terminal.

La sesión termina cuando finaliza la orden o la shell del equipo remoto y se han cerrado todas las conexiones X11 y TCP.

CARACTERES DE ESCAPE

Cuando se solicita un seudoterminal, ssh admite varias funciones mediante un carácter de escape.

Se puede enviar una tilde aislada como ~~ o escribiendo después de la tilde un carácter distinto de los que se describen a continuación. El carácter de escape siempre debe ir precedido de un salto de línea para interpretarse como especial. Se puede cambiar en los archivos de configuración mediante la directiva EscapeChar o en la línea de órdenes con la opción -e.

Los caracteres de escape admitidos (suponiendo que se use la tilde predeterminada ‘~’) son:

Desconecta.
Pasa ssh a segundo plano.
Enumera las conexiones reenviadas.
Pasa ssh a segundo plano al cerrar sesión mientras espera a que terminen las sesiones con conexiones reenviadas o X11.
Muestra una lista de los caracteres de escape.
Envía una señal BREAK al sistema remoto (solo es útil si el otro extremo la admite).
Abre la línea de órdenes. Actualmente permite añadir reenvíos de puertos mediante las opciones -L, -R y -D (véase más arriba). También permite cancelar reenvíos existentes mediante -KL[dirección_enlace:]puerto para reenvíos locales, -KR[dirección_enlace:]puerto para remotos y -KD[dirección_enlace:]puerto para dinámicos. !orden permite ejecutar una orden local si la opción PermitLocalCommand está habilitada en ssh_config(5). Se puede obtener ayuda básica con la opción -h.
Muestra información sobre la conexión SSH actual.
Solicita volver a generar las claves de la conexión (solo es útil si el otro extremo lo admite).
Reduce el nivel de detalle (LogLevel) cuando se escriben errores en la salida de error estándar.
Aumenta el nivel de detalle (LogLevel) cuando se escriben errores en la salida de error estándar.

REENVÍO TCP

El reenvío de conexiones TCP arbitrarias a través de un canal seguro se puede especificar en la línea de órdenes o en un archivo de configuración. Una aplicación posible es conectarse de forma segura a un servidor de correo; otra es atravesar cortafuegos.

En el ejemplo siguiente se cifra la comunicación de un cliente IRC, aunque el servidor IRC al que se conecta no admita directamente comunicaciones cifradas. El usuario se conecta al equipo remoto con ssh e indica los puertos que se utilizarán para reenviar la conexión. Después puede iniciar el programa localmente y ssh cifrará y reenviará la conexión al servidor remoto.

El siguiente ejemplo crea un túnel para una sesión IRC desde el cliente hasta un servidor IRC en “server.example.com”, y se une al canal “#users” con el apodo “pinky”, usando el puerto IRC estándar, 6667:

$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1

La opción -f pone ssh en segundo plano y especifica la orden remota “sleep 10” para dejar tiempo (10 segundos en este ejemplo) para iniciar el programa que utilizará el túnel. Si no se establece ninguna conexión durante el tiempo indicado, ssh termina.

REENVÍO X11

Si la variable ForwardX11 está establecida en “yes” (o se usan las opciones -X, -x o -Y descritas anteriormente) y el usuario utiliza X11 (la variable de entorno DISPLAY está definida), la conexión a la pantalla X11 se reenvía automáticamente al lado remoto, de modo que los programas X11 iniciados desde la shell o la orden utilizan el canal cifrado y se conectan al servidor X real desde el equipo local. El usuario no debe establecer manualmente DISPLAY. El reenvío de conexiones X11 se puede configurar en la línea de órdenes o en los archivos de configuración.

El valor de DISPLAY establecido por ssh apunta al equipo servidor, pero con un número de pantalla superior a cero. Esto es normal: ssh crea un servidor X “proxy” en el equipo servidor para reenviar las conexiones por el canal cifrado.

ssh también configura automáticamente los datos de Xauthority en el equipo servidor. Para ello, genera una cookie de autorización aleatoria, la guarda en Xauthority en el servidor y comprueba que todas las conexiones reenviadas incluyan esa cookie; al abrir la conexión, la sustituye por la cookie real. La cookie de autenticación real nunca se envía al equipo servidor (y no se envían cookies en texto claro).

Si la variable ForwardAgent está establecida en “yes” (o se usan las opciones -A o -a descritas anteriormente) y el usuario utiliza un agente de autenticación, la conexión con el agente se reenvía automáticamente al lado remoto.

VERIFICACIÓN DE CLAVES DE EQUIPOS

Al conectarse a un servidor por primera vez, se muestra al usuario la huella digital de la clave pública del servidor (salvo que se haya deshabilitado la opción StrictHostKeyChecking). Las huellas digitales se pueden obtener mediante ssh-keygen(1):

$ ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key

Si la huella digital ya se conoce, se puede comparar con la mostrada y aceptar o rechazar la clave. Si solo se dispone de huellas digitales antiguas (MD5) del servidor, se puede utilizar la opción -E de ssh-keygen(1) para reducir el algoritmo de huella digital y hacerlo coincidir.

Como es difícil comparar claves de equipo observando únicamente las cadenas de huellas digitales, también se pueden comparar visualmente mediante . Si se establece la opción VisualHostKey en “yes”, se muestra un pequeño gráfico ASCII cada vez que se inicia sesión en un servidor, tanto en sesiones interactivas como en las demás. Al aprender el patrón de un servidor conocido, el usuario puede detectar fácilmente si la clave de equipo ha cambiado porque aparece un patrón completamente distinto. Sin embargo, estos patrones no son inequívocos: un patrón que se parezca al recordado solo indica una probabilidad alta de que la clave sea la misma, no una prueba definitiva.

Para obtener una lista de las huellas digitales y su arte aleatorio de todos los equipos conocidos, se puede usar la siguiente línea de órdenes:

$ ssh-keygen -lv -f ~/.ssh/known_hosts

Si se desconoce la huella digital, existe un método alternativo de verificación: comprobar las huellas SSH mediante DNS. Se añade un registro de recursos (RR) SSHFP al archivo de zona, y el cliente que se conecta puede comparar la huella con la de la clave presentada.

En este ejemplo, conectamos un cliente a un servidor, “host.example.com”. Primero deben añadirse los registros de recursos SSHFP al archivo de zona de host.example.com:

$ ssh-keygen -r host.example.com.

Las líneas de salida deben añadirse al archivo de zona. Para comprobar que la zona responde a las consultas de huellas digitales:

$ dig -t SSHFP host.example.com

Por último, el cliente se conecta:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Consulte la opción VerifyHostKeyDNS en ssh_config(5) para obtener más información.

REDES PRIVADAS VIRTUALES BASADAS EN SSH

ssh admite túneles de redes privadas virtuales (VPN) mediante el pseudodispositivo de red tun(4), lo que permite unir dos redes de forma segura. La opción de configuración PermitTunnel de sshd_config(5) controla si el servidor admite esta función y en qué nivel (tráfico de capa 2 o 3).

El siguiente ejemplo conecta la red del cliente 10.0.50.0/24 con la red remota 10.0.99.0/24 mediante una conexión punto a punto desde 10.1.1.1 hasta 10.1.1.2, siempre que el servidor SSH de la pasarela a la red remota, en 192.168.1.15, lo permita.

En el lado del cliente:

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

En el lado del servidor:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

El acceso del cliente se puede ajustar con más precisión mediante el archivo /root/.ssh/authorized_keys (véase más abajo) y la opción del servidor PermitRootLogin. La siguiente entrada permitiría conexiones al dispositivo tun(4) 1 del usuario “jane” y al dispositivo de túnel 2 del usuario “john”, si PermitRootLogin está establecido en “forced-commands-only”:

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Como una configuración basada en SSH conlleva una sobrecarga considerable, puede resultar más adecuada para configuraciones temporales, como las VPN inalámbricas. Para VPN más permanentes son preferibles herramientas como ipsecctl(8) y isakmpd(8).

ENTORNO

Normalmente, ssh establece las siguientes variables de entorno:

La variable DISPLAY indica la ubicación del servidor X11. ssh la establece automáticamente con un valor del formato “nombre_equipo:n”, donde “nombre_equipo” indica el equipo en el que se ejecuta la shell y ‘n’ es un entero ≥ 1. ssh utiliza este valor especial para reenviar conexiones X11 por el canal seguro. Normalmente, el usuario no debe establecer DISPLAY de forma explícita, ya que la conexión X11 dejaría de ser segura y tendría que copiar manualmente las cookies de autorización necesarias.
Se establece con la ruta del directorio personal del usuario.
Sinónimo de USER; se establece por compatibilidad con sistemas que utilizan esta variable.
Se establece con la ruta del buzón de correo del usuario.
Se establece con el valor predeterminado de PATH, especificado al compilar ssh.
Si ssh necesita una frase de contraseña y se ejecuta desde un terminal, la lee del terminal actual. Si ssh no está asociado a un terminal, pero están definidas DISPLAY y SSH_ASKPASS, ejecuta el programa indicado por SSH_ASKPASS y abre una ventana X11 para leer la frase de contraseña. Esto resulta especialmente útil al invocar ssh desde .xsession o un script similar. (En algunos equipos puede ser necesario redirigir la entrada desde /dev/null para que funcione.)
Permite controlar mejor el uso de un programa askpass. Si esta variable se establece en “never”, ssh nunca intentará usarlo. Si se establece en “prefer”, ssh preferirá utilizar el programa askpass en lugar del terminal al solicitar contraseñas. Por último, si se establece en “force”, se utilizará el programa askpass para todas las entradas de frases de contraseña, independientemente de que DISPLAY esté definido.
Identifica la ruta de un socket UNIX-dominio utilizado para comunicarse con el agente.
Identifica los extremos cliente y servidor de la conexión. La variable contiene cuatro valores separados por espacios: dirección IP del cliente, número de puerto del cliente, dirección IP del servidor y número de puerto del servidor.
Esta variable contiene la línea de órdenes original cuando se ejecuta una orden forzada. Se puede utilizar para extraer los argumentos originales.
Se establece con el nombre del terminal (ruta al dispositivo) asociado a la shell o la orden actual. Si la sesión actual no tiene terminal, esta variable no se establece.
La establece opcionalmente sshd(8) con los nombres de las interfaces asignadas si el cliente solicitó el reenvío de túnel.
La establece opcionalmente sshd(8); puede contener la ruta de un archivo que enumera los métodos de autenticación utilizados correctamente al establecer la sesión, incluidas las claves públicas que se utilizaron.
Esta variable indica la zona horaria actual si estaba definida cuando se inició el demonio (es decir, el demonio transmite ese valor a las nuevas conexiones).
Se establece con el nombre del usuario que inicia sesión.

Además, ssh lee ~/.ssh/environment y añade al entorno líneas con el formato “NOMBRE_VARIABLE=valor” si el archivo existe y se permite a los usuarios modificar su entorno. Para obtener más información, consulte la opción PermitUserEnvironment en sshd_config(5).

ARCHIVOS

~/.rhosts
Este archivo se utiliza para la autenticación basada en el equipo (véase más arriba). En algunos equipos debe ser legible por todos si el directorio personal del usuario está en una partición NFS, porque sshd(8) lo lee como root. Además, el archivo debe pertenecer al usuario y nadie más debe tener permiso de escritura. En la mayoría de los equipos se recomiendan permisos de lectura y escritura para el usuario, sin acceso para los demás.

~/.shosts
Este archivo se utiliza exactamente igual que .rhosts, pero permite la autenticación basada en el equipo sin permitir el inicio de sesión mediante rlogin/rsh.

~/.ssh/
Este directorio es la ubicación predeterminada de toda la información de configuración y autenticación específica del usuario. No existe una obligación general de mantener en secreto todo su contenido, pero se recomiendan permisos de lectura, escritura y ejecución para el usuario, sin acceso para los demás.

~/.ssh/authorized_keys
Enumera las claves públicas (ECDSA, Ed25519, RSA) que se pueden utilizar para iniciar sesión como este usuario. El formato del archivo se describe en la página de manual sshd(8). El archivo no contiene información especialmente sensible, pero se recomiendan permisos de lectura y escritura para el usuario, sin acceso para los demás.

~/.ssh/config
Este es el archivo de configuración específico del usuario. El formato y las opciones de configuración se describen en ssh_config(5). Debido al posible uso indebido, el archivo debe tener permisos estrictos: lectura y escritura para el usuario, y sin permiso de escritura para los demás. Puede tener permiso de escritura para el grupo si este solo contiene al usuario.

~/.ssh/environment
Contiene definiciones adicionales de variables de entorno; véase más arriba ENVIRONMENT.

~/.ssh/id_ecdsa
 
~/.ssh/id_ecdsa_sk
 
~/.ssh/id_ed25519
 
~/.ssh/id_ed25519_sk
 
~/.ssh/id_mldsa44_ed25519
 
~/.ssh/id_rsa
Contiene la clave privada para la autenticación. Estos archivos contienen datos sensibles y deben ser legibles por el usuario, pero no accesibles para los demás. ssh ignora cualquier archivo de clave privada al que puedan acceder otros usuarios. Al generar la clave se puede especificar una frase de contraseña que se utilizará para cifrar con AES-128 la parte sensible de este archivo.

~/.ssh/id_ecdsa.pub
 
~/.ssh/id_ecdsa_sk.pub
 
~/.ssh/id_ed25519.pub
 
~/.ssh/id_ed25519_sk.pub
 
~/.ssh/id_mldsa44_ed25519.pub
 
~/.ssh/id_rsa.pub
Contiene la clave pública para la autenticación. Estos archivos no son sensibles y pueden ser legibles por cualquiera, aunque no es obligatorio.

~/.ssh/known_hosts
Contiene una lista de las claves de equipo de todos los equipos en los que el usuario ha iniciado sesión y que aún no figuran en la lista de claves conocidas de todo el sistema. Consulte sshd(8) para obtener más información sobre el formato de este archivo.

~/.ssh/rc
ssh ejecuta las órdenes de este archivo cuando el usuario inicia sesión, justo antes de iniciar su shell u orden. Consulte la página de manual sshd(8) para obtener más información.

/etc/hosts.equiv
Este archivo se utiliza para la autenticación basada en el equipo (véase más arriba). Solo root debe tener permiso de escritura.

/etc/ssh/shosts.equiv
Este archivo se utiliza exactamente igual que hosts.equiv, pero permite la autenticación basada en el equipo sin permitir el inicio de sesión mediante rlogin/rsh.

/etc/ssh/ssh_config
Archivo de configuración de todo el sistema. El formato del archivo y las opciones de configuración se describen en ssh_config(5).

/etc/ssh/ssh_host_ecdsa_key
 
/etc/ssh/ssh_host_ed25519_key
 
/etc/ssh/ssh_host_mldsa44_ed25519_key
 
/etc/ssh/ssh_host_rsa_key
Estos archivos contienen las partes privadas de las claves del equipo y se utilizan para la autenticación basada en el equipo.

/etc/ssh/ssh_known_hosts
Lista de todo el sistema de las claves de equipo conocidas. El administrador del sistema debe preparar este archivo con las claves públicas de todos los equipos de la organización. Debe ser legible por todos. Consulte sshd(8) para obtener más información sobre su formato.

/etc/ssh/sshrc
ssh ejecuta las órdenes de este archivo cuando el usuario inicia sesión, justo antes de iniciar su shell u orden. Consulte la página de manual sshd(8) para obtener más información.

ESTADO DE SALIDA

ssh termina con el estado de salida de la orden remota o con 255 si se ha producido un error.

VÉASE TAMBIÉN

scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

ESTÁNDARES

S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, January 2006.

J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, January 2006.

F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, January 2006.

J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, January 2006.

M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, January 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, January 2006.

M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006.

J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, November 2006.

D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, December 2009.

A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

AUTORES

OpenSSH deriva de la versión original y libre ssh 1.2.12, publicada por Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt y Dug Song corrigieron numerosos errores, recuperaron funciones más recientes y crearon OpenSSH. Markus Friedl contribuyó con la compatibilidad con las versiones 1.5 y 2.0 del protocolo SSH.

TRADUCCIÓN

La traducción al español de esta página del manual fue creada por Marcos Fouces <marcos@debian.org>

Esta traducción es documentación libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD.

Si encuentra algún error en la traducción de esta página del manual, envíe un correo electrónico a debian-l10n-spanish@lists.debian.org

$Mdocdate: 5 de septiembre de 2026 $ Nixpkgs