Может один доступ открытый терминал на компьютере через SSH?

Я надеюсь получать доступ к открытому терминалу, то есть, открытый локально на моей машине, от удаленного компьютера без использования tmux или screen. Существует несколько причин этого, самая простая из которых - то, что я продолжаю кончаться с ситуацией, где я не запланировал заранее, выполнял что-то большое на моем ПК на работе, идут домой и затем хотят проверить его через ssh.

В сущности я ищу способ подключить к терминалу, уже работающему на компьютере и просмотреть его вывод.

Теперь, я знаю, что существует несколько потоков там, которые говорят, что Вы не можете сделать этого (такие как этот), и другие, которые просто рекомендуют screen и tmux (как этот, этот или этот). То, что я ищу, является способом непосредственно получить доступ к рабочему терминальному процессу или по крайней мере видеть кэшируемый вывод того терминала. Я должен не обязательно смочь ввести команды в тот терминал.

Существует ли способ сделать это? Иначе, какие-либо идеи о взломе, который мог работать? Я думал, что мог, вероятно, найти способ автоматически зарегистрировать stdout, stderr и команды в файл (возможно, умная тонкая настройка на истории удара, которая регистрирует все?)

2
задан 28 July 2017 в 00:59

4 ответа

Просто из-за того, как терминалы создаются, не возможно получить доступ ко всему, т.е. Вы не можете просмотреть рабочий терминал и взаимодействовать с ним, если у Вас нет съемной сессии, работающей в упомянутом терминале, такой как screen или tmux сессия, или если Вы не запустили ту команду с входа через script команда.

То, что может быть сделано, является частично представлением TTY через sudo cat /dev/vcs1 команда. /dev/vcs[1-6] соответствуйте их соответствующим консолям TTY. Это ограничено scrollback размером буфера соответствующего TTY, что означает, что можно только видеть то, что сохранено в памяти до определенного числа строк. Это, конечно, может быть настроено для увеличения числа строк как показано в ответе muru здесь. С другой стороны, вероятно, необходимо попробовать

setterm -file log.txt -dump [ttynumbers]

который был упомянут в этом ssh вопросе.

В конце дня, bodhi.zazen правильно отмеченный в их комментарии, что Ваш отказ использовать screen или tmux самая большая проблема. Я полностью понимаю, я часто забываю отслеживать продолжительные программы сам, но с некоторыми командами необходимо начать предполагать.

4
ответ дан 2 December 2019 в 01:43

Из комментариев существует несколько потенциальных решений, но они все должны быть реализованы перед выполнением команды в графическом терминале.

Например, см. https://bugs.launchpad.net/ubuntu / + source/gnome-terminal / + ошибка/1356433

Таким образом, пользователи в рамках тех же X сессий не могут соединиться снова с закрытыми вкладками.

Можно попробовать reptyr, как предложено muru, и это - прохладное решение, но лучше запланировать ssh сессии лучше от запуска.

Необходимо разработать лучшую рабочую стратегию.

  1. Используйте экран или tmux или подобный. Эти инструменты были разработаны для точно этого сценария.

Лично я использую экран, поскольку я знаком с ним, и по причинам Вы заявляете, что я всегда использую экранную сессию по ssh, т.е. я запускаю экран, и verver действительно выходят из экранной сессии. Часто у меня есть более затем одна экранная сессия, один для каждого VM на хосте, например.

  1. Используйте сервер VNC. Можно выполнить сессию по ssh (VNC-over-SSH) или использовать FreeNX, который быстрее и более безопасен. НЕ ВЫПОЛНЯЙТЕ СЕРВЕР VNC ПО "ИНТЕРНЕТУ" БЕЗ SSH ИЛИ FREENX

VNC по ssh - https://www.cyberciti.biz/tips/tunneling-vnc-connections-over-ssh-howto.html

FreeNX - https://www.howtoforge.com/tutorial/freenx-ubuntu-14-04-trusty-tahr/

  1. Можно использовать Xpra

https://help.ubuntu.com/community/Xpra

http://xpra.org/

С xpra можно запустить и затем повторно прикрепить графический терминал, но снова необходимо выполнять xpra перед запуском терминала.

0
ответ дан 2 December 2019 в 01:43

Так как Вы отметили этот , в зависимости от версии, могло бы быть возможно просмотреть часть вывода. От этого сообщения в блоге, где автор хотел видеть то, что Терминал GNOME делает для "неограниченного" scrollback:

Я мог просто посмотреть на какой файлы gnome-terminal имел открытый, таким образом, lsof к спасению. Затем я нашел, что это было подлым, это имело много названных файлов /tmp/vteXYZ1tv открытый, но это уже удалило их. Таким образом Вы не видите их при просмотре, и они будут удалены, когда программа закроется. [...] Они могут быть восстановлены, хотя, мой путь (существуют, вероятно, другие), должен был сделать a ls -l /proc/<gnome-terminal pid>/fd видеть то, на что они указывают. Затем Вы можете cat они для создания нового файла. Это просто дословная копия терминального вывода. Никакое сжатие. Нет ничто.

Но в более новых версиях, файлы, как предполагается, шифруются. Из этого ответа:

vte-0.40 (который, скорее всего, появится в Ubuntu 15.10 W.W.) сожмет и зашифрует эти файлы. Это уменьшит необходимое устройство хранения данных к приблизительно третьему - четвертому из его размера (если Ваше приложение произведет X объемов данных как простой текст, где-нибудь между X/4.. X/3 является обоснованной оценкой для устройства хранения данных, это будет требоваться), и также избавляется от конфиденциальности/проблемы безопасности в случае, если кто-то получает необработанный доступ к жесткому диску.

Если Вы только хотите будущий вывод, Вы могли бы попытаться перетащить процесс к новому TTY, использующему reptyr.

2
ответ дан 2 December 2019 в 01:43

В зависимости от выполнения процесса в терминале Вы могли бы иметь успех путем заглядывания в состояние и действия, сделанные тем процессом, а не что это отобразило в терминале.

Несколько примеров, принимая Вы так или иначе выяснили PID (идентификатор процесса) данного процесса (например, использование pidof или ps):

  • Если данные подкоманды запусков инструмента один за другим, проверьте, какой выполняет использование ps.

  • Если данный инструмент иногда изменяет свой рабочий каталог, проверьте это в /proc/<PID>/cwd.

  • Если данный инструмент воздействует на многие файлы подряд, проверьте который открытое под /proc/<PID>/fd. Если Вы не видите никого в данный момент, могло бы случиться так, что Ваш процесс только что закрылся один и собирается открыть следующее; проверьте снова несколько раз на содержание того каталога.

  • Если команда воздействует на единственный огромный файл с помощью стандарта read/write syscalls, можно найти число дескриптора файла под /proc/<PID>/fd и проверьте на смещение тока в соответствующем файле под /proc/<PID>/fdinfo. Если команда использует pread/pwrite вместо этого затем посмотрите следующий пункт маркированного списка.

  • Можно соединиться с использованием процесса strace для наблюдения то, что это делает: strace -p <PID>. Выход вскоре после этого с помощью Ctrl+C (это завершается strace только, не приложение Вы прослеживаете). Исследуйте вывод и ищите соответствующий материал, который мог бы дать Вам общее представление. Используйте, например, -e trace опция ограничить этот вывод для регистрации операций только. Вы будете видеть, например, имена файлов, которые открываются Вашими приложениями, а также смещениями где pread/pwrite операции происходят.

0
ответ дан 2 December 2019 в 01:43

Другие вопросы по тегам:

Похожие вопросы: