OpenSSH (Español)
Secure Shell 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 .
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:
Con dicha configuración, los siguientes comando son equivalentes:
$ ssh -p puerto usuario@dirección-servidor $ ssh miServidor
Vea 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.
Configuración
El archivo de configuración del demonio SSH se puede encontrar y editar en .
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 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
Gestión del Demonio
openssh viene con un archivo de unidad de systemd:
- , el cual mantendra el demonio de SSH permanentemente activo y bifurcara para cada conexión entrante. Es especialmente interesante para sistemas con bastante trafico de SSH.
Se puede activar y activar inicio automático de para empezar a usar el demonio.
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.
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.
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 :
PasswordAuthentication no
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:
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:
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
Usando iptables
Si su sistema ya esta usando iptables, se puede proteger fácilmente contra los ataques de fuerza bruta usando la siguientes reglas
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 (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 . Basta con cambiar a y descomentar la línea:
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 , 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 :
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 desde los repositorios oficiales o la última revisión 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 . Preguntará por tu contraseña, y luego ¡estarás conectado! El parámetro desactiva el prompt interactivo, y el especifica el puerto local en el cual escuchar (puedes elegir el numero de puerto que quieras). El parámetro desactiva la asignación pseudo-tty.
Le puede interesar añadir el parámetro verbose (), 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 en el campo "servidor SOCKS" , y luego escribe tu número de puerto en el siguiente campo de texto (
4711en 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 :
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 utilizadas por el servidor y el cliente para la autenticación de la sesión de X11 (fuente).
Configuración
En el sistema remoto:
- Instale xorg-xauth y desde los repositorios oficiales
- en :
- verifique que las opciones y están ajustadas a yes, y que está ajustado a 10 (esos son los valores por defecto si no se han cambiado, ver )
- ajuste
X11Forwardinga yes
- a continuación, reinicie el demonio sshd.
En el sistema cliente, active la opción , bien especificando el parámetro en la línea de órdenes para las conexiones ocasionales, bien ajustando a yes en el archivo de configuración del cliente de openSSH.
Utilización
Inicie sesión en el equipo remoto como de costumbre, especificando el parámetro 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 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 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 en
sshd_configen el server, o - ajuste la opción en
sshd_configen 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 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 y la especificación de reenvío se acompaña en forma de .
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 y utiliza la especificación de reenvío en forma de .
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 . La especificación puede ser cualquier dirección de la máquina en el inicio del túnel, , (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 viene asignada a . 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 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 adicionalmentesshd en uno de los puertos de la lista blanca:
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 , 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 :
Host examplehost.com ControlMaster auto ControlPersist yes ControlPath ~/.ssh/socket-%r@%h:%p
Vea la página del manual para obtener una descripción completa de estas opciones.
Otra opción para mejorar la velocidad es habilitar la compresión con el sufijo . Una solución permanente es agregar esta línea debajo del host correcto en :
Compression yes
El tiempo de inicio de sesión puede ser acortado usando el sufijo ,que saltea la búsqueda IPv6. Esto puede hacerse permanente añadiendo esta línea bajo el host correcto en :
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.
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 :
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 o a 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 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 o el global del sistema , 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 , 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 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í 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 implica 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 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 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 del cliente y del servidor son propiedad de sus usuario:
$ chown -R USER: ~/.ssh
3. Compruebe que, por ejemplo, la clave pública del cliente está en el archivo del servidor .
4. Compruebe que no se limitó el acceso a SSH a través de AllowUsers en (separadas por espacios).
Limpiar claves desactualizadas (opcional)
5. Elimine claves antiguas/no válidas del archivo del servidor.
6. Elimine claves antiguas/no válidas privadas y públicas dentro de la carpeta 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 :
¿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 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 para conocer errores, etc.
¿Existen reglas de firewall que bloqueen la conexión?
Iptables puede bloquear conexiones en el puerto . Compruebe esto con: y busque las posibles reglas que bloqueen paquetes en la cadena . Entonces, si es necesario, desbloquee el puerto con una orden como: 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?
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 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 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 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 :
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 :
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 , por instancia) en , incluso si el binario de la shell se encuentra en una de las entradas .
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:
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:
Ahora copie el archivo terminfo de su terminal en el nuevo directorio. Reemplace con el terminal de su cliente en la siguiente orden y 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
- Defending against brute force ssh attacks
- OpenSSH key management, Part 1 and Part 2 on IBM developerWorks