информация о передаче о соединении от ssh клиента к ssh серверу
предположите, что у меня есть следующая ssh сессия:
userA@boxA -> userB@boxB -> userC@boxC
теперь, от boxC, как userC, Я хотел бы иметь информацию, из которой прибыло соединение SSH userB@boxB который в свою очередь прибыл из userA@boxA.
теперь у меня есть следующая ssh сессия наряду с первой ssh сессией:
userD@boxD -> userB@boxB
от boxB, как userB, Я хотел бы иметь информацию, из которой прибыло соединение userD@boxD и это там - вторая ssh сессия, прибывающая из userA@boxA.
действительно ли эта информация доступна и доступна как пользователь? это даже доступно вообще?
в противном случае там какой-либо "легкий" путь состоит в том, чтобы сделать эту информацию доступной? с легким я имею в виду, не взламывая и перекомпилировав sshd, и не имея необходимость иметь корневой доступ на машинах.
4 ответа
Официальный способ отправить переменные среды от клиента к серверу через SendEnv и AcceptEnv. Проблема состоит в том, что Вы должны базироваться доступ на сервере для конфигурирования AcceptEnv. Большинство серверов настроено для принятия не или только несколько предопределенных переменных.
Я нашел, что два приема отправили переменные среды от клиента к серверу, обеим работам, не нуждаясь в корневом доступе на сервере.
обманите тот:
ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME bash
это соединится с сервером и затем выполнит команду SSH_ORIGIN=$USERNAME@$HOSTNAME bash, с $USERNAME и $HOSTNAME уже замененный на стороне клиента. затем, на стороне сервера, можно далее обработать информацию, содержавшуюся в переменной SSH_ORIGIN.
-t необходим иначе, удар будет запущен на сервере без tty (попробуйте его, Вы будете видеть).
небольшая модификация позволит передавать информацию transitively вниз более длинная ssh цепочка.
ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN bash
обсуждение:
- удар запускается как интерактивная оболочка невхода в систему (
.profileне читается). - удар выполняется дважды (
.bashrcчитается дважды). однажды sshd и однажды пользовательской командой. - это будет всегда запускать удар, игнорируя Вашу оболочку по умолчанию на сервере.
прием два:
сначала необходимо генерировать ssh ключ и передачу это к ~/.ssh/authorized_keys на сервере. затем предварительно ожидайте строку с command="$SHELL". см. sshd страницу справочника для получения дополнительной информации об этом.
соединитесь с ssh сервером с помощью команды:
ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME
это соединится с сервером, но на этот раз переменное присвоение не выполняется. вместо этого, строка хранится в переменной среды $SSH_ORIGINAL_COMMAND. затем команда, обеспеченная в ~/.ssh/authorized_keys выполняется. после того как Вы находитесь в оболочке, можно обработать информацию, содержавшуюся в $SSH_ORIGINAL_COMMAND.
как выше, можно сделать это переходным:
ssh -t server SSH_ORIGIN=$USERNAME@$HOSTNAME:$SSH_ORIGIN
обсуждение:
- это запустит оболочку по умолчанию на сервере.
- это будет всегда запускать оболочку по умолчанию на сервере. любая команда, которую Вы даете команде ssh, будет проигнорирована и сохранена в
$SSH_ORIGINAL_COMMAND. если Вы хотите выполнить команду по ssh, можно использовать другой ssh ключ или иметь оболочку init файл, чтобы обнаружить и выполниться$SSH_ORIGINAL_COMMAND.
Команда who говорит Вам, кто еще зарегистрирован теперь на той же машине и откуда они вошли в систему. Команда last дает ту же информацию для прошлых сессий. В зависимости от конфигурации машины и методов входа в систему, информация не может всегда быть полна, актуальна или доступна некорневым пользователям.
В Вашем A@A-> B@B-> сценарий C@C, невозможно от машины C знать, что в B@B вошли B через ssh сессию от A. В 1980-х, когда все доверяли всем, Вы, возможно, попробовали finger или ident, но в эти дни машина B вряд ли будет даже водить пальцем или ident демоном.
От Поля C, без доступа к Полю B, Вы не смогли бы сказать, что пользователь произошел из Поля A. На самом деле Вы не можете говорить, как пользователь добрался до Поля C. Это просто зависит от того, как администратор настроил вещи.
Тот же ответ для "предполагает далее" вопрос. Это зависит от полномочий, которые системный администратор дал Вам и программам, которые он установил.
Соответствующие команды, которые помогли бы Вам, если бы у Вас были полномочия (но Вы, вероятно, не делаете):
finger - http://www.manpagez.com/man/1/finger/
last - http://www.manpagez.com/man/1/last/