Tengo un servidor SSH ejecutándose en una Raspberry Pi para que mi amigo y yo podamos programar entre pares (o realmente simplemente jugar), pero, francamente, es demasiado viejo y no tiene suficiente potencia para hacer algo útil además de alojar algunos repositorios de Git. . ¿Es posible usarlo como una especie de proxy para compartir una sesión que se ejecuta en mi escritorio o en el de mi amigo?
Hasta ahora he estado enviando SSH a Pi desde mi escritorio, iniciando una sesión para que mi amigo se una y volviendo a enviar SSH a mi escritorio desde Pi dentro de esa sesión. También he estado iniciando una sesión en mi escritorio a través de ese laberinto, para poder conectarme a él en otra terminal local y usarlo sin ninguna latencia, pero toda la configuración parece realmente torpe.
Otro problema es que requiere la configuración de reenvío de puertos en el lado del usuario; Esto no es un problema para mí ya que el Pi está en la misma LAN, pero mi amigo no puede abrir un puerto de su lado, por lo que no puede compartir su propio espacio de trabajo.
Pensé que sería inteligente e iniciaría un socket local en el Pi montado con SSHFS, para que Tmux en realidad se ejecutara localmente pero mi amigo pudiera acceder a él, pero lamentablemente me dio un "Permiso denegado"... En retrospectiva, Probablemente no habría sido demasiado estable de todos modos.
En resumen, ¿hay alguna manera de reenviar mi sesión Tmux local a un dispositivo compartido para que otro usuario pueda acceder a él, sin preocuparme por SSH de un lado a otro o abrir puertos?
Respuesta1
En resumen, ¿hay alguna manera de reenviar mi sesión Tmux local a un dispositivo compartido para que otro usuario pueda acceder a él, sin preocuparme por SSH de un lado a otro o abrir puertos?
En resumen, no; tmux es solo local.
(Eltmatetenedor, sin embargo, parece estar construido exactamente para este propósito. Parece utilizar un servicio alojado en la nube para compartir la conexión).
Con tmux estándar, en lugar de usar Pi como proxy, haga que su amigo SSH acceda directamente a su escritorio, con supropiocuenta de usuario y haga lo mismo que hace actualmente.
O, alternativamente, otorgue directamente permisos a su cuenta para conectarse a su archivo de socket tmux (probablemente querrá usar la -Sopción para iniciar tmux con un socket separado para este propósito). Las versiones recientes de tmux tienen funcionalidad adicional para acceso multiusuario; el nuevo server-accesscomando se puede utilizar para otorgar acceso de solo lectura en lugar de lectura y escritura completa.
Otro problema es que requiere la configuración de reenvío de puertos en el lado del usuario; Esto no es un problema para mí ya que el Pi está en la misma LAN, pero mi amigo no puede abrir un puerto de su lado, por lo que no puede compartir su propio espacio de trabajo.
Utilice una VPN. Si configura OpenVPN o WireGuard en su computadora, su amigo puede conectarse a su servidor VPN, sin ningún "reenvío de puerto" de su parte, y luego usted puede conectarse a su escritorio a través del túnel VPN activo.
Hay varias VPN de "malla" o "peer-to-peer" que hacen esto aún más simple, sin necesidad de ninguna configuración de "servidor" (por ejemplo, Tailscale o ZeroTier son las sugerencias habituales; ambas descubren las conexiones peer-to-peer automáticamente ).
Pensé que sería inteligente e iniciaría un socket local en el Pi montado con SSHFS, para que Tmux en realidad se ejecutara localmente pero mi amigo pudiera acceder a él, pero lamentablemente me dio un "Permiso denegado"... En retrospectiva, Probablemente no habría sido demasiado estable de todos modos.
Los sockets con nombre solo existen en el sistema de archivos comonombres;las operaciones de socket reales no pasan por el sistema de archivos, por lo que tampoco se compartirán a través de SSHFS ni de ningún otro sistema de archivos de red. (Algunos sistemas de archivos de red antiguos, como RFS, podían hacer esto, pero todos los actuales no. Hay una razón por la que se llaman "localenchufes".)