Cómo configurar un túnel SSH automático

Cómo configurar un túnel SSH automático

He estado usando la función de reenvío remoto de SSH para reenviar conexiones a un socket de dominio Unix en un host remoto example.coma un socket de dominio Unix en mi máquina local. Ambas máquinas ejecutan Linux. El comando es el siguiente:

ssh -N -n -R /home/guest/daemon.sock:/var/run/daemon.sock [email protected]

Quiero automatizar esto para que el túnel se cree automáticamente cada vez que se inicie mi máquina. Copié el archivo /etc/ssh/ssh_host_rsa_key.pub de mi máquina local al control remoto /home/guest/.ssh/id_rsa.puby agregué las siguientes líneas /etc/ssh/ssh_configen mi máquina local:

Host example.com User guest IdentityFile /etc/ssh/ssh_host_rsa_key RemoteForward /home/guest/daemon.sock /var/run/daemon.sock

Por razones de seguridad, también quiero restringir al usuario 'invitado' en la máquina remota a la creación de túneles y nada más. Por lo tanto, agregué las siguientes líneas /etc/ssh/sshd_configen el host remoto:

match User guest AllowTcpForwarding yes X11Forwarding no AllowAgentForwarding no ForceCommand /bin/false

Aquí está el problema: no sucede nada cuando se inicia mi máquina local. Estoy seguro de que me falta algo importante, pero no pude encontrar qué. ¿Algunas ideas?

Respuesta1

El ssh_configarchivo no hace absolutamente nada para automatizar las conexiones SSH.

Sólo existe para permitir definir elopciones predeterminadas– Cada vez que ejecuta ssh example.com, se busca la sección "Host" correspondiente y se agregan todas las opciones a la línea de comando. (Se podría decir que es similar a los alias de shell). El término por usuario ~/.ssh/configse usa más comúnmente para el mismo propósito.

Pero todavía depende de ustedcorrerel sshcomando, por ejemplo, a través de una unidad systemd .service, o un script /etc/init.d, o un trabajo cron. (No olvide definir en el servicio que debe iniciarse después de configurar la red).

(TúpuedeContinúe usando ssh_config, pero es inútil aquí y solo haráregularConexiones example.commolestas. En su lugar, simplemente especifique las mismas opciones directamente en el archivo de servicio).


Si bien no es ilegal, es algo extraño reutilizar la clave del host para la autenticación del lado del cliente. Sería mejor generar un par de claves dedicado usando ssh-keygen.

Y como @Paul señaló en el comentario, las claves confiables deben incluirse authorized_keys: al servidor SSH no le importan ninguno de los id_*archivos.

información relacionada