Использование локального .bashrc через ssh и консолидация истории выполнения команд

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
Если вам приходится работать с большим количеством удаленных машин через ssh то возникает вопрос как унифицировать shell окружение на этих машинах. Копировать заранее .bashrc не очень удобно, а зачастую невозможно. Давайте рассмотрим вариант копирования непосредственно в процессе соединения:

[ -z "$PS1" ] && return

sshb() {
    scp ~/.bashrc ${1}:
    ssh $1
}

# the rest of the .bashrc
alias c=cat
...

Это очень наивный способ с несколькими очевидными недостатками:

  • Можно затереть уже существующий .bashrc
  • Вместо одного соединения мы устанавливаем 2
  • Как следствие авторизоваться придется тоже 2 раза
  • Аргумент функции может быть только адресом удаленной машины

Улучшенный вариант:

[ -z "$PS1" ] && return

sshb() {
    local ssh="ssh -S ~/.ssh/control-socket-$(tr -cd '[:alnum:]' < /dev/urandom|head -c8)"
    $ssh -fNM "$@"
    $ssh placeholder "cat >~/.bash-ssh" <~/.bashrc
    $ssh "$@" -t "bash --rcfile ~/.bash-ssh -i"
    $ssh placeholder -O exit >/dev/null 2>&1
}

# the rest of the .bashrc
alias c=cat
...

Теперь мы используем только одно соединение за счет мультиплексирования. .bashrc копируется в файл, который не используется bash по умолчанию и мы явно указываем его через опцию --rcfile. Аргументом функции может быть не только адрес удаленной машины, но и другие опции ssh.

На этом в принципе можно было бы и остановиться, но полученное решение обладает неприятным недостатком. Если вы запустите screen или tmux, то будет использоваться тот .bashrc, который находится на удаленной машине и все ваши алиасы и функции потеряются. К счастью это можно побороть. Для этого надо создать скрипт-обертку, который мы объявим нашим новым шеллом. Давайте для простоты предположим, что скрипт-обертка на удаленной машине у нас уже есть и находится в ~/bin/bash-ssh. Выглядит скрипт вот так::

#!/bin/bash
exec /bin/bash --rcfile ~/.bash-ssh “$@”

А .bashrc так:

[ -n "$SSH_TTY" ] && export SHELL="$HOME/bin/bash-ssh"

[ -z "$PS1" ] && return

sshb() {
    local ssh="ssh -S ~/.ssh/control-socket-$(tr -cd '[:alnum:]' < /dev/urandom|head -c8)"
    $ssh -fNM "$@"
    $ssh placeholder "cat >~/.bash-ssh" <~/.bashrc
    $ssh "$@" -t "bash --rcfile ~/.bash-ssh -i"
    $ssh placeholder -O exit >/dev/null 2>&1
}

# the rest of the .bashrc
alias c=cat
...

Если существует переменная SSH_TTY мы понимаем, что находимся на удаленной машине и переопределяем переменную SHELL. С этого момента при запуске нового интерактивного шелла будет запускаться скрипт, который будет стартовать bash с нестандартным конфигом, сохраненный при установлении ssh сессии.

Для получения удобного рабочего решения осталось придумать как создавать на удаленной машине скрипт-обертку. В принципе можно создавать его в сохраняемом нами конфиге баша вот так:

[ -n "$SSH_TTY" ] && {
    mkdir -p "$HOME/bin"
    export SHELL="$HOME/bin/bash-ssh"
    echo -e '#!/bin/bash\nexec /bin/bash --rcfile ~/.bash-ssh "$@"' >$SHELL
    chmod +x $SHELL
}

Но на самом деле можно обойтись единственным файлом ~/.bash-ssh:

#!/bin/bash

[ -n "$SSH_TTY" ] && [ "${BASH_SOURCE[0]}" == "${0}" ] && exec bash --rcfile "$SHELL" "$@"

[ -z "$PS1" ] && return

sshb() {
    local ssh="ssh -S ~/.ssh/control-socket-$(tr -cd '[:alnum:]' < /dev/urandom|head -c8)"
    $ssh -fNM "$@"
    $ssh placeholder "cat >~/.bash-ssh" <~/.bashrc
    $ssh "$@" -t 'SHELL=~/.bash-ssh; chmod +x $SHELL; bash --rcfile $SHELL -i'
    $ssh placeholder -O exit >/dev/null 2>&1
}


# the rest of the .bashrc
alias c=cat
...

Теперь файл ~/.bash-ssh является одновременно и самостоятельным скриптом и конфигом bash. Работает это так. На локальной машине команды после [ -n "$SSH_TTY" ] игнорируются. На удаленной машине функция sshb создает файл ~/.bash-ssh и использует его как конфиг для запуска интерактивной сессии. Конструкция [ "${BASH_SOURCE[0]}" == "${0}" ] позволяет определить подгружается файл другим скриптом или запущен как самостоятельный скрипт. В результате, когда ~/.bash-ssh используется
  • как конфиг — exec игнорируется
  • как скрипт — управление переходит башу и исполнение ~/.bash-ssh заканчивается тем самым exec-ом.


Теперь при коннекте по ssh ваше окружение везде будет выглядеть одинаково. Так работать гораздо удобнее, но история выполнения команд будет оставаться на машинах, с которыми вы соединялись. Лично мне бы хотелось сохранять историю локально, чтобы иметь возможность освежить в памяти, что именно я делал на каких-то машинах в прошлом. Для того, чтобы это сделать нам нужны следующие компоненты:
  • Tcp сервер на локальной машине, который бы принимал данные с сокета и перенаправлял их в файл
  • Форвард слушающего порта этого сервера на машину, с которой мы коннектимся по ssh
  • PROMPT_COMMAND в установках bash, который бы по завершению команды отправлял обновление истории на отфорварженный порт
Это можно реализовать так:

#!/bin/bash

[ -n "$SSH_TTY" ] && [ "${BASH_SOURCE[0]}" == "${0}" ] && exec bash --rcfile "$SHELL" "$@"

[ -z "$PS1" ] && return

[ -z "$SSH_TTY" ] && {
    history_port=26574
    netstat -lnt|grep -q ":${history_port}\b" || {
        umask 077 && nc -kl 127.0.0.1 "$history_port" >>~/.bash_eternal_history &
    }
}

HISTSIZE=$((1024 * 1024))
HISTFILESIZE=$HISTSIZE
HISTTIMEFORMAT='%t%F %T%t'

update_eternal_history() {
    local histfile_size=$(stat -c %s $HISTFILE)
    history -a
    ((histfile_size == $(stat -c %s $HISTFILE))) && return
    local history_line="${USER}\t${HOSTNAME}\t${PWD}\t$(history 1)"
    local history_sink=$(readlink ~/.bash-ssh.history 2>/dev/null)
    [ -n "$history_sink" ] && echo -e "$history_line" >"$history_sink" 2>/dev/null && return
    local old_umask=$(umask)
    umask 077
    echo -e "$history_line" >> ~/.bash_eternal_history
    umask $old_umask
}

[[ "$PROMPT_COMMAND" == *update_eternal_history* ]] || export PROMPT_COMMAND="update_eternal_history;$PROMPT_COMMAND"

sshb() {
    local ssh="ssh -S ~/.ssh/control-socket-$(tr -cd '[:alnum:]' < /dev/urandom|head -c8)"
    $ssh -fNM "$@"
    local bashrc=~/.bashrc
    [ -r ~/.bash-ssh ] && bashrc=~/.bash-ssh && history_port=$(basename $(readlink ~/.bash-ssh.history))
    local history_remote_port="$($ssh -O forward -R 0:127.0.0.1:$history_port placeholder)"
    $ssh placeholder "cat >~/.bash-ssh; ln -nsf /dev/tcp/127.0.0.1/$history_remote_port ~/.bash-ssh.history" < $bashrc
    $ssh "$@" -t 'SHELL=~/.bash-ssh; chmod +x $SHELL; bash --rcfile $SHELL -i'
    $ssh placeholder -O exit >/dev/null 2>&1
}

# the rest of the .bashrc
alias c=cat
...

Блок после [ -z "$SSH_TTY" ] срабатывает только на локальной машине. Мы проверяем занят ли порт и если нет запускаем на нем netcat, вывод которого перенаправлен в файл.

Функция update_eternal_history вызывается непосредственно перед выводом на экран подсказки bash. Эта функция проверяет не была ли последняя команда дубликатом и если нет отправляет ее на отфорварженный порт. Если порт не сконфигурирован (в случае локальной машины) или если при отправке произошла ошибка сохранение идет в локальный файл.

Функция дополнилась установлением форвардинга порта и созданием симлинки, которая будет использоваться update_eternal_history для отправки данных на сервер.

Это решение не лишено недостатков:
  • Порт для netcat захардкожен, есть шанс нарваться на конфликт
  • Форвард порта дает возможность любому человеку со злыми намерениями заспамить вашу историю мусорными данными
  • Если вы создаете цепочку соединений (машина А-машина Б-машина В), то данные будут нормально передаваться с В на А, но в случае обрыва соединения между А и Б и установления нового соединения Б будет продолжать форвардить старый порт и данные с В не достигнут А, они будут сохраняться на Б

Мой собственный .bashrc можно посмотреть тут.

Если у вас есть идеи как можно улучшить предложенное решение пожалуйста делитесь в комментариях.
Источник: https://habr.com/ru/post/529544/


Интересные статьи

Интересные статьи

Использование контроля версий для разработки в ERP-системе MS Dynamics AX — штука довольно неоднозначная. Кто-то не использует совсем, кто-то использует встроенную систему контроля версий...
Работа над вакцинами и лекарствами против коронавируса идет полным ходом, однако ученым приходится решать множество проблем. По данным CNN, на этапе разработки находится более 20 лекарственных ср...
Серьезная альтернативная история (а не «спецназовец Вася попал в палеолит и построил светлое будущее») хороша тем, что дает более широкую картину и позволяет понять, почему произошло именно то, ч...
Сотрудник, который много знает, умеет и готов потушить любой пожар на своей поляне, конечно, молодец. Но если этот герой уходит в отпуск или вообще увольняется, наступают тяжелые времена. Оказыва...
Начнём с постановки задачи. Надо в каждом запросе в header’s отправлять токен и id юзера Надо из каждого ответа вытаскивать из headers новый токен и id юзера Полученные данные надо сохр...