У меня есть SSH-сервер, работающий на Raspberry Pi, так что мой друг и я можем программировать на peer-устройствах (или просто бездельничать), но, честно говоря, он слишком старый и недостаточно мощный, чтобы делать что-то полезное, кроме как размещать несколько репозиториев Git. Возможно ли использовать его как своего рода прокси-сервер для совместного использования сеанса, запущенного на моем рабочем столе или рабочем столе моего друга?
До сих пор я подключался по SSH к Pi со своего рабочего стола, запускал сеанс для присоединения моего друга и подключался по SSH обратно к своему рабочему столу с Pi в рамках этого сеанса. Я также запускал сеанс обратно на своем рабочем столе через этот лабиринт, чтобы я мог подключиться к нему на другом локальном терминале и использовать его без какой-либо задержки, но вся настройка кажется действительно неуклюжей.
Другая проблема заключается в том, что она требует настройки переадресации портов на стороне пользователя; для меня это не проблема, так как Pi находится в той же локальной сети, но мой друг не может открыть порт на своей стороне, поэтому он не может предоставить общий доступ к своему рабочему пространству.
Я подумал, что поступлю умно и запущу локальный сокет на Pi, смонтированный с помощью SSHFS, чтобы Tmux на самом деле работал локально, но был доступен моему другу, но, увы, он выдал мне сообщение «Отказано в доступе»... Оглядываясь назад, можно сказать, что он в любом случае, вероятно, был бы не слишком стабильным.
Короче говоря, есть ли способ перенаправить мой локальный сеанс Tmux на общее устройство, чтобы другой пользователь мог получить к нему доступ, не беспокоясь о SSH-подключении туда и обратно или открытии портов?
решение1
Короче говоря, есть ли способ перенаправить мой локальный сеанс Tmux на общее устройство, чтобы другой пользователь мог получить к нему доступ, не беспокоясь о SSH-подключении туда и обратно или открытии портов?
Короче говоря, нет; tmux работает только локально.
(Thetmateвилка, однако, похоже, создан именно для этой цели. Похоже, что он использует облачный сервис для совместного использования соединения.)
Со стандартным tmux — вместо использования Pi в качестве прокси-сервера, пусть ваш друг подключится по SSH к вашему рабочему столу напрямую, с егособственныйучетную запись пользователя и сделайте то же самое, что вы делаете сейчас.
Или, в качестве альтернативы, напрямую дайте его учетной записи разрешения на подключение к вашему файлу сокета tmux (вы, вероятно, захотите использовать опцию -Sзапуска tmux с отдельным сокетом для этой цели). Последние версии tmux имеют дополнительную функциональность для многопользовательского доступа; новую server-accessкоманду можно использовать для предоставления доступа только для чтения вместо полного доступа для чтения и записи.
Еще одна проблема заключается в том, что требуется настроить переадресацию портов на стороне пользователя; для меня это не проблема, поскольку Pi находится в той же локальной сети, но мой друг не может открыть порт на своей стороне, поэтому он не может предоставить общий доступ к своему рабочему пространству.
Используйте VPN. Если вы настроите OpenVPN или WireGuard на своем компьютере, ваш друг сможет подключиться к вашему VPN-серверу — без какой-либо «переадресации портов» на его стороне — а затем вы сможете подключиться к его рабочему столу через активный VPN-туннель.
Существует несколько «ячеистых» или «одноранговых» VPN, которые еще больше упрощают задачу, не требуя настройки «сервера» (например, обычно рекомендуются Tailscale или ZeroTier; оба они автоматически распознают одноранговые соединения).
Я подумал, что поступлю умно и запущу локальный сокет на Pi, смонтированный с помощью SSHFS, чтобы Tmux на самом деле работал локально, но был доступен моему другу, но, увы, он выдал мне сообщение «Отказано в доступе»... Оглядываясь назад, можно сказать, что он в любом случае, вероятно, был бы не слишком стабильным.
Именованные сокеты существуют в файловой системе только какимена;фактические операции сокета не проходят через файловую систему, поэтому они не будут совместно использоваться через SSHFS или любую другую сетевую файловую систему. (Некоторые древние сетевые файловые системы, такие как RFS, могли это делать, но все современные не могут. Недаром они называются "местныйРозетки".)