У меня есть пара открытого и закрытого ключей, которая ~/.sshиспользуется для SSH-подключения к GitHub.
Чтобы проверить, правильно ли я настроил SSH с GitHub, я использовал , и это отлично работает.ssh -T [email protected]
Кроме того, если я выполняю указанную выше команду как суперпользователь, то она работает нормально.
su
ssh -T [email protected]
Однако, когда я использую sudo, команда не работает. Я подозреваю, что она не может получить доступ к паре ключей, хранящейся в ~/.sshпри запуске сsudo
Приведенная ниже команда не выполняется.
sudo ssh -T [email protected]
Вы можете легко воспроизвести проблему с любым дистрибутивом Ubuntu иэтотСтраница помощи GitHub.
Редактировать:
Я понимаю, что могу передать закрытый ключ следующим sshобразом:
ssh -i <path-to-private-key> -T [email protected]
Мне просто интересно, почему использование делает закрытый ключ недоступным.sudo ssh -T [email protected]
решение1
Гипотеза: для вашего обычного пользователя запущен агент аутентификации, и у агента есть ключ.
sshсозданная из оболочки без повышенных привилегий, наследует важную переменную среды SSH_AUTH_SOCK, которая сообщает ей местоположение сокета для связи с агентом. sshможет использовать агент, именно так вы обычно используете агент.
suне сбрасывает переменную. sshafter suможет найти сокет благодаря переменной. Обычно сокет недоступен для пользователей, отличных от владельца, но теперь sshзапускается как root, и root может получить доступ (почти) к любому файлу независимо от его разрешений.
sudo делаетсбросить переменную (по умолчанию; см.этотичто). sshin sudo ssh …не может найти сокет. Как будто агента там не было. sshпытается найти правильный закрытый ключ в нескольких местах по умолчанию в ~/.ssh, но теперь он проверяет домашний каталог root, а не домашний каталог вашего обычного пользователя, где находится правильный закрытый ключ.
решение2
Путь к файлу идентификации можно передать с помощью параметра -i для ssh.
ssh user@host -i /path/to/keyfile