ssh: en línea en la nube

PROGRAMA:

NOMBRE

ssh - Cliente OpenSSH SSH (programa de inicio de sesión remoto)

SINOPSIS

ssh [-1246aacfggkkmnnqsttvvxxyy] [-b dirección_vinculada] [-c especificación_cifrado] [-D [dirección_vinculada:]Puerto]
[-E archivo de registro] [-e escape_char] [-F archivo de configuración] [-I pkcs11] [-i archivo_identidad]
[-L dirección] [-l nombre de inicio de sesión] [-m mac_spec] [-O CTL_CMD] [-o opción] [-p Puerto]
[-Q opción_consulta] [-R dirección] [-S ruta_ctl] [-W fortaleza:Puerto] [-w local_tun[:sintonización_remota]]
[usuario@]hostname [comando]

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á destinado a proporcionar comunicaciones cifradas seguras entre dos
hosts que no son de confianza en una red insegura. Conexiones X11, 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 especificado hostname (con opcional usuario nombre). El usuario debe
demuestre su identidad a la máquina remota utilizando uno de varios métodos (ver más abajo).

If comando se especifica, se ejecuta en el host remoto en lugar de un shell de inicio de sesión.

Las opciones son las siguientes:

-1 Fuerzas ssh para probar solo la versión 1 del protocolo.

-2 Fuerzas ssh para probar solo la versión 2 del protocolo.

-4 Fuerzas ssh para utilizar direcciones IPv4 únicamente.

-6 Fuerzas ssh para utilizar direcciones IPv6 únicamente.

-A Habilita el reenvío de la conexión del agente de autenticación. Esto también puede ser
especificado por host en un archivo de configuración.

El reenvío de agentes debe habilitarse con precaución. Usuarios con la capacidad de omitir
los permisos de archivo en el host remoto (para el socket de dominio UNIX del agente) pueden acceder
el agente local a través de la conexión reenviada. Un atacante no puede obtener la clave
material del agente, sin embargo, pueden realizar operaciones en las claves que permiten
para autenticarse utilizando las identidades cargadas en el agente.

-a Desactiva el reenvío de la conexión del agente de autenticación.

-b dirección_vinculada
Usa dirección_vinculada en la máquina local como la dirección de origen de la conexión. Solamente
útil en sistemas con más de una dirección.

-C Solicita la compresión de todos los datos (incluidos stdin, stdout, stderr y datos para
reenviado conexiones de dominio X11, TCP y UNIX). El algoritmo de compresión es el
mismo usado por gzip(1), y el "nivel" puede ser controlado por el Nivel de compresión
opción para la versión de protocolo 1. La compresión es deseable en líneas de módem y otros
conexiones lentas, pero solo ralentizará las cosas en redes rápidas. El valor por defecto
el valor se puede establecer host por host en los archivos de configuración; ver el
Compresión .

-c especificación_cifrado
Selecciona la especificación de cifrado para cifrar la sesión.

La versión 1 del protocolo permite la especificación de un solo cifrado. Los valores admitidos
son "3des", "pez globo" y "des". Para la versión de protocolo 2, especificación_cifrado es una coma
lista separada de cifrados enumerados en orden de preferencia. Ver el Cifrados palabra clave en
ssh_config(5) para obtener más información.

-D [dirección_vinculada:]Puerto
Especifica un reenvío de puertos a nivel de aplicación "dinámico" local. Esto funciona por
asignar un socket para escuchar Puerto en el lado local, opcionalmente ligado al
especificado dirección_vinculada. Siempre que se establece 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 dónde conectarse desde la máquina remota. Actualmente los SOCKS4 y
Se admiten los protocolos SOCKS5 y ssh actuará como servidor SOCKS. Solo 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. Solamente
el superusuario puede reenviar puertos privilegiados. De forma predeterminada, el puerto local está vinculado a
de acuerdo con el Puertos de enlace configuración. Sin embargo, una explícita dirección_vinculada puede ser
utilizado para vincular la conexión a una dirección específica. los dirección_vinculada de "localhost"
indica que el puerto de escucha debe estar destinado solo para uso local, mientras que un
dirección o '*' indica que el puerto debe estar disponible en todas las interfaces.

-E archivo de registro
Anexar registros de depuración a archivo de registro en lugar del error estándar.

-e escape_char
Establece el carácter de escape para sesiones con un pty (predeterminado: '~'). El escape
El carácter solo se reconoce al principio de una línea. El personaje de escape
seguido de un punto ('.') cierra la conexión; seguido de control-Z suspende el
conexión; y seguido por sí mismo envía el carácter de escape una vez. Establecer el
carácter a "ninguno" deshabilita cualquier escape y hace que la sesión sea completamente transparente.

-F archivo de configuración
Especifica un archivo de configuración alternativo por usuario. Si un archivo de configuración es
dado en la línea de comando, el archivo de configuración de todo el sistema (/ etc / ssh / ssh_config)
será ignorado. El valor predeterminado para el archivo de configuración por usuario es ~ / .ssh / config.

-f Solicitudes ssh para ir al fondo 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 lo quiere en el
antecedentes. Esto implica -n. La forma recomendada de iniciar programas X11 de forma remota
el sitio es con algo como ssh -f fortaleza xterm.

Si Salir en avance Fallo La opción de configuración se establece en "sí", luego un cliente
comenzó con -f esperará a que todos los reenvíos de puertos remotos se realicen correctamente
establecido antes de colocarse en un segundo plano.

-G Causas ssh para imprimir su configuración después de evaluar Host y Match bloques y
salida.

-g Permite que los hosts remotos se conecten a los puertos reenviados locales. Si se usa en un multiplexado
conexión, esta opción debe especificarse en el proceso maestro.

-I pkcs11
Especificar la biblioteca compartida PKCS # 11 ssh debe usar para comunicarse con un PKCS # 11
token que proporciona la clave RSA privada del usuario.

-i archivo_identidad
Selecciona un archivo del cual la identidad (clave privada) para la autenticación de clave pública
es leído. El valor predeterminado es ~ / .ssh / identidad para la versión de protocolo 1, y ~ / .ssh / id_dsa,
~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 y ~ / .ssh / id_rsa para la versión de protocolo 2.
Los archivos de identidad también se pueden especificar por host en el archivo de configuración.
Es posible tener múltiples -i opciones (y múltiples identidades especificadas en
Archivos de configuración). Si no se han especificado explícitamente certificados por el
CertificadoArchivo Directiva, ssh también intentará cargar la información del certificado desde
el nombre de archivo obtenido al agregar -cert.pub a los nombres de archivo de identidad.

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

-k Inhabilita el reenvío (delegación) de credenciales GSSAPI al servidor.

-L [dirección_vinculada:]Puerto:fortaleza:Puerto host
-L [dirección_vinculada:]Puerto:toma_remoto
-L socket_local:fortaleza:Puerto host
-L socket_local:toma_remoto
Especifica que las conexiones al puerto TCP dado o socket Unix en el local
El host (cliente) se reenviarán al host y puerto dados, o socket Unix, en el
lado remoto. Esto funciona asignando un socket para escuchar un TCP Puerto on
el lado local, opcionalmente vinculado al especificado dirección_vinculada, oa un socket Unix.
Siempre que se realiza una conexión al puerto o enchufe local, la conexión es
reenviado a través del canal seguro, y se establece una conexión a cualquiera fortaleza Puerto
Puerto host, o el socket Unix toma_remoto, 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 mediante
encerrando la dirección entre corchetes.

De forma predeterminada, el puerto local está vinculado de acuerdo con la Puertos de enlace ajuste.
Sin embargo, una explícita dirección_vinculada se puede utilizar para vincular la conexión a un específico
dirección. los dirección_vinculada de "localhost" indica que el puerto de escucha debe estar vinculado
solo para uso local, mientras que una dirección vacía o '*' indica que el puerto debe ser
disponible en todas las interfaces.

-l nombre de inicio de sesión
Especifica el usuario para iniciar sesión como en la máquina remota. Esto también puede especificarse
por host en el archivo de configuración.

-M Coloca el ssh cliente en modo "maestro" para compartir la conexión. Múltiple -M
opciones lugares ssh en modo "maestro" con confirmación requerida antes de esclavo
Se aceptan conexiones. Consulte la descripción de ControlMaster in
ssh_config(5) para obtener más detalles.

-m mac_spec
Una lista separada por comas de algoritmos MAC (código de autenticación de mensajes), especificada en
orden de preferencia. Ver el MAC palabra clave para obtener más información.

-N No ejecute un comando remoto. Esto es útil solo para reenviar puertos.

-n Redirige stdin de / dev / null (en realidad, evita la lectura desde stdin). Esto debe
ser usado cuando ssh se ejecuta en segundo plano. Un truco común es usar esto para ejecutar X11
programas en una máquina remota. Por ejemplo, ssh -n sombras.cs.hut.fi emacs & will
inicie un emacs en shadows.cs.hut.fi, y la conexión X11 será automáticamente
reenviado a través de un canal cifrado. los ssh El programa se pondrá en segundo plano.
(Esto no funciona si ssh necesita pedir una contraseña o frase de contraseña; ver también el
-f opción.)

-O CTL_CMD
Controle un proceso maestro de multiplexación de conexión activa. Cuando el -O opción es
especificado, el CTL_CMD El argumento se interpreta y se pasa al proceso maestro.
Los comandos válidos son: "comprobar" (comprobar que el proceso maestro se está ejecutando), "reenviar"
(solicitar reenvíos sin ejecución de comando), "cancelar" (cancelar reenvíos),
"Salir" (solicitar al maestro que salga) y "detener" (solicitar al maestro que se detenga
aceptar más solicitudes de multiplexación).

-o opción
Puede usarse para dar opciones en el formato usado en el archivo de configuración. Este es
útil para especificar opciones para las que no existe un indicador de línea de comandos independiente. Para
detalles completos de las opciones enumeradas a continuación, y sus posibles valores, consulte
ssh_config(5).

Agregar claves al agente
DirecciónFamilia
Por lotes
Vincular dirección
Dominios canónicos
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizarMaxDots
CanonicalizarCNAMEs permitidos
CertificadoArchivo
DesafíoRespuestaAutenticación
ComprobarHostIP
Cifra
Cifrados
BorrarTodosReenvíos
Compresión
Nivel de compresión
Intentos de conexión
Tiempo de conexión
ControlMaster
Ruta de control
ControlPersistir
Avance Dinámico
EscapeChar
Salir en avance Fallo
Huella dactilar
AdelanteAgente
AdelanteX11
AdelanteX11Timeout
AdelanteX11
Puertos de enlace
GlobalKnownHostsArchivo
GSSAPIAutenticación
GSSAPIDelegadoCredenciales
HashKnownHosts
Host
Autenticación basada en host
Tipos de claves basadas en host
Algoritmos de clave de host
Alias ​​de clave de host
NombreHost
archivo de identidad
Solo identidades
IPQoS
KbdAutenticación Interactiva
Dispositivos interactivos Kbd
Algoritmos de Kex
ComandoLocal
Reenvío local
Nivel de registro
MAC
Match
Sin autenticación de host para host local
Número de solicitudes de contraseña
Autenticación de contraseña
PermitLocalCommandPermitLocalCommand
Proveedor PKCS11
Puerto
Autenticaciones preferidas
Protocolo
Comando proxy
ProxyUseFdpass
PubkeyAcceptedKeyTypes
PubkeyAutenticación
RekeyLimit
Remoto Adelante
Solicitar TTY
RhostsRSAAutenticación
Autenticación RSA
EnviarEnv
ServidorAliveInterval
ServidorAliveCountMax
StreamLocalBindMáscara
StreamLocalBindDesvincular
Comprobación estricta de claves de host
TCPMantener vivo
Túnel
TúnelDispositivo
ActualizarHostKeys
Usar puerto privilegiado
User
UsuarioConocidoHostsArchivo
VerificarHostKeyDNS
VisualHostKey
XAuthUbicación

-p Puerto
Puerto al que conectarse en el host remoto. Esto se puede especificar por host en
el archivo de configuración.

-Q opción_consulta
Consultas ssh para los algoritmos compatibles con la versión 2 especificada.
las características son: cifra (cifrados simétricos compatibles), cifrado-auth (simétrico apoyado
cifrados que admiten cifrado autenticado), Mac (integridad de mensaje admitida
códigos), KEX (algoritmos de intercambio de claves), clave (tipos de clave), certificado de clave (clave de certificado
tipos), llano (tipos de claves sin certificado) y versión de protocolo (compatible con SSH
versiones de protocolo).

-q Modo silencioso. Provoca la supresión de la mayoría de los mensajes de advertencia y diagnóstico.

-R [dirección_vinculada:]Puerto:fortaleza:Puerto host
-R [dirección_vinculada:]Puerto:socket_local
-R toma_remoto:fortaleza:Puerto host
-R toma_remoto:socket_local
Especifica que las conexiones al puerto TCP dado o al socket Unix en el control remoto
(servidor) deben ser reenviados al host y puerto dados, o socket Unix, en el
lado local. Esto funciona asignando un socket para escuchar un TCP Puerto o para
un enchufe Unix en el lado remoto. Siempre que se establezca una conexión a este puerto o
Unix socket, la conexión se reenvía a través del canal seguro y una conexión
está hecho para cualquiera fortaleza Puerto Puerto hosto socket_local, desde la máquina local.

Los reenvíos de puertos también se pueden especificar en el archivo de configuración. Puertos privilegiados
solo se puede reenviar al iniciar sesión como root en la máquina remota. Direcciones IPv6
se puede especificar encerrando la dirección entre corchetes.

De forma predeterminada, los sockets de escucha de TCP en el servidor estarán vinculados al loopback
solo interfaz. Esto puede anularse especificando un dirección_vinculada. Un vacío
dirección_vinculada, o la dirección '*', indica que el enchufe remoto debe escuchar en
todas las interfaces. Especificando un control remoto dirección_vinculada sólo tendrá éxito si el servidor
Puertos de enlace la opción está habilitada (ver sshd_config(5)).

Si Puerto argumento es '0', el puerto de escucha se asignará dinámicamente en el
servidor e informado al cliente en tiempo de ejecución. Cuando se usa junto con -O HACIA EL FUTURO
el puerto asignado se imprimirá en la salida estándar.

-S ruta_ctl
Especifica la ubicación de un zócalo de control para compartir la conexión, o la cadena
"Ninguno" para deshabilitar la conexión compartida. Consulte la descripción de Ruta de control y
ControlMaster in ssh_config(5) para obtener más detalles.

-s Puede usarse para solicitar la invocación de un subsistema en el sistema remoto. Subsistemas
Facilitar el uso de SSH como transporte seguro para otras aplicaciones (p. ej.
Sftp(1)). El subsistema se especifica como comando remoto.

-T Deshabilite la asignación de pseudo-terminal.

-t Forzar la asignación de pseudo-terminal. Esto se puede utilizar para ejecutar pantallas arbitrarias
programas basados ​​en una máquina remota, que pueden ser muy útiles, por ejemplo, al implementar
servicios de menú. Múltiple -t las opciones fuerzan la asignación de tty, incluso si ssh no tiene local
tty.

-V Muestre el número de versión y salga.

-v Modo detallado. Causas ssh para imprimir mensajes de depuración sobre su progreso. Este es
útil para depurar problemas de conexión, autenticación y configuración.
Múltiple -v las opciones aumentan la verbosidad. El máximo es 3.

-W fortaleza:Puerto
Solicita que la entrada y salida estándar del cliente se envíen a fortaleza on Puerto
sobre el canal seguro. Implica -N, -T, Salir en avance Fallo y
BorrarTodosReenvíos.

-w local_tun[:sintonización_remota]
Solicita el reenvío del dispositivo de túnel con el hacer(4) dispositivos entre el
clientelocal_tun) y el servidor (sintonización_remota).

Los dispositivos se pueden especificar por ID numérico o la palabra clave "cualquiera", que utiliza el
siguiente dispositivo de túnel disponible. Si sintonización_remota no se especifica, por defecto es "cualquiera".
Vea también el Túnel y TúnelDispositivo directivas en ssh_config(5). Si el Túnel
La directiva no está configurada, está configurada en el modo de túnel predeterminado, que es "punto a punto".

-X Habilita el reenvío X11. Esto también se puede especificar por host en un
archivo de configuración.

El reenvío X11 debe habilitarse con precaución. Usuarios con 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 el seguimiento de pulsaciones de teclas.

Por esta razón, el reenvío de X11 está sujeto a las restricciones de extensión de X11 SECURITY
por defecto. por favor refiérase a ssh -Y opción y el AdelanteX11 Directivas
in ssh_config(5) para obtener más información.

(Específico de Debian: el reenvío X11 no está sujeto a la extensión X11 SECURITY
restricciones de forma predeterminada, porque demasiados programas se bloquean actualmente en este modo.
Seleccione las AdelanteX11 opción a "no" para restaurar el comportamiento aguas arriba. Esta
puede cambiar en el futuro dependiendo de las mejoras del lado del cliente).

-x Desactiva el reenvío X11.

-Y Habilita el reenvío X11 confiable. Los reenvíos de Trusted X11 no están sujetos a la
Controles de extensión X11 SECURITY.

(Específico de Debian: esta opción no hace nada en la configuración predeterminada: es
equivalente a "AdelanteX11 sí ”, que es el valor predeterminado como se describe anteriormente. Colocar
de la forma más AdelanteX11 opción a "no" para restaurar el comportamiento aguas arriba. Esto puede
cambiar en el futuro dependiendo de las mejoras del lado del cliente).

-y Envíe la información de registro utilizando el syslog(3) módulo de sistema. Por defecto esta información
se envía a stderr.

ssh Además, puede obtener datos de configuración de un archivo de configuración por usuario y un
archivo de configuración de todo el sistema. El formato de archivo y las opciones de configuración se describen en
ssh_config(5).

AUTENTICACIÓN

El cliente OpenSSH SSH admite los protocolos SSH 1 y 2. El valor predeterminado es utilizar el protocolo 2
solo, aunque esto se puede cambiar a través del Protocolo en opción ssh_config(5) o el -1 y -2
opciones (ver arriba). El protocolo 1 no debe usarse y solo se ofrece para admitir versiones heredadas
dispositivos. Sufre de una serie de debilidades criptográficas y no es compatible con muchos de
las funciones avanzadas disponibles para el protocolo 2.

Los métodos disponibles para la autenticación son: autenticación basada en GSSAPI, basada en host
autenticación, autenticación de clave pública, autenticación de desafío-respuesta y contraseña
autenticación. Los métodos de autenticación se prueban en el orden especificado anteriormente, aunque
Autenticaciones preferidas se puede utilizar para cambiar el orden predeterminado.

La autenticación basada en host funciona de la siguiente manera: si la máquina desde la que el usuario inicia sesión aparece en la lista
in /etc/hosts.equiv or /etc/ssh/shosts.equiv en la máquina remota, y los nombres de usuario son
lo mismo en ambos lados, o si los archivos ~ / .rhosts or ~ / .shosts existir en la casa del usuario
directorio en la máquina remota y contiene 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 para iniciar sesión. Adicionalmente,
el servidor deben poder verificar la clave de host del cliente (ver la descripción de
/ etc / ssh / ssh_known_hosts y ~ / .ssh / hosts_conocidos, a continuación) para que se permita el inicio de sesión. Esta
El método de autenticación cierra los agujeros de seguridad debido a la suplantación de IP, la suplantación de DNS y el enrutamiento
suplantación. [Nota para el administrador: /etc/hosts.equiv, ~ / .rhostsy el rlogin / rsh
protocolo en general, son intrínsecamente inseguros y deben desactivarse si se desea 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 criptosistemas donde el cifrado y el descifrado se realizan utilizando claves independientes, y es
No es factible derivar la clave de descifrado de la clave de cifrado. La idea es que cada usuario
crea un par de claves pública / privada con fines de autenticación. El servidor conoce al público
clave, y solo el usuario conoce la clave privada. ssh implementa la autenticación de clave pública
protocolo automáticamente, utilizando uno de los algoritmos DSA, ECDSA, Ed25519 o RSA. La historia
sección de ssl(8) (en sistemas que no son OpenBSD, consulte
http://www.openbsd.org/cgi-bin/man.cgi? query = ssl & sektion = 8 # HISTORY) contiene un breve
discusión de los algoritmos DSA y RSA.

El archivo ~ / .ssh / Authorizedkeys enumera las claves públicas que están permitidas para iniciar sesión.
Cuando el usuario inicia sesión, el ssh El programa le dice al servidor qué par de claves le gustaría usar.
para autenticación. El cliente acredita que tiene acceso a la clave privada y al servidor
comprueba que la clave pública correspondiente esté autorizada para aceptar la cuenta.

El usuario crea su par de claves ejecutando ssh-keygen(1). Esto almacena la clave privada en
~ / .ssh / identidad (protocolo 1), ~ / .ssh / id_dsa (DSA), ~ / .ssh / id_ecdsa (ECDSA),
~ / .ssh / id_ed25519 (Ed25519), o ~ / .ssh / id_rsa (RSA) y almacena la clave pública en
~ / .ssh / identity.pub (protocolo 1), ~ / .ssh / id_dsa.pub (DSA), ~ / .ssh / id_ecdsa.pub (ECDSA),
~ / .ssh / id_ed25519.pub (Ed25519), o ~ / .ssh / id_rsa.pub (RSA) en el directorio de inicio del usuario.
A continuación, el usuario debe copiar la clave pública a ~ / .ssh / Authorizedkeys en su directorio de inicio
en la máquina remota. los claves_autorizadas archivo corresponde al convencional ~ / .rhosts
archivo, y tiene una clave por línea, aunque las líneas pueden ser muy largas. Después de esto, el usuario puede
inicie sesión sin dar la contraseña.

Una variación de la autenticación de clave pública está disponible en forma de certificado.
autenticación: en lugar de un conjunto de claves públicas / privadas, se utilizan certificados firmados. Esta
tiene la ventaja de que se puede utilizar una única autoridad de certificación de confianza en lugar de muchas
claves públicas / privadas. 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 certificado puede ser con un
agente de autenticación. Ver ssh-agent(1) y (opcionalmente) el Agregar claves al agente directiva en
ssh_config(5) para obtener más información.

La autenticación de desafío-respuesta funciona de la siguiente manera: el servidor envía un
texto de "desafío" y solicitudes de respuesta. Ejemplos de autenticación de desafío-respuesta
incluir Autenticación BSD (consulte iniciar sesión.conf(5)) y PAM (algunos sistemas que no son OpenBSD).

Finalmente, si otros métodos de autenticación fallan, ssh solicita al usuario una contraseña. los
la contraseña se envía al host remoto para su verificación; sin embargo, dado que todas las comunicaciones son
cifrada, la contraseña no puede ser vista por alguien que esté escuchando en la red.

ssh mantiene y verifica automáticamente una base de datos que contiene la identificación de todos los hosts
alguna vez se ha utilizado con. Las claves de host se almacenan en ~ / .ssh / hosts_conocidos en la casa del usuario
directorio. Además, el archivo / etc / ssh / ssh_known_hosts se comprueba automáticamente
hosts conocidos. Los nuevos hosts se agregan automáticamente al archivo del usuario. Si un anfitrión
la identificación siempre cambia, ssh advierte sobre esto y deshabilita la autenticación de contraseña para
prevenir la suplantación de servidor o los ataques de intermediario, que de otro modo podrían utilizarse para
eludir el cifrado. los Comprobación estricta de claves de host La opción se puede utilizar para controlar los inicios de sesión.
a máquinas cuya clave de host no se conoce o ha cambiado.

Cuando el servidor ha aceptado la identidad del usuario, el servidor ejecuta la
dado el comando en una sesión no interactiva o, si no se ha especificado ningún comando, inicia sesión en
la máquina y le da al usuario un shell normal como una sesión interactiva. Toda la comunicación
con el comando remoto o shell se cifrará automáticamente.

Si se solicita una sesión interactiva ssh por defecto solo solicitará un pseudo-terminal
(pty) para sesiones interactivas cuando el cliente tiene una. Las banderas -T y -t puede ser usado para
anule 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
Transfiera datos binarios de forma fiable. En la mayoría de los sistemas, establecer el carácter de escape en "ninguno"
también haga que la sesión sea transparente incluso si se usa un tty.

La sesión termina cuando el comando o shell en la máquina remota sale y todos los X11 y
Se han cerrado las conexiones TCP.

ESCAPE CARACTERES

Cuando se solicita un pseudo-terminal, ssh admite una serie de funciones a través del
uso de un carácter de escape.

Se puede enviar un solo carácter tilde como ~~ o siguiendo la tilde por un carácter otro
que los descritos a continuación. El carácter de escape siempre debe seguir una nueva línea para ser
interpretado como especial. El carácter de escape se puede cambiar en los archivos de configuración usando
de la forma más EscapeChar directiva de configuración o en la línea de comando por el -e .

Los escapes admitidos (asumiendo el '~' predeterminado) son:

~. Desconectar.

~ ^ Z Antecedentes ssh.

~# Lista de conexiones reenviadas.

~& Antecedentes ssh al cerrar la sesión mientras espera la conexión reenviada / sesiones X11 para
Terminar.

~? Muestra una lista de caracteres de escape.

~B Envíe un BREAK al sistema remoto (solo es útil si el par lo admite).

~C Abra la línea de comando. Actualmente, esto permite la adición de reenvíos de puertos utilizando el
-L, -R y -D opciones (ver arriba). También permite la cancelación de existentes
reenvíos de puertos con -KL[dirección_vinculada:]Puerto para local, -KR[dirección_vinculada:]Puerto for
remoto y -KD[dirección_vinculada:]Puerto para reenvíos de puertos dinámicos. !comando permite la
usuario para ejecutar un comando local si el PermitLocalCommandPermitLocalCommand la opción está habilitada en
ssh_config(5). Hay ayuda básica disponible, utilizando el -h .

~R Solicitar el cambio de clave de la conexión (solo es útil si el par lo admite).

~V Disminuir la verbosidad (Nivel de registro) cuando se escriben errores en stderr.

~v Aumenta la verbosidad (Nivel de registro) cuando se escriben errores en stderr.

TCP ADELANTE

El reenvío de conexiones TCP arbitrarias a través del canal seguro se puede especificar en
la línea de comando 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; otro atraviesa cortafuegos.

En el siguiente ejemplo, analizamos la encriptación de la comunicación entre un cliente y un servidor de IRC,
aunque el servidor de IRC no admite directamente comunicaciones cifradas. Esto funciona
de la siguiente manera: el usuario se conecta al host remoto usando ssh, especificando un puerto que se utilizará para
reenviar conexiones al servidor remoto. Después de eso, es posible iniciar el servicio.
que se cifrará en la máquina cliente, conectándose al mismo puerto local, y ssh
cifrará y reenviará la conexión.

El siguiente ejemplo tuneliza una sesión de IRC desde la máquina cliente "127.0.0.1" (localhost) a
servidor remoto "server.example.com":

$ ssh -f -L 1234: localhost: 6667 server.example.com sleep 10
$ irc -c '#usuarios' -p 1234 meñique 127.0.0.1

Esto crea un túnel en una conexión al servidor de IRC "server.example.com", uniéndose al canal "#users",
apodo "meñique", utilizando el puerto 1234. No importa qué puerto se utilice, siempre que sea
mayor que 1023 (recuerde, solo root puede abrir sockets en puertos privilegiados) y no
conflicto con cualquier puerto que ya esté en uso. La conexión se reenvía al puerto 6667 en el
servidor remoto, ya que es el puerto estándar para los servicios de IRC.

El -f fondos de opciones ssh y el comando remoto "dormir 10" se especifica para permitir un
cantidad de tiempo (10 segundos, en el ejemplo) para iniciar el servicio que se va a tunelizar.
Si no se realizan conexiones dentro del tiempo especificado, ssh saldrá

X11 ADELANTE

Si AdelanteX11 variable se establece en "sí" (o consulte la descripción de la -X, -xy -Y
opciones anteriores) y el usuario está usando X11 (la variable de entorno DISPLAY está configurada), el
La conexión a la pantalla X11 se reenvía automáticamente al lado remoto de tal manera
que cualquier programa X11 iniciado desde el shell (o comando) pasará por el cifrado
canal, y la conexión al servidor X real se realizará desde la máquina local. los
el usuario no debe configurar PANTALLA manualmente. El reenvío de conexiones X11 se puede configurar en
la línea de comando o en archivos de configuración.

El valor de PANTALLA establecido por ssh apuntará a la máquina del servidor, pero con un número de pantalla
mayor que cero. Esto es normal y sucede porque ssh crea un servidor X "proxy" en
la máquina del servidor para reenviar 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
Verifique que cualquier conexión reenviada lleve esta cookie y reemplácela por la cookie real.
cuando se abre la conexión. La cookie de autenticación real nunca se envía al servidor.
máquina (y no se envían cookies en el plano).

Si AdelanteAgente variable se establece en "sí" (o consulte la descripción de la -A y -a
opciones anteriores) y el usuario está utilizando un agente de autenticación, la conexión con el agente es
reenviado automáticamente al lado remoto.

VERIFICANDO HOST LLAVES

Cuando se conecta a un servidor por primera vez, se muestra una huella digital de la clave pública del servidor.
presentado al usuario (a menos que la opción Comprobación estricta de claves de host ha sido deshabilitado).
Las huellas dactilares se pueden determinar utilizando ssh-keygen(1):

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

Si la huella dactilar ya se conoce, se puede hacer coincidir y la clave se puede aceptar o
rechazado. Si solo hay disponibles huellas dactilares heredadas (MD5) para el servidor, ssh-keygen(1)
-E La opción se puede utilizar para degradar el algoritmo de huellas dactilares para que coincida.

Debido a la dificultad de comparar claves de host con solo mirar las cadenas de huellas dactilares,
También hay soporte para comparar visualmente claves de host, usando azar artículo. Al establecer el
VisualHostKey opción a "sí", se muestra un pequeño gráfico ASCII en cada inicio de sesión en un
servidor, no importa si la sesión en sí es interactiva o no. Aprendiendo el patrón un
servidor conocido produce, un usuario puede descubrir fácilmente que la clave de host ha cambiado cuando un
Se muestra un patrón completamente diferente. Porque estos patrones no son inequívocos
Sin embargo, un patrón que se parece al patrón recordado solo da una buena
Probabilidad de que la clave del host sea la misma, prueba no garantizada.

Para obtener una lista de las huellas dactilares junto con su arte aleatorio para todos los hosts conocidos,
se puede utilizar la siguiente línea de comando:

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

Si se desconoce la huella digital, hay disponible un método alternativo de verificación: SSH
huellas dactilares verificadas por DNS. Se agrega un registro de recursos adicional (RR), SSHFP, a un
zonefile y el cliente de conexión puede hacer coincidir la huella digital con la de la clave
presentado.

En este ejemplo, estamos conectando un cliente a un servidor, "host.example.com". El SSHFP
Los registros de recursos primero deben agregarse al archivo de zona para host.example.com:

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

Las líneas de salida deberán agregarse al archivo de zona. Para comprobar que la zona está respondiendo
consultas de huellas dactilares:

$ dig -t host SSHFP.ejemplo.com

Finalmente el cliente se conecta:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Huella digital de clave de host coincidente encontrada en DNS.
¿Estás seguro de que quieres continuar conectando (sí / no)?

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

BASADO EN SSH VIRTUAL PRIVADO NETWORKS

ssh contiene soporte para túneles de redes privadas virtuales (VPN) usando el hacer(4) red
pseudodispositivo, que permite unir dos redes de forma segura. los sshd_config(5)
opción de configuración Permiso Túnel controla si el servidor admite esto y en qué
nivel (tráfico de capa 2 o 3).

El siguiente ejemplo conectaría la red del 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
El servidor SSH que se ejecuta en la puerta de enlace a la red remota, en 192.168.1.15, lo permite.

En el cliente:

# ssh -f -w 0: 1 192.168.1.15 verdadero
# ifconfig tun0 10.1.1.1 10.1.1.2 máscara de red 255.255.255.252
# ruta agregar 10.0.99.0/24 10.1.1.2

En el servidor:

# ifconfig tun1 10.1.1.2 10.1.1.1 máscara de red 255.255.255.252
# ruta agregar 10.0.50.0/24 10.1.1.1

El acceso del cliente se puede ajustar con mayor precisión a través del /root/.ssh/autorizadas_claves archivo (ver más abajo)
y la PermitRootIniciar sesión opción de servidor. La siguiente entrada permitiría conexiones en
hacer(4) dispositivo 1 del usuario "jane" y en tun dispositivo 2 del usuario "john", si PermitRootIniciar sesión is
establecido en "solo comandos forzados":

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

Dado que una configuración basada en SSH implica una gran cantidad de gastos generales, puede ser más adecuada para
configuraciones temporales, como para VPN inalámbricas. Las VPN más permanentes son mejor proporcionadas por
herramientas como iPsecctl(8) y ISAKMPD(8).

MEDIO AMBIENTE

ssh normalmente configurará las siguientes variables de entorno:

DISPLAY La variable DISPLAY indica la ubicación del servidor X11. Está
establecido automáticamente por ssh para apuntar a un valor de la forma "nombre de host: n",
donde "nombre de host" indica el host donde se ejecuta el shell, y 'n' es
un número entero ≥ 1. ssh utiliza este valor especial para reenviar X11
conexiones a través del canal seguro. El usuario normalmente no debería configurar
DISPLAY explícitamente, ya que hará que la conexión X11 sea insegura
(y requerirá que el usuario copie manualmente cualquier autorización requerida
galletas).

INICIO Establecido en la ruta del directorio de inicio del usuario.

LOGNAME Sinónimo de USER; configurado para compatibilidad con sistemas que utilizan este
variable.

CORREO Establecido en la ruta del buzón de correo del usuario.

PATH Establecido en el PATH predeterminado, como se especificó al compilar ssh.

SSH_ASKPASS Si ssh necesita una frase de contraseña, leerá la frase de contraseña del
terminal actual si se ejecutó desde un terminal. Si ssh no tiene
un terminal asociado con él pero DISPLAY y SSH_ASKPASS están configurados,
ejecutará el programa especificado por SSH_ASKPASS y abrirá un X11
ventana para leer la frase de contraseña. Esto es particularmente útil cuando
llamar ssh de un .xsesión o guión relacionado. (Tenga en cuenta que en algunos
máquinas, puede ser necesario redirigir la entrada de / dev / null a
haz que esto funcione.)

SSH_AUTH_SOCK Identifica la ruta de un socket de dominio UNIX utilizado para comunicarse con
el agente.

SSH_CONNECTION Identifica los extremos del cliente y del servidor de la conexión. La variable
contiene cuatro valores separados por espacios: dirección IP del cliente, puerto del cliente
número, dirección IP del servidor y número de puerto del servidor.

SSH_ORIGINAL_COMMAND Esta variable contiene la línea de comando original si un comando forzado
es ejecutado. Puede usarse para extraer los argumentos originales.

SSH_TTY Esto 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 está establecida.

TZ Esta variable se establece para indicar la zona horaria actual si se estableció
cuando se inició el demonio (es decir, el demonio pasa el valor a
nuevas conexiones).

USUARIO Establecido en el nombre del usuario que inicia sesión.

Esta terapia, además ssh lee ~ / .ssh / entornoy agrega líneas con el formato "VARNAME = valor" a
el entorno si el archivo existe y los usuarios pueden cambiar su entorno. Para
más información, consulte el PermitirEntornoDeUsuario en opción sshd_config(5).

Use ssh en línea usando los servicios de onworks.net