OpenSSH (Español)

Este artículo o sección necesita ser
traducido
.
Notas:
The english page has seen many changes since 2018. (Discusión en
Talk:OpenSSH (Español)#
)
Esta traducción de
OpenSSH
fue revisada el
2018-01-05
. Si existen
cambios
puede
actualizarla
o avisar al
equipo de traducción
.
Artículos relacionados
SSH keys (Español)
Pam abl
fail2ban
sshguard (Español)
SSHFS (Español)
Syslog-ng
SFTP chroot
S
ecure
Sh
ell o
SSH
es un protocolo de red que permite el intercambio de datos sobre un canal seguro entre dos computadoras. SSH usa técnicas de cifrado que hacen que la información que viaja por el medio de comunicación vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contraseña de la conexión ni lo que se escribe durante toda la sesión. SSH usa criptografía de clave pública para autenticar el equipo remoto y permitir al mismo autenticar al usuario si es necesario.
SSH se suele utilizar para iniciar una sesión en una máquina remota, donde poder ejecutar órdenes, pero también permite la tunelización, el reenvío de puertos TCP de forma arbitraria y de conexiones X11; también se pueden realizar transferencias de archivos usando protocolos SFTP o SCP asociados.
Un servidor SSH, por defecto, escucha el puerto TCP 22. Un programa cliente de SSH es utilizado, generalmente, para establecer conexiones a un demonio
sshd
que acepta conexiones remotas. Ambos se encuentran comúnmente en los sistemas operativos más modernos, incluyendo Mac OS X, Linux, Solaris y OpenVMS. Existen versiones propietarias, freeware y open-source de varios niveles de complejidad y exhaustividad.
(Source:
Wikipedia:es:Secure Shell
)
OpenSSH
OpenSSH (OpenBSD Secure Shell) es un conjunto de programas de computadora que proveen una sesión de comunicación encriptada en una red informática que utiliza el protocolo SSH. Fue creado como una alternativa de código abierto al software propietario ofrecido por SSH Communications Security. OpenSSH es desarrollado como parte del proyecto OpenBSD, que está a cargo de Theo de Raadt.
OpenSSH es confundido a veces con OpenSSL por la similitud de nombre, sin embargo, los proyectos tienen objetivos distintos y están desarrollados por equipos diferentes.
Instalación
Instale
openssh
desde los
repositorios oficiales
.
Cliente
Para conectarse a un servidor, ejecuta:
$ ssh -p
puerto
usuario
@
dirección-servidor
Si el servidor solo acepta verificación con claves públicas, siga las instrucciones en
claves SSH
.
Configuración
El archivo de configuración del cliente SSH se puede encontrar y editar en
~/.ssh/config
.
El cliente se puede configurar para guardar servidores y opciones comunes. Todas las opciones se pueden declarar globalmente o se pueden restringir a un servidor especifico. Por ejemplo:
~/.ssh/config
# opciones globales
User
usuario
# opciones especificas por servidor
Host miServidor
    HostName
direción-servidor
Port
puerto
Con dicha configuración, los siguientes comando son equivalentes:
$ ssh -p
puerto
usuario
@
dirección-servidor
$ ssh miServidor
Vea
ssh_config(5)
para más información.
Algunas opciones no tienen parametros equivalentes en al ejecutar un comando directamente, pero se puede especificar opciones en en comando con el parametro
-o
. Por ejemplo
-oKexAlgorithms=+diffie-hellman-group1-sha1
.
Servidor
Configuración
El archivo de configuración del demonio SSH se puede encontrar y editar en
/etc/ssh/ssh
d
_config
.
Para permitir el acceso sólo a algunos usuarios añadir esta línea:
AllowUsers    user1 user2
Para permitir el acceso sólo a algunos grupos:
AllowGroups group1 group2
Para agregar un agradable mensaje de bienvenida edite el archivo
/etc/issue
y cambie la línea Banner para que luzca así:
Banner /etc/issue
Claves de acceso del servidor serán generadas automáticamente por los
archivos de servicio
de
sshd
. Si se desea usar una clave especifica, previamente creada, se puede configurar manualmente:
HostKey /etc/ssh/ssh_host_rsa_key
Si el servidor va a estar expuesto a la WAN, es recomendado cambiar el puerto por defecto 22 a algo aleatorio y superior:
Port 39901
Sugerencia
Es posible que desee cambiar el puerto por defecto de 22 a cualquier puerto superior (ver
seguridad por oscuridad
). A pesar de que el puerto ssh que está siendo ejecutado puede ser detectado utilizando un port-scanner o escáner de puertos como
nmap
, cambiarlo reducirá el número de entradas en el log causados por intentos de autentificación automáticos. Para ayudar a seleccionar un puerto, revise la
lista de números de puerto TCP y UDP
. También puede encontrar información de los puertos a nivel local en
/etc/services
. Seleccione un puerto alternativo que
no
esté ya asignado a un servicio común para evitar conflictos.
Desactivar completamente los inicios de sesión con contraseña aumentará en gran medida el nivel seguridad, consulte
#Forzamiento de autenticación con claves públicas
para más información.
Gestión del Demonio
openssh
viene con un archivo de unidad de
systemd
:
Se puede
activar
y
activar inicio automático
de
sshd.service
, el cual mantendra el demonio de SSH permanentemente activo y bifurcara para cada conexión entrante.
Si se desea utilizar un puerto diferente al puerto por defecto 22, tendremos que modificar el fichero de configuración del demonio ubicado en /etc/ssh/sshd_config, buscar la línea Port=* y cambiar por el puerto deseado.
Advertencia
Systemd inicia los procesos de manera asíncrona. Si se amarra el demonio SSH a una dirección IP específica
ListenAddress 192.168.1.100
puede ser que no cargue al arranque porque por defecto el archivo sshd.service no depende de que se hayan habilitado las interfaces de red. Cuando se amarre a una dirección IP, es necesario agregar
After=network.target
a un archivo personalizado de sshd.service. Ver
Systemd (Español)#Modificar los archivos de unidad suministrados
.
Sugerencia
Cuando se utiliza la activación del socket, ni
sshd.socket
ni
sshd.service
permiten supervisar los intentos de conexión en el registro, pero si lo puede ver al ejecutar
# journalctl /usr/bin/sshd
.
Protección
Permitir el acceso remoto al sistema a través de SSH es bueno para fines administrativos, pero puede representar una amenaza para la seguridad de su servidor. A menudo es el blanco de ataques de fuerza bruta, por lo que el acceso SSH necesita ser limitado adecuadamente para evitar que terceros accedan a su servidor.
Utilice nombres de cuenta y contraseñas no estándar .
Permita solo conexiones SSH entrantes desde ubicaciones de confianza.
Utilice
fail2ban
o
sshguard
para controlar los ataques de fuerza bruta, y banear las IP que se correspondan con las de los ataques de fuerza bruta.
Forzamiento de autenticación con claves públicas
Si un cliente no se puede autenticar mediante clave pública, por defecto el servidor de SSH intentará autenticar con contraseña, permitiendo así que un usuario malicioso intente ganar acceso con
ataques de fuerza bruta
en la contraseña. Uno de los métodos más efectivos para proteger el sistema contra esta clase de ataques es desactivando el inicio de sesión con contraseña completamente, forzando así el uso de
claves SSH
. Esto se puede lograr modificando la siguiente opción en el archivo
sshd_config
:
PasswordAuthentication no
Advertencia
Antes de efectuar este ajuste, asegúrese de que todas las cuentas que requieren acceso SSH, tienen configurada la autenticación de la clave pública en los correspondientes archivos
authorized_keys
. Vea
SSH keys#Copying the public key to the remote server
para más información.
Autenticación de dos factores y claves públicas
Desde la versión 6.2 de OpenSSH, se puede agregar su propia utilidad para autenticar usando la opción
AuthenticationMethods
. Esta opción da la posibilidad de usar sus claves públicas o autenticación de dos factores.
Vea
Autenticador de Google
para configurar el autenticador de Google.
Para usar
PAM
son OpenSSH, edite las siguientes lineas:
/etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey keyboard-interactive:pam
Después puede iniciar sesión ya sea con clave pública
o
con la autenticación del usuario, tal como es requerido en la configuración de PAM.
Si, por otra parte se quiere autenticar el usuario con la clave pública y la autenticación especificada en la configuración de PAM, use una coma en lugar de un espacio para separar los
AuthenticationMethods
.
/etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey
,
keyboard-interactive:pam
Cuando se requiere autenticación de clave pública
y
PAM, es deseable desactivar el requisito de contraseña:
/etc/pam.d/sshd
# Desactive inicio de sesión root remoto
auth      required  pam_securetty.so
# Requerido por el authenticator de google
auth      required  pam_google_authenticator.so
# Desactive inicio de sesión con contraseña
#auth      include   system-remote-login
account   include   system-remote-login
password  include   system-remote-login
session   include   system-remote-login
Protección contra ataques de fuerza bruta
El concepto de
ataques de fuerza bruta
es simple: es un mecanismo por el que alguien trata continuamente de iniciar sesión en una página web o un servidor para acceder a un prompt como SSH utilizando un elevado número de combinaciones de nombre de usuario y contraseña aleatorios.
Usango ufw
Vea
ufw#Rate limiting with ufw
.
Usando iptables
Si su sistema ya esta usando iptables, se puede proteger fácilmente contra los ataques de fuerza bruta usando la siguientes reglas
Nota
En este ejemplo el puerto de SSH fue cambiado al puerto TCP 42660.
Antes de usar las siguientes reglas es necesario crear una nueva regla que registra y descarta demasiados intentos de conexión:
# iptables -N LOG_AND_DROP
La primera regla va a ser aplicada a paquetes que señaalan el comienzo de nuevas conexiones con destino el puert TCP 42660.
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --set --name DEFAULT --rsource
Esta regla le permite a iptables buscar por paquetes que coinciden con los parámetros de la regla anterior, y que provienen de servidores que ya están en la lista de vigilancia.
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --update --seconds 90 --hitcount 4 --name DEFAULT --rsource -j LOG_AND_DROP
Ahora iptables decide que hacer con trafico con destino al puerto TCP 42660 que no coincide con la regla anterior.
# iptables -A INPUT -p tcp -m tcp --dport 42660 -j ACCEPT
Se adjunta esta regla a la tabla de registro y descarte, y se usa el operador
-j
(jump), para pasar la información del paquete al registro.
# iptables -A LOG_AND_DROP -j LOG --log-prefix "iptables deny: " --log-level 7
Después que el paquete es registrado por la primera regla, el resto de paquetes sera descartado.
# iptables -A LOG_AND_DROP -j DROP
Utilidades para prevenir ataques de fuerza bruta
Se pueden prevenir los ataques de fuerza bruta usando un script automatizado que bloquea a cualquiera que intenta usar fuerza bruta, por ejemplo
fail2ban
o
sshguard
.
Solo permite conexiones SSH entrantes de ubicaciones de confianza.
Use
fail2ban
o
sshguard
para bloquear direcciones IP que fallan en la autenticación con contraseña demasiadas veces.
Use
pam_shield
para bloquear direcciones IP que intentan iniciar sesión demasiadas veces en un periodo de tiempo determinado. En comparación con
fail2ban
o
sshguard
, este programa no toma en cuenta si el intento de inicio de sesión fue exitoso o no.
Limitar el inicio de sesión como root
En general, se considera una mala práctica permitir que el usuario root inicie sesión sin restricciones a través de SSH. Hay dos métodos por los cuales el acceso de root a SSH puede ser restringido para mayor seguridad.
Denegar
Sudo proporciona los derechos de root de forma selectiva para las acciones que requieran de estos derechos, sin necesidad de autenticarse con la cuenta de root. Esto permite el bloqueo de la cuenta root para acceder a través de SSH y funciona como una medida de seguridad frente a los potenciales ataques de fuerza bruta, ya que ahora un atacante debe adivinar, además del nombre de la cuenta, la contraseña.
SSH se puede configurar para negar las conexiones remotas con el usuario root, editando la sección «Authentication» en
/etc/ssh/sshd_config
. Basta con cambiar
#PermitRootLogin yes
a
no
y descomentar la línea:
/etc/ssh/sshd_config
PermitRootLogin no
...
A continuación, reiniciar el demonio de SSH:
# systemctl restart sshd
Ahora va a ser incapaz de conectarse por SSH como root, pero todavía será capaz de iniciar sesión con su usuario normal y utilizar
su (Español)
o
sudo (Español)
para hacer la administración del sistema.
Restringir
Algunas tareas automatizadas realizadas a distancia, como copia de seguridad de todo el sistema, requieren el acceso de root completo. Para permitir que esto se haga de una manera segura, en lugar de desactivar el inicio de sesión de root a través de SSH, es posible permitir las conexiones de root solo para ciertas órdenes seleccionadas. Esto se puede lograr editando
~root/.ssh/authorized_keys
, y anteponiendo la clave deseada, por ejemplo, como sigue:
command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …
Esto permitirá cualquier inicio de sesión con esta clave específica, solo para ejecutar la orden especificada entre las comillas.
El aumento de la superficie de ataque creado por exponer el nombre de usuario root al iniciar la sesión, se puede compensar añadiendo lo siguiente a
sshd_config
:
PermitRootLogin forced-commands-only
Este ajuste no solo restringirá las órdenes que puede ejecutar root a través de SSH, sino que también desactiva el uso de contraseñas, forzando el uso de la autenticación de la clave pública para la cuenta root.
Hay una alternativa un poco menos restrictiva, que permitirá ejecutar cualquier orden por root, pero hace los ataques de fuerza bruta no factibles mediante la exigencia de la autenticación de la clave pública. Para esta opción, establezca:
PermitRootLogin without-password
VirtualBox
Para comunicarse entre huésped y anfitrión de VirtualBox, el puerto del servidor debe ser reenviado en Settings > Network. Al conectarse desde el cliente/anfitrión, conecte a la dirección IP de la máquina del cliente/anfitrión, en oposición a la conexión de la otra máquina. Esto es porque la conexión se realizará a través de un adaptador virtual.
Otros servidores y clientes SSH
Aparte de OpenSSH, hay otros muchos
clientes
y
servidores
SSH disponibles.
Dropbear
Dropbear
es un cliente SSH-2  y un servidor. El paquete
dropbear
está disponible en
AUR
.
El cliente ssh en línea de órdenes se llama dbclient.
SSH alternativa: Mobile Shell - responsive, survives disconnects
Del
sitio web
de Mosh:
Aplicación de terminal remoto que permite la itinerancia, soporta conectividad intermitente y proporciona echo local inteligente y la edición de línea de keystrokes del usuario. Mosh es un reemplazo para SSH. Es más robusto y sensible, sobre todo a través de Wi-Fi, móvil y enlaces de larga distancia.
Instale
mosh
desde los
repositorios oficiales
o la última revisión
mosh-git
AUR
desde
AUR
.
Trucos y sugerencias
Túneles SOCKS cifrados
Este tipo de conexión es muy útil para usuarios de equipos portátiles conectados a varias conexiones inalámbricas no seguras. Lo único que necesitas es un servidor SSH corriendo en algún lugar seguro, como tu casa o tu trabajo. Puede ser útil usar un servicio de DNS dinámico como
DynDNS
para no tener que recordar la dirección IP a la que desea conectarse.
Paso 1: Iniciar la conexión
Lo único que tienes que hacer es ejecutar este comando en tu terminal favorita para iniciar la conexión:
$ ssh -ND 4711
user
@
host
donde
user
es tu nombre de usuario en el servidor SSH que se está ejecutando en el
host
. Preguntará por tu contraseña, y luego ¡estarás conectado! El parámetro
N
desactiva el prompt interactivo, y el
D
especifica el puerto local en el cual escuchar (puedes elegir el numero de puerto que quieras). El parámetro
T
desactiva la asignación pseudo-tty.
Le puede interesar añadir el parámetro
verbose
(
-v
), ya que la salida le permite comprobar que está realmente conectado.
Paso 2: Configurar tu navegador (u otros programas)
El paso anterior es inútil si no configura el navegador web (u otros programas) para su uso con el túnel que acaba de crear. Debido a que la versión actual de SSH soporta SOCKS4 y SOCKS5, se puede usar cualquiera de ellos.
Para Firefox:
Editar → Preferencias → Avanzadas → Red → Conexión → Configuración
:
Marca la casilla
"Configuración manual de proxy"
, y escribe
localhost
en el campo
"servidor SOCKS"
, y luego escribe tu número de puerto en el siguiente campo de texto (
4711
en el siguiente ejemplo).
Firefox no hace automáticamente las peticiones DNS a través del túnel socks. Este potencial problema de privacidad puede ser mitigado por los siguientes pasos:
Escriba «about:config» en la barra de navegación de Firefox.
Busque por «network.proxy.socks_remote_dns»
Ajuste el valor a «true».
Reinicie el navegador.
Para Chromium: Se pueden setear las configuraciones de SOCKS como variables de entorno o como opciones en línea de comandos. Es recomendable agregar una de las siguientes funciones a
.bashrc
:
function secure_chromium() {
    port=4711
    export SOCKS_SERVER=localhost:$port
    export SOCKS_VERSION=5
    chromium &
    exit
}
o
function secure_chromium {
    port=4343
    chromium --proxy-server="socks://localhost:$port" &
    exit
}
Ahora solo queda abrir una terminal y escribir:
$ secure_chromium
Listo. ¡Disfruta tu túnel seguro!
Redireccionar X11
X11 forwarding
es un mecanismo que permite a las interfaces gráficas de los programas de X11, que se ejecutan en un sistema remoto, mostrarse en una máquina cliente local. Para reenviar X11 al equipo remoto, este no necesita tener un sistema completo X11 instalado, sin embargo, necesita, al menos, tener
xauth
instalado.
xauth
es una utilidad que mantiene las configuraciones de
Xauthority
utilizadas por el servidor y el cliente para la autenticación de la sesión de X11 (
fuente
).
Advertencia
Redirigir X11 tiene importantes implicaciones de seguridad que aconsejan la lectura de, al menos, las secciones pertinentes de
ssh
,
sshd_config
y
ssh_config
de las páginas del manual. Vea también
esta breve nota
.
Configuración
En el sistema remoto:
Instale
xorg-xauth
y
xorg-xhost
desde los
repositorios oficiales
en
/etc/ssh/ssh
d
_config
:
verifique que las opciones
AllowTcpForwarding
y
X11UseLocalhost
están ajustadas a
yes
, y que
X11DisplayOffset
está ajustado a
10
(esos son los valores por defecto si no se han cambiado, ver
sshd_config(5)
)
ajuste
X11Forwarding
a
yes
a continuación,
reinicie
el
demonio
sshd
.
En el sistema cliente, active la opción
ForwardX11
,  bien especificando el parámetro
-X
en la línea de órdenes para las conexiones ocasionales, bien ajustando
ForwardX11
a
yes
en el
archivo de configuración del cliente de openSSH
.
Sugerencia
Puede activar la opción
ForwardX11Trusted
(
-Y
en la línea de órdenes) si la interfaz gráfica está llegando mal o recibe errores; esto evitará que las redirecciones de X11 vengan sujetas a los controles de la
extensión de SEGURIDAD de X11
. Asegúrese de haber entendido
la advertencia
del comienzo de esta sección, si lo hace.
Utilización
Inicie sesión en el equipo remoto como de costumbre, especificando el parámetro
-X
si
ForwardX11
no se ha activado en el archivo de configuración del cliente:
$ ssh -X
user@host
Si recibe errores tratando de ejecutar aplicaciones gráficas, pruebe
ForwardX11Trusted
en su lugar:
$ ssh -Y
user@host
Ahora puede iniciar cualquier programa X en el servidor remoto, la salida será enviada a su sesión local:
$ xclock
Si recibe errores como «Cannot open display», pruebe la siguiente orden como usuario no root:
$ xhost +
La orden anterior permitirá a cualquiera transmitir aplicaciones X11. Para limitar el reenvío a un tipo de equipo particular:
$ xhost +hostname
donde hostname es el nombre del equipo en particular al que desea remitirse. Ver
xhost(1)
para más detalles.
Tenga cuidado con algunas aplicaciones, ya que hacen un chequeo para ejecutar una instancia en la máquina local.
Firefox
es un ejemplo: o bien cierre la instancia de Firefox en ejecución o utilice el siguiente parámetro de inicio para poner en marcha una instancia remota en el equipo local:
$ firefox -no-remote
Si recibe «X11 forwarding request failed on channel 0» cuando se conecta (y el archivo
/var/log/errors.log
del servidor  muestra «Failed to allocate internet-domain X11 display socket»), asegúrese de que el paquete
xorg-xauth
está instalado. Si su instalación no funciona, pruebe cualquiera de los dos opciones siguientes:
active la opción
AddressFamily any
en
ssh
d
_config
en el
server
, o
ajuste la opción
AddressFamily
en
ssh
d
_config
en el
server
a inet.
Si establece «inet» puede arreglar los problemas con los clientes de Ubuntu en IPv4.
Para ejecutar aplicaciones X como otro usuario en el servidor SSH, necesita la línea de autenticación
xauth add
tomada desde
xauth list
de la sesión SSH del usuario conectado.
Redireccionar otros puertos
Además del soporte integrado de SSH para redirigir X11, dicho soporte se puede usar también para asegurar el canal de cualquier conexión TCP, mediante su re dirección local o remota.
El reenvío local abre un puerto en la máquina local, a la que se redirigirán las conexiones para el equipo remoto y de ahí a un destino determinado. Muy a menudo, el destino de reenvío será el mismo que el del equipo remoto, proporcionando así un shell seguro y, por ejemplo, una conexión VNC segura, a la misma máquina. El reenvío local se lleva a cabo por medio del parámetro
-L
y la especificación de reenvío se acompaña en forma de
<tunnel port>:<destination address>:<destination port>
.
Así:
$ ssh -L 1000:mail.google.com:25 192.168.0.100
utilizará SSH para iniciar sesión y abrir un shell en 192.168.0.100, y también creará un túnel desde el puerto TCP 1000 de la máquina local a mail.google.com en el puerto 25. Una vez establecidas, las conexiones a localhost:1000 conectarán al puerto SMTP de Gmail. Para Google, parecerá que dichas conexiones (aunque no necesariamente los datos transmitidos por la conexión) se originaron en 192.168.0.100, y tales datos estarán seguros entre el equipo local y 192.168.0.100, pero no una vez en 192.168.0.100, a menos que se tomen otras medidas.
Del mismo modo:
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100
permitirá conexiones a localhost:2000 que se enviarán de forma transparente al equipo remoto en el puerto 6001. El ejemplo anterior es útil para conexiones VNC mediante la utilidad de vncserver —parte del paquete tightvnc— que, aunque muy útil, es explícita acerca de su falta de seguridad.
El reenvío remoto permite al equipo remoto conectarse a un equipo de forma arbitraria a través del túnel SSH y la máquina local, proporcionando un cambio funcional de redirecciones locales, y es útil para situaciones en las que, por ejemplo, el equipo remoto ha limitado conectividad debido a los cortafuegos. Se activa con el parámetro
-R
y utiliza la especificación de reenvío en forma de
<tunnel port>:<destination address>:<destination port>
.
Así:
$ ssh -R 3000:irc.libera.chat:6667 192.168.0.200
abrirá una shell en 192.168.0.200, y las conexiones desde 192.168.0.200 a sí mismo en el puerto 3000 (hablando en terminología remota, localhost:3000) serán enviadas a través del túnel de la máquina local y luego a irc.libera.chat en el puerto 6667, por lo tanto, en este ejemplo, lo que permite es el uso de programas de IRC en el equipo remoto, incluso si el puerto 6667 esté bloqueado por él, como es lo normal.
Tanto el reenvío local como el remoto se pueden utilizar para ofrecer una «puerta de enlace» segura, lo que permite que otros equipos se aprovechen de un túnel SSH, sin ejecutar SSH o el demonio SSH, proporcionando una dirección de enlace para el inicio del túnel como parte de la especificación de reenvío, por ejemplo
<tunnel address>:<tunnel port>:<destination address>:<destination port>
. La especificación
<tunnel address>
puede ser cualquier dirección de la máquina en el inicio del túnel,
localhost
, (o en blanco)
*
, que, respectivamente, permiten conexiones a través de la dirección indicada, a través de la interfaz loopback, o a través de cualquier interfaz. De forma predeterminada, el reenvío se limita a las conexiones desde la máquina en el «principio» del túnel, es decir, la especificación
<tunnel address>
viene asignada a
localhost
. El reenvío local no requiere ninguna configuración adicional, sin embargo, el reenvío remoto está limitado por la configuración del demonio SSH del servidor remoto. Vea la opción
GatewayPorts
en
sshd_config(5)
para más información.
Multiplexación
El demonio SSH normalmente escucha en el puerto 22. Sin embargo, es una práctica común para muchos puntos de acceso público a Internet bloquear todo el tráfico que no pase por los puertos HTTP/S normales (80 y 443, respectivamente), por lo que, efectivamente, bloquean las conexiones SSH. La solución inmediata para esto es tener listado adicionalmente
sshd
en uno de los puertos de la lista blanca:
/etc/ssh/sshd_config
Port 22
Port 443
Sin embargo, es probable que el puerto 443 ya esté en uso por un servidor web que sirve contenidos HTTPS, en cuyo caso es posible utilizar un multiplexor, como
sslh
, que escucha en el puerto multiplexado y puede inteligentemente reenviar paquetes a muchos servicios.
Acelerando SSH
Se puede hacer que todas las sesiones al mismo equipo utilicen una conexión única, lo que acelerará enormemente los inicios de sesión posteriores, añadiendo estas líneas bajo el equipo (host) adecuado en
/etc/ssh/ssh_config
:
Host examplehost.com
  ControlMaster auto
  ControlPersist yes
  ControlPath ~/.ssh/socket-%r@%h:%p
Vea la página del manual
ssh_config(5)
para obtener una descripción completa de estas opciones.
Otra opción para mejorar la velocidad es habilitar la compresión con el sufijo
-C
. Una solución permanente es agregar esta línea debajo del host correcto en
/etc/ssh/ssh_config
:
Compression yes
Advertencia
ssh(1)
establece que «
La compresión es deseable en las líneas de módem y otras conexiones lentas, pero ralentizará las cosas en redes rápidas
». Este consejo podría ser contraproducente en función de su configuración de red.
El tiempo de inicio de sesión puede ser acortado usando el sufijo
-4
,que saltea la búsqueda IPv6. Esto puede hacerse permanente añadiendo esta línea bajo el host correcto en
/etc/ssh/ssh_config
:
AddressFamily inet
Cambiar los algoritmos de cifrado usados por SSH para demandar menos cpu puede mejorar la velocidad. En este sentido, las mejores opciones son arcfour y blowfish-cbc.
Advertencia
Por favor, no haga esto a menos que sepa lo que está haciendo; arcfour tiene una serie de debilidades conocidas.
Para utilizar sistemas de cifrado alternativos, ejecute SSH con el parámetro
-c
:
$ ssh -c arcfour,blowfish-cbc user@server-address
Para usar el cifrado permanentemente, añada esta línea bajo el equipo adecuado en
/etc/ssh/ssh_config
:
Ciphers arcfour,blowfish-cbc
Montando un Sistema de archivos Remoto con SSHFS
Por favor, consulte el artículo
Sshfs
para utilizar sshfs a fin de montar un sistema remoto —accesible a través de SSH— en una carpeta local, de modo que sea capaz de hacer cualquier operación en los archivos montados con cualquier herramienta (copiar, renombrar, editar con vim, etc.). Utilizar sshfs en lugar de shfs es, en general, preferible, como una nueva versión de shfs, ya que esta última no ha sido liberada desde 2004.
Mantener la sesión activa
Tu sesion ssh sera automáticamente desconectada si ésta se encuentra inactiva. Para mantener activa la conexión agrega esto a
~/.ssh/config
o a
/etc/ssh/ssh_config
en el cliente.
ServerAliveInterval 120
Esto enviará la señal «keep alive» al servidor cada 120 segundos.
Por el contrario, para mantener activas las conexiones entrantes, puede establecer:
ClientAliveInterval 120
(o algún otro número mayor que 0) en el archivo
/etc/ssh/sshd_config
del servidor.
Guardar los datos de conexión en la configuración de SSH
Cada vez que desee conectarse a un servidor ssh, por lo general, tiene que escribir, al menos, su dirección y el nombre de usuario. Para ahorrarse tener que reescribirlo, puede guardar los datos de los servidores a los que se conecta regularmente, utilizando el archivo personal
~/.ssh/config
o el global del sistema
/etc/ssh/ssh_config
, como se muestra en el siguiente ejemplo:
~/.ssh/config
Host myserver
    HostName 123.123.123.123
    Port 12345
    User bob
Host other_server
    HostName test.something.org
    User alice
    CheckHostIP no
    Cipher blowfish
Ahora solo queda conectarse al servidor utilizando el nombre especificado:
$ ssh myserver
Para ver una lista completa de las opciones posibles, eche un vistazo a la página del manual de ssh_config en el sistema o a la
ssh_config documentación
en el sitio web oficial.
Autossh - reiniciar automáticamente las sesiones y túnes de SSH
Cuando una sesión o túnel no pueden mantenerse activos, por ejemplo debido a las malas condiciones de la red que provoca desconexiones del cliente, puede utilizar
Autossh
para reiniciar automáticamente. Autossh se puede instalar desde los
repositorios oficiales
.
Ejemplos de uso:
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com
Combinado con
sshfs
:
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example
Conexión a través de un conjunto SOCKS-proxy por
Proxy_settings
:
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com
Con el opción
-f
, autossh puede hacer que se ejecute como un proceso en segundo plano. Ejecutarlo de esta manera, sin embargo, significa que la frase de contraseña no se podrá introducir de forma interactiva.
La sesión finalizará una vez que se escribe
exit
en la sesión, o el proceso autossh recibe una señal SIGTERM, SIGINT of SIGKILL.
Ejecutar Autossh automáticamente en el arranque mediante systemd
Si desea iniciar automáticamente autossh, ahora es fácil conseguirlo haciendo que systemd maneje esto. Por ejemplo, puede crear un archivo de unidad systemd como este:
[Unit]
Description=AutoSSH service for port 2222
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

[Install]
WantedBy=multi-user.target
Aquí
AUTOSSH_GATETIME=0
es una variable de entorno que especifica cuánto tiempo ssh debe estar activo antes de que autossh considere la conexión exitosa, ponerlo a 0 hace que autossh ignore el primer fallo de ejecución de ssh. Esto puede ser útil cuando se ejecuta autossh en el arranque. Otras variables de entorno están disponibles en la página del manual. Por supuesto, se puede hacer esta unidad más compleja si es necesario (consulte la documentación de systemd para más detalles), y, obviamente, puede utilizar sus propias opciones para autossh, pero tenga en cuenta que el parámetro
-f
implica
AUTOSSH_GATETIME=0
quen no funciona con systemd.
Luego coloque esto en, por ejemplo, /etc/systemd/system/autossh.service. Posteriormente, puede activar sus túneles autossh con, por ejemplo:
$ systemctl start autossh
(o como llame al archivo de servicios)
Si esto funciona bien para su caso, puede hacer esto permanente ejecutando:
$ systemctl enable autossh
Eso hace que autossh se inicie automáticamente en el arranque.
También es fácil mantener varios procesos autossh, para mantener activos varios túneles. Solo tiene que crear varios archivos .service con diferentes nombres.
Cambiar el número de puerto de SSH con la activación del socket (sshd.socket)
Cree el archivo
/etc/systemd/system/sshd.socket.d/port.conf
con:
[Socket]
# Desactivar puerto por defecto
ListenStream=
# Establecer nuevo puerto
ListenStream=12345
systemd escuchará automáticamente en el nuevo puerto después de su recarga:
systemctl daemon-reload
Solución de problemas
Lista de comprobación
Esta es una primera aproximación a la solución de problemas con una lista de comprobación. Se recomienda revisar estos puntos antes de mirar más lejos:
1. La carpeta
~/.ssh
del cliente y del servidor y su contenido deben ser accesibles por sus usuarios:
$ chmod 700 /home/USER/.ssh
  $ chmod 600 /home/USER/.ssh/*
2. Compruebe que todos los archivos de la carpeta
~/.ssh
del cliente y del servidor son propiedad de sus usuario:
$ chown -R USER: ~/.ssh
3. Compruebe que, por ejemplo, la clave pública
id_rsa.pub
del cliente está en el archivo
authorized_keys
del servidor .
4. Compruebe que no se limitó el acceso a SSH a través de
AllowUsers
en
/etc/ssh/sshd_config
(separadas por espacios).
Limpiar claves desactualizadas (opcional)
5. Elimine claves antiguas/no válidas del archivo
/.ssh/authorized_keys
del servidor.
6. Elimine claves antiguas/no válidas privadas y públicas dentro de la carpeta
~/.ssh
de los clientes.
Recomendaciones
7. Mantenga el menor número de claves posibles del archivo
~/.ssh/authorized_keys
del cliente en el servidor.
La conexión SSH queda colgada después de apagar/reiniciar
La conexión SSH se bloquea después de apagar o reiniciar si systemd detiene la conexión de red antes que sshd. Para solucionar este problema, comente y cambie la declaración
After
:
/usr/lib/systemd/system/systemd-user-sessions.service
#After=remote-fs.target
After=network.target
Conexión denegada o problemas con timeout
¿Está su router haciendo reenvío de puertos?
SALTAR ESTE PASO SI NO ESTÁ DETRÁS DE UNA NAT DE MÓDEM/ROUTER (por ejemplo, un VPS o en otro caso un equipo con direcciones públicas). La mayoría de los hogares y pequeñas empresas tendrán un módem/router con NAT.
Lo primero es asegurarse de que el router sabe que reenvía cualquier conexión ssh entrante a su máquina. Su IP externa es dada a usted por su proveedor de Internet, y se asocia con cualquier petición que sale de su router. Por lo tanto, el router tiene que saber que cualquier conexión ssh entrante a su IP externa necesita ser reenviada a su máquina donde se ejecuta sshd.
Encuentre su dirección de red interna.
ip a
Encuentre la interfaz de su dispositivo y busque el campo inet. Luego acceda a la interfaz web de configuración del router, utilizando la IP del router (encontrará esto en la web). Informe a su router para re-dirigirlo a su IP inet. Vaya a
[1]
para más instrucciones sobre cómo hacerlo para su router en particular.
¿Está SSH corriendo y escuchando?
$ ss -tnlp
Si la orden anterior no muestra que el puerto SSH está abierto, SSH no se está ejecutando. Compruebe
/var/log/messages
para conocer errores, etc.
¿Existen reglas de firewall que bloqueen la conexión?
Iptables
puede bloquear conexiones en el puerto
22
. Compruebe esto con:
# iptables -nvL
y busque las posibles reglas que bloqueen paquetes en la cadena
INPUT
. Entonces, si es necesario, desbloquee el puerto con una orden como:
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
Para obtener más ayuda sobre cómo para configurar cortafuegos, consulte
Firewalls (Español)
.
¿Está el tráfico llegando a su ordenador?
Realice un vuelco de la información del tráfico sobre el equipo que está teniendo problemas con:
# tcpdump -lnn -i any port ssh and tcp-syn
Esto debería mostrar alguna información básica, y luego espere a que todo el tráfico que debería producirse se muestre. Pruebe su conexión ahora. Si no ve ninguna salida cuando se intenta conectar, entonces algo fuera de su ordenador está bloqueando el tráfico (por ejemplo, cortafuegos físicos, NAT del router, etc.).
¿Su ISP o un tercero está bloqueando el puerto por defecto?
Nota
Pruebe este paso si
sabe
que no está ejecutando ningún cortafuegos y sabe que ha configurado el router para DMZ o ha redirigido el puerto a su equipo y aún no funciona. Aquí encontrará los pasos de diagnóstico y una posible solución.
En algunos casos, su proveedor de Internet podría bloquear el puerto predeterminado (puerto 22 SSH), así que lo que está intentando (apertura de puertos, endurecimiento del apilamiento, defensa contra ataques de saturación, etc.) es estéril. Para confirmar esto, cree un servidor en todas las interfaces (0.0.0.0) y conéctelo de forma remota.
Si recibe un mensaje de error similar a este:
ssh: connect to host www.inet.hr port 22: Connection refused
Eso significa que el puerto
no
está bloqueado por el ISP, pero el servidor no ejecuta SSH en ese puerto (vea
seguridad por oscuridad
).
Sin embargo, si se recibe un mensaje de error similar a este:
ssh: connect to host 111.222.333.444 port 22: Operation timed out
Eso significa que algo está rechazando el tráfico TCP en el puerto 22. Básicamente ese puerto está siendo vigilado, ya sea por el cortafuegos o por la intervención de terceras partes (como un ISP que bloquea y/o rechaza el tráfico entrante en el puerto 22). Si se sabe que no está ejecutando ningún cortafuegos en su ordenador, y está seguro que ningún Gremlins están creciendo en su router y switches, entonces, el ISP está bloqueando el tráfico.
Para hacer doble verificación, puede ejecutar Wireshark en el servidor y escuchar el tráfico en el puerto 22. Dado que Wireshark es una utilidad que esnifa paquetes de dos niveles, y TCP/UDP tiene 3 niveles y así sucesivamente (ver
pila de red de IP
), si no recibe nada mientras se conecta de forma remota, lo más probable es que un tercero esté bloqueando el tráfico en ese puerto para su servidor.
Diagnóstico con Wireshark
Instale
Wireshark con el paquete
wireshark-cli
disponible en los
repositorios oficiales
.
Y luego ejecútelo utilizando,
tshark -f "tcp port 22" -i NET_IF
donde NET_IF es la interfaz de red para una conexión WAN (ver
ip a
para comprobar). Si no se está recibiendo ningún paquete al intentar conectarse de forma remota, puede estar muy seguro de que su ISP está bloqueando el tráfico entrante en el puerto 22.
Posible solución
La solución es utilizar algún otro puerto que el ISP no esté bloqueando. Abra el archivo
/etc/ssh/sshd_config
y configúrelo para utilizar diferentes puertos. Por ejemplo, añada:
Port 22
Port 1234
Asegúrese también de que otras líneas de configuración del «puerto»  en el archivo están comentadas. Solo comentar «Port 22» y poner «Port 1234» no va a resolver el problema, porque entonces sshd solo escuchará el puerto 1234. Utilice ambas líneas para ejecutar el servidor SSH en ambos puertos.
Reinicie el servidor
systemctl restart sshd.service
y todo estará listo. Todavía tiene que configurar su cliente(s) para poder usar el otro puerto, en lugar del puerto predeterminado. Existen numerosas soluciones a ese problema, pero nosotros cubrimos dos de ellas aquí.
Leer del socket fallido: connection reset by peer
Las versiones recientes de openssh a veces fallan con el mensaje de error anterior, debido a un error que implica la criptografía de curva elíptica. En este caso, añada la siguiente línea a
~/.ssh/config
:
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
Con openssh 5.9, la solución anterior no funciona. En su lugar, ponga las siguientes líneas en
~/.ssh/config
:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc 
MACs hmac-md5,hmac-sha1,hmac-ripemd160
Ver también
discussion
en el foro openssh bug.
«[your shell]: No such file or directory» / ssh_exchange_identification problem
Una posible causa de esto es la necesidad de ciertos clientes SSH de encontrar una ruta absoluta (una devuelta por
whereis -b [your shell]
, por instancia) en
$SHELL
, incluso si el binario de la shell se encuentra en una de las entradas
$PATH
.
Mensaje de error «Terminal unknown» o  «Error opening terminal»
Con ssh es posible recibir errores como «Terminal unknown» después de iniciar sesión. Iniciar aplicaciones ncurses como nano fallan con el mensaje «Error opening terminal». Hay dos métodos para solucionar este problema, uno rápido, mediante la variable $TERM, y otro más detallado usando el archivo terminfo.
Solución estableciendo la variable $TERM
Después de conectar con el servidor remoto establezca la variable $TERM para «xterm» con la siguiente orden:
TERM=xterm
Este método es una solución provisional y debe ser utilizado en servidores ssh al que se conecta raramente, ya que puede tener efectos secundarios no deseados. También tiene que repetir la orden después de cada conexión, o bien configurando ~.bashrc .
Solución usando el archivo terminfo
Una solución con más dedicación consiste en transferir el archivo terminfo del terminal en el equipo cliente al servidor ssh. En este ejemplo explicamos cómo configurar el archivo terminfo para el terminal «rxvt-unicode-256color».
Cree el directorio que contendrá los archivos terminfo en el servidor ssh, mientras se está conectado al servidor, con la orden:
mkdir -p ~/.terminfo/r/
Ahora copie el archivo terminfo de su terminal en el nuevo directorio. Reemplace
rxvt-unicode-256color
con el terminal de su cliente en la siguiente orden y
ssh-server
con el usuario y dirección del servidor correspondiente.
$ scp  /usr/share/terminfo/r/
rxvt-unicode-256color
ssh-server:~/.terminfo/r/
Después de salir y entrar en el servidor ssh el problema debe haber sido corregido.
Véase también
A Cure for the Common SSH Login Attack
[
enlace roto
2025-03-15]
Defending against brute force ssh attacks
OpenSSH key management, Part 1
and
Part 2
on IBM developerWorks