Ich habe einen SSH-Server auf einem Raspberry Pi laufen, auf dem mein Freund und ich Peer-Programmierung betreiben (oder einfach nur herumspielen) können, aber ehrlich gesagt ist er zu alt und zu schwach, um damit irgendetwas Sinnvolles zu tun, außer ein paar Git-Repos zu hosten. Ist es möglich, ihn als eine Art Proxy zu verwenden, um eine Sitzung freizugeben, die auf meinem eigenen oder dem Desktop meines Freundes läuft?
Bisher habe ich von meinem Desktop aus per SSH auf den Pi zugegriffen, eine Sitzung für meinen Freund gestartet und innerhalb dieser Sitzung per SSH vom Pi zurück auf meinen Desktop zugegriffen. Ich habe durch dieses Labyrinth auch eine Sitzung auf meinem Desktop gestartet, damit ich mich auf einem anderen lokalen Terminal damit verbinden und es ohne Latenz verwenden kann, aber die gesamte Einrichtung fühlt sich wirklich klobig an.
Ein weiteres Problem dabei ist, dass auf der Benutzerseite eine Portweiterleitung eingerichtet werden muss; das ist für mich kein Problem, da der Pi im selben LAN ist, aber mein Freund kann auf seiner Seite keinen Port öffnen, sodass er seinen eigenen Arbeitsbereich nicht freigeben kann.
Ich dachte, ich wäre schlau und würde einen lokalen Socket auf dem mit SSHFS gemounteten Pi starten, sodass Tmux tatsächlich lokal laufen würde, aber für meinen Freund zugänglich wäre, aber leider bekam ich die Meldung „Zugriff verweigert“ … Im Nachhinein betrachtet wäre es wahrscheinlich sowieso nicht allzu stabil gewesen.
Kurz gesagt: Gibt es eine Möglichkeit, meine lokale Tmux-Sitzung an ein gemeinsam genutztes Gerät weiterzuleiten, sodass ein anderer Benutzer darauf zugreifen kann, ohne sich um das Hin- und Her-SSH-Verfahren oder das Öffnen von Ports kümmern zu müssen?
Antwort1
Kurz gesagt: Gibt es eine Möglichkeit, meine lokale Tmux-Sitzung an ein gemeinsam genutztes Gerät weiterzuleiten, sodass ein anderer Benutzer darauf zugreifen kann, ohne sich um das Hin- und Her-SSH-Verfahren oder das Öffnen von Ports kümmern zu müssen?
Kurz gesagt, nein; tmux ist nur lokal.
(DertmateGabelscheint jedoch genau für diesen Zweck entwickelt worden zu sein. Es scheint einen in der Cloud gehosteten Dienst zum Teilen der Verbindung zu verwenden.)
Mit Standard-tmux – anstatt den Pi als Proxy zu verwenden, lassen Sie Ihren Freund direkt per SSH auf Ihren Desktop zugreifen, mit seinemeigenBenutzerkonto und machen Sie dasselbe wie bisher.
Oder erteilen Sie seinem Konto alternativ direkt die Berechtigung, eine Verbindung zu Ihrer tmux-Socket-Datei herzustellen (zu diesem Zweck möchten Sie wahrscheinlich die -SOption verwenden, tmux mit einem separaten Socket zu starten). Neuere tmux-Versionen verfügen über zusätzliche Funktionen für den Mehrbenutzerzugriff. Mit dem neuen server-accessBefehl können Sie anstelle von vollständigem Lese- und Schreibzugriff nur Lesezugriff gewähren.
Ein weiteres Problem besteht darin, dass auf der Benutzerseite eine Portweiterleitung eingerichtet werden muss. Für mich ist das kein Problem, da sich die Pis im selben LAN befinden, aber mein Freund kann auf seiner Seite keinen Port öffnen und kann daher seinen eigenen Arbeitsbereich nicht freigeben.
Verwenden Sie ein VPN. Wenn Sie OpenVPN oder WireGuard auf Ihrem Computer einrichten, kann Ihr Freund eine Verbindung zu Ihrem VPN-Server herstellen – ohne dass auf seiner Seite eine „Portweiterleitung“ erforderlich ist – und Sie können dann über den aktiven VPN-Tunnel eine Verbindung zu seinem Desktop herstellen.
Es gibt mehrere „Mesh“- oder „Peer-to-Peer“-VPNs, die dies noch einfacher machen, ohne dass eine „Server“-Einrichtung erforderlich ist (üblicherweise werden beispielsweise Tailscale oder ZeroTier empfohlen; beide ermitteln Peer-to-Peer-Verbindungen automatisch).
Ich dachte, ich wäre schlau und würde einen lokalen Socket auf dem mit SSHFS gemounteten Pi starten, sodass Tmux tatsächlich lokal laufen würde, aber für meinen Freund zugänglich wäre, aber leider bekam ich die Meldung „Zugriff verweigert“ … Im Nachhinein betrachtet wäre es wahrscheinlich sowieso nicht allzu stabil gewesen.
Benannte Sockets existieren im Dateisystem nur alsNamen;die eigentlichen Socket-Operationen laufen nicht über das Dateisystem, daher werden sie auch nicht über SSHFS oder ein anderes Netzwerkdateisystem geteilt. (Einige alte Netzwerkdateisysteme wie RFS konnten dies, aber alle aktuellen können es nicht. Es gibt einen Grund, warum sie "lokalSteckdosen".)