И я про screen

[filin]

По итогам обсуждения у Витуса (1 серия, 2 серия) собрал и причесал:

source_ssh_auth:

fix_ssh_auth_sock () {
    if [ -e "$HOME/bin/fixssh" ]; then /bin/rm -f "$HOME/bin/fixssh"; fi
    if [ -S "$SSH_AUTH_SOCK" -a ! -L "$SSH_AUTH_SOCK" ]; then
        local new_ssh_auth_sock_dir
        new_ssh_auth_sock_dir="$HOME/.ssh/auth_sock"
        local new_ssh_auth_sock
        new_ssh_auth_sock="$new_ssh_auth_sock_dir/auth_sock.$(hostname)"
        if [ ! -d "$new_ssh_auth_sock_dir" ]; then
            mkdir -p "$new_ssh_auth_sock_dir" || return
        fi
        ln -sf "$SSH_AUTH_SOCK" "$new_ssh_auth_sock" || return
        SSH_AUTH_SOCK="$new_ssh_auth_sock"
        export SSH_AUTH_SOCK
    fi
}

case "$DISPLAY" in
    # don't run fix_ssh_auth_sock if logged in locally in X
    # because otherwise you'll lose connection to local ssh agent
    # after first remote or terminal login to this host
    :*) ;;
    *) fix_ssh_auth_sock ;;
esac

Что делает. Если видит в переменной SSH_AUTH_SOCK сокет ssh-агента (но не симлинк на него — поэтому ! -L), делает на него симлинк с well-known именем. После чего переставляет переменную SSH_AUTH_SOCK.

Единственная переменная часть в имени — hostname. Защита от проблем, возникающих в случае с NFS-mounted home.

Что позволяет. Типичная ситуация: с хоста A, где агент, идем с форвардом агента на хост B, запускаем там screen или tmux, и оттуда ходим на хосты C, D и т.д. Если не выполнить fix_ssh_auth_sock, то после первого detach, по любой причине, $SSH_AUTH_SOCK внутри screen останется негодным навсегда. А он случайный. А если выполнить, то после перелогина и подсоединения к сессии он снова станет годным. Будет через симлинк указывать на новый сокет.

Запускается... Во-первых, не запускается, а читается. "." (source), в смысле. Потому что надо переставить переменную. У меня из .zprofile, а остальным рекомендуется .profile или .bash_profile. Синтаксис намеренно выдержан таким, чтобы можно было запускать даже из dash.

Не надо запускать это из НЕинтерактивного шелла — агент отвалится после завершения команды. Честно говоря, маны на bash и dash мутны в части того, выполняется ли .profile из логинного, но неинтерактивного шелла. Подозреваю, что нет, но экспериментируйте себе сами.

.zlogin:

if [ -n "$SSH_CONNECTION" ]; then exec screen -xRR; fi

Что делает. При интерактивном логине по ssh молча запускает screen в режиме «если есть запущенная сессия, подцепиться к ней (к самой свежей по времени создания, если их несколько), НЕ отцепляя других возможных клиентов той же сессии; если ее нет, создать и подцепиться». Согласно man screen, именно с этими ключами screen запускается, если указать его в качестве логинного шелла.

Что позволяет. Не попадать в ситуации, когда надо бы отцепиться от сервера (положить спать ноутбук, с которого зашли), а команда на сервере оказалась слишком долгоиграющей, и прерывать ее не хочется. Или в ситуации, когда и не стал бы отключаться, да канал упал, не спросив. Общий принцип: зашел на удаленную машину — запусти screen.

Запускать. У меня из вышеуказанного .zlogin. У кого .profile или .bash_profile, оттуда последней командой.

Comments

[phd_ru]

Интересно, спасибо!

Мне почему-то это редко нужно. Хотя на удалённые сервера с отваливающимися соединениями я хожу постоянно.

Но раз есть готовое решение — возьму, пожалуй, на вооружение.

Меня смущает exec — если у меня проблемы с запуском screen, я потом смогу зайти интерактивно и починить? Не отключит exec мне возможность залогиниться?

[dmarck]

можно без экзека, один лишний процесс будет, ничему мешать не должно.

security implications вроде бы тоже не просматривается

[vitus_wagner]

Без эзека после отцепления screen сессия не завершится. И ты опять попадешь в shell на удаленной машине, но уже без screen.

[dmarck]

ммм, и в чём проблема, если у тебя не кончаются ttys?

[vitus_wagner]

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

[dmarck]

а, это да. но watch (если там был терминал) или по крайней мере kill (если не было) уж точно ж есть

да, немножко ядерное оружие, но

[vitus_wagner]

А ведь вся эта возня затевается для того,чтобы запущенный на удаленной машине процесс всегда попадал в сессию screen и можно было не бояться что его прибюьт SIGHUP-ом если коннект прервется.

А без exec у тебя оказывается достаточно большая вероятность что на экране будут валяться окна удаленных сессий без screen.

[dmarck]

я б кстати написал просто

[ -n "$SSH_CONNECTION" ] && screen -xRR

;-P

[vitus_wagner]

Я так и написал. Но после того как набрал exit внутри screen понял, что был неправ.

[dmarck]

стой-стой. моё написание в точности идентично твоему

или я в чего-то не увидел?

[vitus_wagner]

Я когда реализовывал у себя эту конструкию, сначала сделал как предлагаешь ты.
Но после того как попробовал завершить удаленную сессию, понял что это неправильно, и надо делать как предлагает Артем.

[dmarck]

прости.

я натурально не вижу семантической разницы (ну, sirca exec)

[filin]

И если мы не под ssh, то последняя команда в .zlogin завершится с ненулевым кодом. И мой zsh будет мне на это в промпте ругаться. Настроен так.

Потому что обычно я как раз хочу, чтобы он обращал моё внимание на факт неудачного завершения запущенной мной программы.

[filin]

ssh -t host bash

Это не считается интерактивным логином.

[phd_ru]

В крайнем случае ssh -t $host bash --norc

[vitus_wagner]

А может мы зря уперлись в создание сокета в ${HOME}?
Есть /tmp/user/$(id -u), есть /run/screen/S-${LOGNAME}
Эти места оказываются заведомо локальны для машины и не то чтобы совсем заведомо, но в типичной ситуации writable для юзера.

[dmarck]

это чуть специфично для разных систем. для фри это вообще /tmp/screens/S-${user}/

[vitus_wagner]

Да, и как-то штатного способа заставить screen рассаазать какой у него здесь путь, причем наружу, а не внутрь, я что-то не вижу.

[dmarck]

да, и это тоже анти-портабельная жопа

[dmarck]

и если ты в контейнере, из хоста тоже по-разному!

[vitus_wagner]

Если это настоящий контейнер, а не просто chroot, то какая разниа - все равно с хоста не дадут писать/читать сокет, созданный в контейнере.

[filin]

В /tmp/$USER хорошая мысль. А вот остальные — нет. Создать что-то в /tmp/user сумеет только тот, кто первым создал /tmp/user (нет, система её не создаёт). /run кому попало не writable, а /run/screen может отсутствовать, либо как сказано ниже, либо тупо за отсутствием screen на этой машине.

[vitus_wagner]

/tmp/user/$(id -u), насколько я помню, создает systemd. И прописывет это в ${TMPDIR}.

[filin]

А sysvinit не создает. Витус, ну если я заморачиваюсь про работу в dash, нешто я буду рассчитывать на наличие systemd? Из доброго десятка машин, на которые я вообще хожу, он на трёх. И только одна из них сервер, где это в основном имеет смысл.

Зато вот идея, что $HOME/.ssh тоже может не быть writable, у меня встречается. Правда, у служебных юзеров, под которыми могут заходить разные люди и к которым поэтому вообще не стоит форвардить агента.

(Кстати, только что дошло: мы привыкли прописывать ForwardAgent yes для хоста, не глядя на юзера на том конце. Для серверов, где есть такие служебные юзеры, и ты доверяешь не всем, кто туда ходит, это чревато боком, и надо ещё Match с user прописывать. Ну, если там есть недоверенный рут, то туда вообще нельзя агента форвардить.)

[filin]

А, нет, /tmp/$USER и т.п. плохая идея. Её может создать кто угодно, и безопасность тогда будет сами понимаете. Отследить её собственника и права можно, но геморройно и чревато race conditions. А права на .ssh у нас заведомо достаточно секьюрные. Ибо если туда может писать кто попало, то всё пропало :-) — там ведь authorized_keys.

[dmarck]

mktemp /tmp/${USER}.${`hostname`}

чтобы от луркеров защититься

и в хомяк его имя линком (поэтому в оригинале хост)

[filin]

Эээ... Зачем всё это? Сокет и так во временной директории.

[phd_ru]

А в zsh нет $HOSTNAME — вместо $(hostname)?

[filin]

Нет. Там есть HOST. А команду hostname зовут одинаково, по крайней мере во всех линуксах.

Впрочем, мы тут с Витусом обсуждаем что-то в духе создавать линк не в ~/.ssh/auth_sock/ и добавлять $(hostname) к имени сокета, а в /tmp/user-$(id -u)/ и ничего к имени не добавлять.

/tmp крайне редко бывает NFS-shared, даже если она NFS-mounted. Но с другой стороны, писать туда может кто попало, поэтому обеспечить безопасность такого решения я бы не взялся.

export SSH_AUTH_SOCK

[phd_ru]

export лишний. SSH_AUTH_SOCK к этому моменту уже проэкспортирован, а второй раз незачем.

Хуже от этого не будет, конечно.

Или в zsh другие правила переэкспортирования переменных?

if [ -n "$SSH_CONNECTION" ]; then exec screen -xRR; fi

[phd_ru]

exec screen -xRR у меня падает. Запускается и сразу на выход. Я подумал и стал подозревать, что проблема в том, что внутри screen тоже запускается .profile, в котором запускается exec screen; screen это отлавливает и прекращает цикл.

Поставил защиту: [ -n "$SSH_CONNECTION" -a -z "$STY" ] && exec screen -xRR. Теперь screen запускается, но перестал работать rsync. Похоже, у меня неинтерактивный ssh всё равно запускает .profile. Поставил ещё одну защиту, от неинтерактивного использования: -t 0. Пока всё работает. В целом конец моего .profile теперь выглядит так:

[ -n "$SSH_CONNECTION" -a -z "$STY" -a -t 0 ] && which screen >/dev/null 2>&1 &&
   exec screen -xRR -S default

Re: if [ -n "$SSH_CONNECTION" ]; then exec screen -xRR; fi

[phd_ru]

-t 0 не достаточно — эта защита не срабатывает в ситуации ssh -t host command. Пришлось усилить защиту — добавил проверку флага i (интерактив) в переменной $-:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return ;;
esac

# Stop if non-interactive shell
[ -z "$PS1" ] && return

if [ -n "$SSH_CONNECTION" -a -z "$STY" -a -t 0 ] &&
   which screen >/dev/null 2>&1
then
   exec screen -xRR -S default
fi

Re: if [ -n "$SSH_CONNECTION" ]; then exec screen -xRR; fi

[filin]

Интересно, что у тебя сразу две проверки на интерактивность... Одна — традиционная башевская, другая — на i в $-.

Бардак с файлами инициализации в bash для меня тоже один из поводов пользоваться zsh.

Re: if [ -n "$SSH_CONNECTION" ]; then exec screen -xRR; fi

[phd_ru]

Две проверки просто так, без причины. Я их натаскал когда-то из разных мест в .bashrc, а теперь вот скопировал в .profile :-)