Переадресация агента SSH не работает

Question

Правдоподобное объяснение выглядит следующим образом: когда вы sshперемещаетесь из точки A в точку B, скрипт запуска оболочки, который получает доступ к точке B, запускает агента, локального для точки B.

В случае, если Bash является вашей оболочкой на B,проверьте свой .bashrcна B.

Предположим, что сценарийправильно запускает агенталокальный для B. Это означает, что он перезаписывает соответствующие переменные среды ( $SSH_AUTH_SOCKпо сути) в оболочке на B. По сути, все, что пытается использовать агента в этом сеансе оболочки, обнаружит, что агент работает на B, который ничего не знает о ваших ключах на A. Когда вы переходите sshиз B в C, у агента на B нет идентификаторов, и вас просят ввести пароль для ключа, /home/myid/.ssh/id_rsaхранящегося на B.

Если бы вы знали предыдущее значение $SSH_AUTH_SOCKна B, вы могли бы найти сокет на B, который все еще подключен к агенту, работающему на A. Если бы вы (вручную) изменили $SSH_AUTH_SOCKобратно на предыдущее значение, все бы заработало так, как вы ожидаете. Я хочу сказать, что сама переадресация не сломана, сокет, предоставленный сервером SSH на B, есть и работает. Проблема в том, что ваши процессы на B не могут его найти, потому что они находят и используют вместо этого неправильный сокет из-за того, что агент на B был запущен и $SSH_AUTH_SOCKизменен.

Вы можете исправить это, не разрешив скрипту запуска на B запускать нового агента. Ответственный код, вероятно, находится там по какой-то причине, поэтому его удаление не обязательно является хорошей идеей. Спросите себя, в чем причина. Если есть причина сохранить код, то разумным решением будет заставить скрипт проверять, $SSH_AUTH_SOCKрасширяется ли он до пустой строки, и только после этого настраивать нового агента.

Я не могу быть уверен, что это то, что происходит.в вашем конкретном случае; тем не менее я считаю, что этот сценарий правдоподобен.

Answer 1

Правдоподобное объяснение выглядит следующим образом: когда вы sshперемещаетесь из точки A в точку B, скрипт запуска оболочки, который получает доступ к точке B, запускает агента, локального для точки B.

В случае, если Bash является вашей оболочкой на B,проверьте свой .bashrcна B.

Предположим, что сценарийправильно запускает агенталокальный для B. Это означает, что он перезаписывает соответствующие переменные среды ( $SSH_AUTH_SOCKпо сути) в оболочке на B. По сути, все, что пытается использовать агента в этом сеансе оболочки, обнаружит, что агент работает на B, который ничего не знает о ваших ключах на A. Когда вы переходите sshиз B в C, у агента на B нет идентификаторов, и вас просят ввести пароль для ключа, /home/myid/.ssh/id_rsaхранящегося на B.

Если бы вы знали предыдущее значение $SSH_AUTH_SOCKна B, вы могли бы найти сокет на B, который все еще подключен к агенту, работающему на A. Если бы вы (вручную) изменили $SSH_AUTH_SOCKобратно на предыдущее значение, все бы заработало так, как вы ожидаете. Я хочу сказать, что сама переадресация не сломана, сокет, предоставленный сервером SSH на B, есть и работает. Проблема в том, что ваши процессы на B не могут его найти, потому что они находят и используют вместо этого неправильный сокет из-за того, что агент на B был запущен и $SSH_AUTH_SOCKизменен.

Вы можете исправить это, не разрешив скрипту запуска на B запускать нового агента. Ответственный код, вероятно, находится там по какой-то причине, поэтому его удаление не обязательно является хорошей идеей. Спросите себя, в чем причина. Если есть причина сохранить код, то разумным решением будет заставить скрипт проверять, $SSH_AUTH_SOCKрасширяется ли он до пустой строки, и только после этого настраивать нового агента.

Я не могу быть уверен, что это то, что происходит.в вашем конкретном случае; тем не менее я считаю, что этот сценарий правдоподобен.

Переадресация агента SSH не работает

решение1

Связанный контент