ssh — Cliente de inicio de sesión remoto OpenSSH
SINTAXIS
ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
[-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command [argument ...]]
ssh [-Q query_option]
DESCRIPCIÓN
ssh (cliente SSH) es un programa para iniciar sesión en una máquina remota y para ejecutar comandos en
una máquina remota. Está diseñado para proporcionar comunicaciones seguras y cifradas entre dos
hosts no confiables a través de una red no segura. Las conexiones X11, los puertos TCP arbitrarios
y los sockets de dominio Unix también se pueden reenviar a través del canal seguro.
ssh se conecta e inicia sesión en el destino especificado, que se puede especificar como
[usuario@]nombre de host o un URI del formulario ssh://[usuario@]nombre de host[:puerto]. El
usuario debe demostrar su identidad a la máquina remota utilizando uno de los varios métodos (vea
abajo).
Si se especifica un comando, se ejecutará en el host remoto en lugar de una shell de inicio de sesión. Se puede especificar una línea de comandos completa como comando, o puede tener argumentos adicionales. Si se proporciona, los argumentos se agregarán al comando, separados por espacios, antes de enviarlos al servidor para su ejecución.
Las opciones son las siguientes:
-4 Fuerza a ssh a usar solo direcciones IPv4.
-6 Fuerza a ssh a usar solo direcciones IPv6.
-A Habilita el reenvío de conexiones desde un agente de autenticación como ssh-agent(1).
Esto también se puede especificar por host en un archivo de configuración.
El reenvío de agentes debe habilitarse con precaución. Los usuarios con la capacidad de omitir los permisos de archivo en el host remoto (para el socket de dominio Unix del agente) pueden acceder al agente local a través de la conexión reenviada. Un atacante no puede obtener material de clave del agente, sin embargo, puede realizar operaciones en las claves que le permitan autenticarse usando las identidades cargadas en el agente. Una alternativa más segura puede ser usar un host de salto (vea -J).
-a Deshabilita el reenvío de la conexión del agente de autenticación.
-B bind_interface
Enlace a la dirección de bind_interface antes de intentar conectarse al destino host. Esto solo es útil en sistemas con más de una dirección.
-b bind_address
Utilice bind_address en la máquina local como la dirección de origen de la conexión. Solo es útil en sistemas con más de una dirección.
-C Solicita la compresión de todos los datos (incluidos stdin, stdout, stderr y los datos para conexiones X11, TCP y de dominio Unix reenviadas). El algoritmo de compresión es el mismo que se utiliza en [gzip]({filename}../../gzip)(1). La compresión es deseable 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 en una base por host en los archivos de configuración; consulte la opción Compresión en ssh_config(5) para obtener más información.
-c cipher_spec
Selecciona la especificación de cifrado para cifrar la sesión. cipher_spec es una lista separada por comas de cifrados enumerados en orden de preferencia. Consulte la palabra clave Cifrados en ssh_config(5) para obtener más información.
-D [bind_address:]port
Especifica un puerto de reenvío de nivel de aplicación "dinámico" local. Esto funciona asignando un socket para escuchar en el puerto del lado local, opcionalmente vinculado a la dirección especificada. Siempre que se realiza una conexión a este puerto, la conexión se reenvía a través del canal seguro y el protocolo de aplicación se utiliza para determinar a dónde conectarse desde la máquina remota. Actualmente, se admiten los protocolos SOCKS4 y SOCKS5, y ssh actuará como un servidor SOCKS. Solo el usuario root puede reenviar puertos privilegiados. Los reenvíos de puertos dinámicos también se pueden especificar en el archivo de configuración.
Las direcciones IPv6 se pueden especificar encerrando la dirección entre corchetes. Solo el superusuario puede reenviar puertos privilegiados. De forma predeterminada, el puerto local se vincula de acuerdo con la configuración de GatewayPorts. Sin embargo, se puede utilizar una dirección de enlace explícita para vincular la conexión a una dirección específica. La dirección de enlace de "localhost" indica que el puerto de escucha debe vincularse para uso local únicamente, mientras que una dirección vacía o '\*' indica que el puerto debe estar disponible desde todas las interfaces.
-E log_file
Agrega los registros de depuración a log_file en lugar de la salida de error estándar.
-e escape_char
Establece el carácter de escape para las 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 suspende la conexión; y seguido de sí mismo envía el carácter de escape una vez. Establecer el carácter en "none" desactiva cualquier escape y hace que la sesión sea completamente transparente.
-F configfile
Especifica un archivo de configuración alternativo por usuario. Si se proporciona un archivo de configuración en la línea de comandos, el archivo de configuración de todo el sistema (/etc/ssh/ssh_config) se ignorará. El valor predeterminado para el archivo de configuración por usuario es ~/.ssh/config. Si se establece en "none", no se leerá ningún archivo de configuración.
-f Solicita a ssh que pase al segundo plano justo antes de la ejecución del comando. Esto es útil si ssh va a solicitar contraseñas o frases de contraseña, pero el usuario desea que esté en segundo plano. Esto implica -n. La forma recomendada de iniciar programas X11 en un sitio remoto es con algo como ssh -f host xterm.
Si la opción de configuración ExitOnForwardFailure se establece en "sí", entonces un cliente iniciado con -f esperará a que se establezcan correctamente todos los reenvíos de puertos remotos antes de pasar a segundo plano. Consulte la descripción de ForkAfterAuthentication en ssh_config(5) para obtener más detalles.
-G: hace que ssh imprima su configuración después de evaluar los bloques `Host` y `Match` y salga.
-g: permite que los hosts remotos se conecten a los puertos reenviados locales. Si se usa en una conexión multiplexada, esta opción debe especificarse en el proceso maestro.
-I pkcs11: especifica la biblioteca compartida PKCS#11 que ssh debe usar para comunicarse con un token PKCS#11 que proporciona claves para la autenticación del usuario.
-i identity_file: selecciona un archivo del cual se lee la identidad (clave privada) para la autenticación de clave pública. También puede especificar un archivo de clave pública para usar la clave privada correspondiente que se carga en `ssh-agent(1)` cuando el archivo de clave privada no está presente localmente. El valor predeterminado es `~/.ssh/id_rsa`, `~/.ssh/id_ecdsa`, `~/.ssh/id_ecdsa_sk`, `~/.ssh/id_ed25519` y `~/.ssh/id_ed25519_sk`. Los archivos de identidad también se pueden especificar por host en el archivo de configuración. Es posible tener múltiples opciones `-i` (y múltiples identidades especificadas en los archivos de configuración). Si no se han especificado explícitamente certificados mediante la directiva `CertificateFile`, ssh también intentará cargar la información del certificado del nombre de archivo obtenido anexando `-cert.pub` a los nombres de archivo de identidad.
-J destination: se conecta al host de destino primero estableciendo una conexión ssh al host de salto descrito por `destination` y luego estableciendo un reenvío TCP al destino final desde allí. Se pueden especificar varios saltos separados por comas. Las direcciones IPv6 se pueden especificar encerrando la dirección entre corchetes. Esta es una forma abreviada de especificar una directiva `ProxyJump` de configuración. Tenga en cuenta que las directivas de configuración proporcionadas en la línea de comandos generalmente se aplican al host de destino y no a los hosts de salto especificados. Use `~/.ssh/config` para especificar la configuración de los hosts de salto.
-K: habilita la autenticación basada en GSSAPI y el reenvío (delegación) de credenciales GSSAPI al servidor.
-k: deshabilita el reenvío (delegación) de credenciales GSSAPI al servidor.
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Especifica que las conexiones al puerto TCP o socket Unix dado en el host local (cliente) deben reenviarse al host y puerto dado, o socket Unix, en el lado remoto. Esto funciona asignando un socket para escuchar en un puerto TCP en el lado local, opcionalmente enlazado a la dirección bind_address especificada, o a un socket Unix. Siempre que se realiza una conexión al puerto o socket local, la conexión se reenvía a través del canal seguro y se establece una conexión al puerto del host hostport, o al socket Unix remote_socket, desde la máquina remota.
Los reenvíos de puertos también se pueden especificar en el archivo de configuración. Solo el superusuario puede reenviar puertos privilegiados. Las direcciones IPv6 se pueden especificar encerrando la dirección entre corchetes.
Por defecto, el puerto local se enlaza de acuerdo con la configuración de GatewayPorts. Sin embargo, se puede utilizar una dirección de enlace explícita para enlazar la conexión a una dirección específica. La dirección de enlace de “localhost” indica que el puerto de escucha debe enlazarse para uso local únicamente, mientras que una dirección vacía o ‘*’ indica que el puerto debe estar disponible desde todas las interfaces.
-l nombre_de_usuario
Especifica el usuario con el que iniciar sesión en la máquina remota. Esto también se puede especificar por host en el archivo de configuración.
-M Coloca el cliente ssh en modo “maestro” para compartir la conexión. Múltiples opciones -M
colocan a ssh en modo “maestro”, pero requieren confirmación mediante ssh-askpass(1) antes de
cada operación que cambie el estado del multiplexado (por ejemplo, abrir una nueva sesión). Consulte
la descripción de ControlMaster en ssh_config(5) para obtener más detalles.
-m especificación_mac
Una lista separada por comas de algoritmos MAC (código de autenticación de mensajes), especificados en orden de preferencia. Consulte la palabra clave MACs en ssh_config(5) para obtener más información.
-N No ejecute un comando remoto. Esto es útil para simplemente reenviar puertos. Consulte la
descripción de SessionType en ssh_config(5) para obtener más detalles.
-n Redirige la entrada estándar desde /dev/null (en realidad, impide la lectura de la entrada estándar). Esto debe
utilizarse cuando ssh se ejecuta en segundo plano. Un truco común es usar esto para ejecutar programas X11 en una máquina remota. Por ejemplo, ssh -n shadows.cs.hut.fi emacs & iniciará un
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 colocará 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). Consulte la descripción de StdinNull en ssh_config(5) para obtener más detalles.
-O comando_ctl
Controla un proceso maestro de multiplexado de conexión activo. Cuando se especifica la opción -O, el argumento comando_ctl se interpreta y se pasa al proceso maestro. Los comandos válidos son: “check” (verificar que el proceso maestro se esté ejecutando), “forward” (solicitar reenvíos sin ejecución de comandos), “cancel” (cancelar reenvíos), “proxy” (conectar a un
proceso maestro de multiplexado en ejecución en modo proxy), “exit” (solicitar que el maestro
salga) y “stop” (solicitar que el maestro deje de aceptar más solicitudes de multiplexado).
-o opción
Se puede utilizar para proporcionar opciones en el formato utilizado en el archivo de configuración. Esto es útil
para especificar opciones para las que no existe una marca de línea de comandos separada. Para obtener detalles completos de las opciones que se enumeran a continuación y sus posibles valores, consulte ssh_config(5).
AddKeysToAgent
AddressFamily
BatchMode
BindAddress
BindInterface
CASignatureAlgorithms
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CertificateFile
ChannelTimeout
CheckHostIP
Ciphers
ClearAllForwardings
Compression
ConnectTimeout
ConnectionAttempts
ControlMaster
ControlPath
ControlPersist
DynamicForward
EnableEscapeCommandline
EnableSSHKeysign
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host
HostKeyAlgorithms
HostKeyAlias
HostbasedAcceptedAlgorithms
HostbasedAuthentication
Hostname
IPQoS
IdentitiesOnly
IdentityAgent
IdentityFile
IgnoreUnknown
Include
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
LogVerbose
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
ObscureKeystrokeTiming
PKCS11Provider
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
RequiredRSASize
RevokedHostKeys
SecurityKeyProvider
SendEnv
ServerAliveCountMax
ServerAliveInterval
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
SyslogFacility
TCPKeepAlive
Tag
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
-P tag Especifica un nombre de etiqueta que se puede utilizar 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.
-p port
Puerto al que conectarse en el host remoto. Esto se puede especificar de forma individual para cada host en el archivo de configuración.
-Q query_option
Consulta los algoritmos admitidos por una de las siguientes características: cipher (cifrados simétricos admitidos), cipher-auth (cifrados simétricos admitidos que admiten cifrado autenticado), help (términos de consulta admitidos para usar con la marca -Q), mac (códigos de integridad de mensajes admitidos), kex (algoritmos de intercambio de claves), kex-gss (algoritmos de intercambio de claves GSSAPI), key (tipos de clave), key-ca-sign (algoritmos de firma de CA válidos para certificados), key-cert (tipos de clave de certificado), key-plain (tipos de clave que no son de certificado), key-sig (todos los tipos de clave y algoritmos de firma), protocol-version (versiones de protocolo SSH admitidas) y sig (algoritmos de firma admitidos). Alternativamente, cualquier palabra clave de ssh_config(5) o sshd_config(5) que acepte una lista de algoritmos se puede utilizar como alias para la opción query_option correspondiente.
-q Modo silencioso. Provoca que la mayoría de los mensajes de advertencia y diagnóstico se supriman.
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
-R [bind_address:]port
Especifica que las conexiones al puerto TCP o socket Unix dado en el host remoto se deben reenviar al lado local.
Esto funciona asignando un socket para escuchar en un puerto TCP o en un socket Unix en el lado remoto. Cada vez que se realiza una conexión a este puerto o socket Unix, la conexión se reenvía a través del canal seguro y se establece una conexión desde la máquina local a un destino explícito especificado por host port hostport, o local_socket, o, si no se especificó un destino explícito, ssh actuará como un proxy SOCKS 4/5 y reenviará 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. Los puertos privilegiados solo se pueden reenviar cuando se inicia sesión como root en la máquina remota. Se pueden especificar las direcciones IPv6 encerrando la dirección entre corchetes.
De forma predeterminada, los sockets de escucha TCP en el servidor se enlazaran solo a la interfaz de bucle invertido. Esto se puede anular especificando una bind_address. Una bind_address vacía, o la dirección '*', indica que el socket remoto debe escuchar en todas las interfaces. Especificar una bind_address remota solo tendrá éxito si la opción GatewayPorts del servidor está habilitada (consulte sshd_config(5)).
Si el argumento de puerto es '0', el puerto de escucha se asignará dinámicamente en el servidor y se informará al cliente en tiempo de ejecución. Cuando se usa junto con -O forward, el puerto asignado se imprimirá en la salida estándar.
-S ctl_path
Especifica la ubicación de un socket de control para el uso compartido de conexiones, o la cadena "none" para deshabilitar el uso compartido de conexiones. Consulte la descripción de ControlPath y ControlMaster en ssh_config(5) para obtener más detalles.
-s Se puede usar para solicitar la invocación de un subsistema en el sistema remoto. Los subsistemas facilitan el uso de SSH como un transporte seguro para otras aplicaciones (por ejemplo, [sftp]({filename}../../sftp)(1)). El subsistema se especifica como el comando remoto. Consulte la descripción de SessionType en ssh_config(5) para obtener más detalles.
-T Deshabilitar la asignación de pseudo-terminal.
-t Forzar la asignación de pseudo-terminal. Esto se puede utilizar para ejecutar programas arbitrarios basados en pantalla en una máquina remota, lo que puede ser muy útil, por ejemplo, al implementar servicios de menú. Múltiples opciones -t fuerzan la asignación de tty, incluso si ssh no tiene un tty local.
-V Mostrar el número de versión y salir.
-v Modo detallado. Hace que ssh imprima mensajes de depuración sobre su progreso. Esto es útil para depurar problemas de conexión, autenticación y configuración. Múltiples opciones -v aumentan la verbosidad. El máximo es 3.
-W host:puerto
Solicita que la entrada y salida estándar del cliente se reenvíen a host en el puerto especificado a través del canal seguro. Implica -N, -T, ExitOnForwardFailure y ClearAllForwardings, aunque estos se pueden anular en el archivo de configuración o mediante las opciones de línea de comandos -o.
-w local_tun[:remote_tun]
Solicita el reenvío del dispositivo de túnel con los dispositivos tun(4) especificados entre el cliente (local_tun) y el servidor (remote_tun).
Los dispositivos se pueden especificar mediante un ID numérico o la palabra clave "cualquiera", que utiliza el siguiente dispositivo de túnel disponible. Si no se especifica `remote_tun`, se establece por defecto en "cualquiera". Consulte también las directivas `Tunnel` y `TunnelDevice` en `ssh_config(5)`.
Si la directiva `Tunnel` no está establecida, se establecerá en el modo de túnel predeterminado, que es "punto a punto". Si se desea un modo de reenvío de túnel diferente, se debe especificar antes de `-w`.
-X Habilita el reenvío de X11. Esto también se puede especificar por host en un archivo de configuración.
El reenvío de X11 debe habilitarse con precaución. Los usuarios que tengan la capacidad de omitir los permisos de archivo en el host remoto (para la base de datos de autorización X del usuario) pueden acceder a la pantalla X11 local a través de la conexión reenviada. Un atacante puede entonces ser capaz de realizar actividades como la monitorización de pulsaciones de teclas.
Por esta razón, el reenvío de X11 está sujeto a las restricciones de la extensión X11 SECURITY por defecto. Consulte la opción `ssh -Y` 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 a las restricciones de la extensión X11 SECURITY por defecto, porque demasiados programas fallan actualmente en este modo. Establezca la opción `ForwardX11Trusted` en "no" para restaurar el comportamiento upstream. Esto puede cambiar en el futuro dependiendo de las mejoras del lado del cliente).
-x Deshabilita el reenvío de X11.
-Y Habilita el reenvío de X11 de confianza. Los reenvíos de X11 de confianza no están sujetos a los controles de la extensión X11 SECURITY.
(Específico de Debian: En la configuración predeterminada, esta opción es equivalente a `-X`, ya que `ForwardX11Trusted` tiene por defecto "sí" como se describe anteriormente. Establezca la opción `ForwardX11Trusted` en "no" para restaurar el comportamiento upstream. Esto puede cambiar en el futuro dependiendo de las mejoras del lado del cliente).
-y Envía información de registro utilizando el módulo del sistema `syslog(3)`. Por defecto, esta información se envía a `stderr`.
`ssh` puede obtener además datos de configuración de un archivo de configuración por usuario y un archivo de configuración a nivel de sistema. El formato del archivo y las opciones de configuración se describen en `ssh_config(5)`.
AUTENTICACIÓN
El cliente SSH de OpenSSH soporta el protocolo SSH 2.
Los métodos disponibles para la autenticación son: autenticación basada en GSSAPI, autenticación basada en host, autenticación de clave pública, autenticación interactiva por teclado y autenticación por contraseña. Los métodos de autenticación se intentan en el orden especificado, aunque se puede utilizar PreferredAuthentications para cambiar el orden predeterminado.
La autenticación basada en el host funciona de la siguiente manera: si la máquina desde la que el usuario inicia sesión está incluida en /etc/hosts.equiv o /etc/ssh/shosts.equiv en la máquina remota, el usuario no es root y los nombres de usuario son los mismos en ambos lados, o si los archivos ~/.rhosts o ~/.shosts existen en el directorio de inicio del usuario en la máquina remota y contienen una línea que contiene el nombre de la máquina cliente y el nombre del usuario en esa máquina, el usuario se considera autorizado para iniciar sesión. Además, el servidor debe ser capaz de verificar la clave de host del cliente (vea la descripción de /etc/ssh/ssh_known_hosts y ~/.ssh/known_hosts, a continuación) para que se permita el inicio de sesión. Este método de autenticación cierra las brechas de seguridad debido al spoofing de IP, el spoofing de DNS y el spoofing de enrutamiento. [Nota para el administrador: /etc/hosts.equiv, ~/.rhosts y el protocolo rlogin/rsh en general, son inherentemente inseguros y deben desactivarse si se desea la seguridad.]
La autenticación de clave pública funciona de la siguiente manera: El esquema se basa en la criptografía de clave pública, utilizando sistemas criptográficos donde el cifrado y el descifrado se realizan utilizando claves separadas, y es inviable derivar la clave de descifrado de la clave de cifrado. La idea es que cada usuario crea un par de claves pública/privada para fines de autenticación. El servidor conoce la clave pública, y solo el usuario conoce la clave privada. ssh implementa el protocolo de autenticación de clave pública automáticamente, utilizando uno de los algoritmos ECDSA, Ed25519 o RSA.
El archivo ~/.ssh/authorized_keys enumera las claves públicas que están permitidas para iniciar sesión. Cuando el usuario inicia sesión, el programa ssh le indica al servidor qué par de claves le gustaría usar para la autenticación. El cliente prueba que tiene acceso a la clave privada y el servidor verifica que la clave pública correspondiente está autorizada para aceptar la cuenta.
El servidor puede informar al cliente de los errores que impidieron que la autenticación de clave pública tuviera éxito después de que se completa la autenticación utilizando un método diferente. Estos se pueden ver aumentando el LogLevel a DEBUG o superior (por ejemplo, utilizando la bandera -v).
El usuario crea su par de claves ejecutando ssh-keygen(1). Esto guarda la clave privada en ~/.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), o ~/.ssh/id_rsa (RSA) y guarda la clave pública en ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (ECDSA alojada en un autenticador), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (Ed25519 alojada en un autenticador), o ~/.ssh/id_rsa.pub (RSA) en el directorio de inicio del usuario. El usuario debe entonces copiar la clave pública a ~/.ssh/authorized_keys en su directorio de inicio en la máquina remota. El archivo authorized_keys corresponde al archivo ~/.rhosts convencional, y tiene una clave por línea, aunque las líneas pueden ser muy largas. Después de esto, el usuario puede iniciar sesión sin tener que proporcionar la contraseña.
Una variación de la autenticación de clave pública está disponible en forma de autenticación de certificados:
en lugar de un conjunto de claves pública/privada, se utilizan certificados firmados. Esto tiene la ventaja
de que se puede utilizar una única autoridad de certificación de confianza en lugar de muchas claves pública/privada.
Consulte la sección CERTIFICADOS de ssh-keygen(1) para obtener más información.
La forma más conveniente de utilizar la autenticación de clave pública o de certificados puede ser mediante un agente de autenticación. Consulte ssh-agent(1) y (opcionalmente) la directiva AddKeysToAgent en ssh\_config(5)
para obtener más información.
La autenticación interactiva por teclado funciona de la siguiente manera: el servidor envía un texto de "desafío" arbitrario
y solicita una respuesta, posiblemente varias veces. Los ejemplos de autenticación interactiva por teclado incluyen la autenticación BSD (consulte login.conf(5)) y PAM (en algunos sistemas que no son OpenBSD).
Por último, si otros métodos de autenticación fallan, ssh solicita al usuario una contraseña. La contraseña
se envía al host remoto para su comprobación; sin embargo, dado que todas las comunicaciones están cifradas, la
contraseña no puede ser vista por alguien que escuche en la red.
ssh mantiene y comprueba automáticamente una base de datos que contiene la identificación de todos los hosts con los que se ha
utilizado. Las claves de host se almacenan en ~/.ssh/known\_hosts en el directorio de inicio del usuario. Además, el archivo /etc/ssh/ssh\_known\_hosts se comprueba automáticamente para detectar hosts conocidos. Cualquier
nuevo host se añade automáticamente al archivo del usuario. Si la identificación de un host cambia alguna vez,
ssh advierte de esto y deshabilita la autenticación por contraseña para evitar la suplantación de servidor o ataques de tipo "man-in-the-middle",
que de otro modo podrían utilizarse para eludir el cifrado. La opción StrictHostKeyChecking se puede utilizar para controlar los inicios de sesión en máquinas cuya clave de host no se conoce o ha cambiado.
Cuando la identidad del usuario ha sido aceptada por el servidor, el servidor ejecuta el comando dado en una sesión no interactiva o, si no se ha especificado ningún comando, inicia sesión en la máquina
y proporciona al usuario una shell normal como sesión interactiva. Toda la comunicación con el comando o la shell remota se cifrará automáticamente.
Si se solicita una sesión interactiva, ssh por defecto solo solicitará un pseudo-terminal (pty)
para las sesiones interactivas cuando el cliente tenga uno. Las opciones -T y -t se pueden utilizar para anular
este comportamiento.
Si se ha asignado un pseudo-terminal, el usuario puede utilizar los caracteres de escape que se indican a continuación.
Si no se ha asignado un pseudo-terminal, la sesión es transparente y se puede utilizar para transferir datos binarios de forma fiable. En la mayoría de los sistemas, establecer el carácter de escape en "ninguno" también hará que la
sesión sea transparente incluso si se utiliza un tty.
La sesión finaliza cuando el comando o la shell en la máquina remota se cierra y todas las conexiones X11 y TCP se han cerrado.
CARACTERES DE ESCAPE
Cuando se ha solicitado un pseudoterminal, ssh admite varias funciones mediante el uso de un carácter de escape.
Se puede enviar un solo carácter de tilde como ~~ o siguiendo la tilde con un carácter que no sea uno de los descritos a continuación. El carácter de escape siempre debe seguir a una nueva línea para ser interpretado como especial. El carácter de escape se puede cambiar en los archivos de configuración utilizando la directiva de configuración EscapeChar o en la línea de comandos mediante la opción -e.
Los escapes admitidos (asumiendo la tilde predeterminada ‘\~’) son:
~. Desconectar.
~^Z Enviar ssh al fondo.
~# Listar las conexiones reenviadas.
~& Enviar ssh al fondo al cerrar la sesión cuando se está esperando a que terminen las conexiones reenviadas/sesiones X11.
~? Mostrar una lista de caracteres de escape.
~B Enviar una señal BREAK al sistema remoto (solo es útil si el par la admite).
~C Abrir una línea de comandos. Actualmente, esto permite agregar reenvíos de puertos utilizando las opciones -L, -R y -D (ver arriba). También permite cancelar los reenvíos de puertos existentes con -KL[dirección_enlace:]puerto para reenvíos de puertos locales, -KR[dirección_enlace:]puerto para reenvíos de puertos remotos y -KD[dirección_enlace:]puerto para reenvíos de puertos dinámicos. !comando permite al usuario ejecutar un comando local si la opción PermitLocalCommand está habilitada en ssh_config(5). Hay ayuda básica disponible, utilizando la opción -h.
~R Solicitar el re-cifrado de la conexión (solo es útil si el par la admite).
~V Disminuir la verbosidad (LogLevel) cuando se escriben errores en stderr.
~v Aumentar la verbosidad (LogLevel) cuando se escriben errores en stderr.
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 comandos o en un archivo de configuración. Una posible aplicación del reenvío TCP es una conexión segura a un servidor de correo; otra es atravesar firewalls.
En el ejemplo a continuación, vemos cómo cifrar la comunicación para un cliente IRC, incluso si el servidor IRC al que se conecta no admite directamente la comunicación cifrada. Esto funciona de la siguiente manera: el usuario se conecta al host remoto mediante ssh, especificando los puertos que se utilizarán para reenviar la conexión. Después de eso, es posible 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 a un servidor IRC en “server.example.com”, uniéndose al canal “#users”, con el nombre de usuario “pinky”, utilizando 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 envía ssh al fondo y se especifica el comando remoto “sleep 10” para permitir un tiempo (10 segundos en el ejemplo) para iniciar el programa que utilizará el túnel. Si no se realizan conexiones dentro del tiempo especificado, ssh se cerrará.
REDIRECCIONAMIENTO X11
Si la variable ForwardX11 está configurada en “yes” (o consulte la descripción de las opciones -X, -x e -Y anteriores) y el usuario está utilizando X11 (la variable de entorno DISPLAY está configurada), la conexión a la pantalla X11 se redirige automáticamente al lado remoto de tal manera que cualquier programa X11 que se inicie desde el shell (o comando) pasará por el canal cifrado, y la conexión al servidor X real se realizará desde la máquina local. El usuario no debe configurar la variable DISPLAY manualmente.
El redireccionamiento de las conexiones X11 se puede configurar en la línea de comandos o en los archivos de configuración.
El valor de DISPLAY establecido por ssh apuntará a la máquina del servidor, pero con un número de pantalla mayor que cero. Esto es normal, y ocurre porque ssh crea un servidor X “proxy” en la máquina del servidor para redirigir las conexiones a través del canal cifrado.
ssh también configurará automáticamente los datos de Xauthority en la máquina del servidor. Para este propósito, generará una cookie de autorización aleatoria, la almacenará en Xauthority en el servidor y verificará que cualquier conexión redirigida lleve esta cookie y la reemplazará con la cookie real cuando se abra la conexión. La cookie de autenticación real nunca se envía a la máquina del servidor (y ninguna cookie se envía en texto plano).
Si la variable ForwardAgent está configurada en “yes” (o consulte la descripción de las opciones -A y -a anteriores) y el usuario está utilizando un agente de autenticación, la conexión al agente se redirige automáticamente al lado remoto.
VERIFICACIÓN DE CLAVES DE HOST
Cuando se conecta a un servidor por primera vez, se presenta al usuario una huella digital de la clave pública del servidor (a menos que la opción StrictHostKeyChecking se haya desactivado). Las huellas digitales se pueden determinar utilizando ssh-keygen(1):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
Si la huella digital ya se conoce, se puede comparar y la clave se puede aceptar o rechazar. Si solo están disponibles huellas digitales (MD5) heredadas para el servidor, la opción ssh-keygen(1) -E se puede utilizar para reducir la versión del algoritmo de huella digital para que coincida.
Debido a la dificultad de comparar las claves de host simplemente observando las cadenas de huella digital, también existe soporte para comparar las claves de host visualmente, utilizando arte aleatorio. Al configurar la opción VisualHostKey en “yes”, se muestra un pequeño gráfico ASCII en cada inicio de sesión en un servidor, independientemente de si la sesión en sí es interactiva o no. Al aprender el patrón que produce un servidor conocido, un usuario puede determinar fácilmente que la clave de host ha cambiado cuando se muestra un patrón completamente diferente. Debido a que estos patrones no son inequívocos, un patrón que se parece al patrón recordado solo proporciona una buena probabilidad de que la clave de host sea la misma, no una prueba garantizada.
Para obtener una lista de las huellas digitales junto con sus representaciones artísticas aleatorias de todos los hosts conocidos, se puede utilizar el siguiente comando:
$ ssh-keygen -lv -f ~/.ssh/known_hosts
Si la huella digital es desconocida, está disponible un método alternativo de verificación: las huellas digitales SSH verificadas por DNS. Se agrega un registro de recurso adicional (RR), SSHFP, a un archivo de zona y el cliente que se conecta puede hacer coincidir la huella digital con la clave presentada.
En este ejemplo, estamos conectando un cliente a un servidor, “host.example.com”. Los registros de recursos SSHFP deben agregarse primero al archivo de zona para host.example.com:
$ ssh-keygen -r host.example.com.
Las líneas de salida deberán agregarse al archivo de zona. Para verificar que la zona responde a las consultas de huellas digitales:
$ dig -t SSHFP host.example.com
Finalmente, el cliente se conecta:
$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Se encontró la huella digital de la clave de host coincidente en DNS. ¿Está seguro de que desea continuar conectándose (sí/no)?
Consulte la opción VerifyHostKeyDNS en ssh_config(5) para obtener más información.
REDES PRIVADAS VIRTUALES BASADAS EN SSH
ssh contiene soporte para el túnel VPN (Red Privada Virtual) mediante el dispositivo de red tun(4), lo que permite unir de forma segura dos redes. La opción de configuración sshd_config(5) PermitTunnel controla si el servidor admite esto y en qué nivel (tráfico de capa 2 o 3).
El siguiente ejemplo conectaría la red de cliente 10.0.50.0/24 con la red remota 10.0.99.0/24 usando una conexión punto a punto de 10.1.1.1 a 10.1.1.2, siempre que el servidor SSH que se ejecuta en la puerta de enlace a la red remota, en 192.168.1.15, lo permita.
En el 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 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 mayor precisión a través del archivo /root/.ssh/authorized_keys (consulte a continuación) y la opción del servidor PermitRootLogin. La siguiente entrada permitiría conexiones en el dispositivo tun(4) 1 desde el usuario “jane” y en el dispositivo tun 2 desde el usuario “john”, si PermitRootLogin está configurado en “forced-commands-only”:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
Dado que una configuración basada en SSH implica una buena cantidad de sobrecarga, puede ser más adecuada para configuraciones temporales, como para VPN inalámbricas. Las VPN más permanentes se proporcionan mejor mediante herramientas como ipsecctl(8) e isakmpd(8).
ENTORNO
Normalmente, ssh establecerá las siguientes variables de entorno:
DISPLAY La variable DISPLAY indica la ubicación del servidor X11. ssh la establece automáticamente para que apunte a un valor del formato “hostname:n”, donde
“hostname” indica el host donde se ejecuta el shell, y ‘n’ es un entero ≥
ssh utiliza este valor especial para reenviar las conexiones X11 a través del canal seguro. El usuario normalmente no debe establecer DISPLAY explícitamente, ya que eso hará que la conexión X11 no sea segura (y requerirá que el usuario copie manualmente cualquier cookie de autorización necesaria).
HOME Se establece en la ruta del directorio de inicio del usuario.
LOGNAME Sinónimo de USER; se establece para compatibilidad con sistemas que utilizan esta variable.
MAIL Se establece en la ruta del buzón del usuario.
PATH Se establece en el PATH predeterminado, según se especifica al compilar ssh.
SSH_ASKPASS Si ssh necesita una frase de contraseña, leerá la frase de contraseña desde el terminal actual si se ejecutó desde un terminal. Si ssh no tiene un terminal asociado, pero DISPLAY y SSH_ASKPASS están establecidos, ejecutará el programa especificado por SSH_ASKPASS y abrirá una ventana X11 para leer la frase de contraseña. Esto es particularmente útil cuando se llama a ssh desde un archivo .xsession o un script relacionado. (Tenga en cuenta que en algunas máquinas puede ser necesario redirigir la entrada desde /dev/null para que esto funcione).
SSH_ASKPASS_REQUIRE Permite un mayor control sobre el uso de un programa askpass. Si esta variable está establecida en “never”, entonces ssh nunca intentará utilizar uno. Si está establecida en “prefer”, entonces ssh preferirá utilizar el programa askpass en lugar del TTY al solicitar contraseñas. Finalmente, si la variable está establecida en “force”, entonces se utilizará el programa askpass para toda la entrada de frases de contraseña, independientemente de si DISPLAY está establecido.
SSH_AUTH_SOCK Identifica la ruta de un socket de dominio Unix utilizado para comunicarse con el agente.
SSH_CONNECTION 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.
SSH_ORIGINAL_COMMAND Esta variable contiene la línea de comandos original si se ejecuta un comando forzado. Se puede utilizar para extraer los argumentos originales.
SSH_TTY Esta variable se establece en el nombre del tty (ruta al dispositivo) asociado con el shell o comando actual. Si la sesión actual no tiene tty, esta variable no se establece.
SSH_TUNNEL Opcionalmente establecido por [sshd]({filename}../../sshd)(8) para contener los nombres de las interfaces asignadas si el reenvío de túnel fue solicitado por el cliente.
SSH_USER_AUTH Opcionalmente establecido por [sshd]({filename}../../sshd)(8), esta variable puede contener una ruta de acceso a un archivo que enumera los métodos de autenticación que se utilizaron correctamente cuando se estableció la sesión, incluidas las claves públicas que se utilizaron.
TZ Esta variable se establece para indicar la zona horaria actual si se estableció cuando se inició el daemon (es decir, el daemon pasa el valor a las nuevas conexiones).
USER Se establece en el nombre del usuario que inicia sesión.
Además, ssh lee ~/.ssh/environment y agrega líneas del formato “VARNAME=value” al entorno si el archivo existe y se permite a los usuarios cambiar 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 host (ver arriba). En algunas máquinas, este archivo puede necesitar ser legible a nivel mundial si el directorio de inicio del usuario se encuentra en una partición NFS, porque sshd(8) lo lee como root. Además, este archivo debe ser propiedad del usuario y no debe tener permisos de escritura para nadie más. El permiso recomendado para la mayoría de las máquinas es de lectura/escritura para el usuario y no accesible para otros.
~/.shosts
Este archivo se utiliza exactamente de la misma manera que .rhosts, pero permite la autenticación basada en host sin permitir el inicio de sesión con rlogin/rsh.
~/.ssh/
Este directorio es la ubicación predeterminada para toda la configuración específica del usuario y la información de autenticación. No hay ningún requisito general para mantener todo el contenido de este directorio en secreto, pero los permisos recomendados son de lectura/escritura/ejecución para el usuario y no accesible para otros.
~/.ssh/authorized_keys
Lista las claves públicas (ECDSA, Ed25519, RSA) que se pueden utilizar para iniciar sesión como este usuario. El formato de este archivo se describe en la página de manual de sshd(8). Este archivo no es muy sensible, pero los permisos recomendados son de lectura/escritura para el usuario y no accesible para otros.
~/.ssh/config
Este es el archivo de configuración por usuario. El formato del archivo y las opciones de configuración se describen en ssh_config(5). Debido al potencial de abuso, este archivo debe tener permisos estrictos: lectura/escritura para el usuario y no se debe permitir la escritura para otros. Puede ser de escritura grupal, siempre que el grupo en cuestión contenga solo al usuario.
~/.ssh/environment
Contiene definiciones adicionales para las variables de entorno; consulte "ENTORNO", arriba.
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Contiene la clave privada para la autenticación. Estos archivos contienen datos confidenciales y deben ser legibles por el usuario, pero no accesibles para otros (lectura/escritura/ejecución). ssh simplemente ignorará un archivo de clave privada si es accesible para otros. Es posible especificar una frase de contraseña al generar la clave, que se utilizará para cifrar la parte confidencial de este archivo utilizando AES-128.
~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
Contiene la clave pública para la autenticación. Estos archivos no son confidenciales y pueden (pero no es necesario) ser legibles por cualquier persona.
~/.ssh/known_hosts
Contiene una lista de claves de host para todos los hosts en los que el usuario ha iniciado sesión que no están ya en la lista de claves de host conocidas a nivel del sistema. Consulte sshd(8) para obtener más detalles sobre el formato de este archivo.
~/.ssh/rc
Los comandos en este archivo se ejecutan mediante ssh cuando el usuario inicia sesión, justo antes de que se inicie el shell (o comando) del usuario. Consulte la página de manual de sshd(8) para obtener más información.
/etc/hosts.equiv
Este archivo se utiliza para la autenticación basada en host (ver arriba). Solo debe ser escribible por root.
/etc/ssh/shosts.equiv
Este archivo se utiliza de la misma manera que hosts.equiv, pero permite la autenticación basada en host sin permitir el inicio de sesión con rlogin/rsh.
/etc/ssh/ssh_config
Archivo de configuración a nivel del 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_rsa_key
Estos archivos contienen las partes privadas de las claves de host y se utilizan para la autenticación basada en host.
/etc/ssh/ssh_known_hosts
Lista a nivel del sistema de las claves de host conocidas. Este archivo debe ser preparado por el administrador del sistema para contener las claves públicas de host de todas las máquinas de la organización. Debe ser legible para todos los usuarios. Consulte sshd(8) para obtener más detalles sobre el formato de este archivo.
/etc/ssh/sshrc
Los comandos en este archivo se ejecutan mediante ssh cuando el usuario inicia sesión, justo antes de que se inicie el shell (o comando) del usuario. Consulte la página del manual sshd(8) para obtener más información.
ESTADO DE SALIDA
ssh sale con el estado de salida del comando remoto o con 255 si se produjo un error.
VER 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 y C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, enero
de 2006.
T. Ylonen y C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, enero de 2006.
T. Ylonen y C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, enero de 2006.
T. Ylonen y C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, enero
de 2006.
T. Ylonen y C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, enero de 2006.
J. Schlyter y W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints,
RFC 4255, enero de 2006.
F. Cusack y M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol
(SSH), RFC 4256, enero de 2006.
J. Galbraith y P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335,
enero de 2006.
M. Bellare, T. Kohno y C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes,
RFC 4344, enero de 2006.
B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345,
enero de 2006.
M. Friedl, N. Provos y W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH)
Transport Layer Protocol, RFC 4419, marzo de 2006.
J. Galbraith y R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, noviembre
de 2006.
D. Stebila y J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport
Layer, RFC 5656, diciembre de 2009.
A. Perrig y D. Song, Visualización de hash: una nueva técnica para mejorar la seguridad en el mundo real, 1999,
Taller internacional sobre técnicas criptográficas y comercio electrónico (CrypTEC '99).
AUTORES
OpenSSH es una versión derivada de la versión original y gratuita de ssh 1.2.12 de Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt y Dug Song eliminaron muchos errores, reincorporaron funciones más recientes y crearon OpenSSH. Markus Friedl contribuyó con el soporte para las versiones del protocolo SSH 1.5 y 2.0.