Пересылку с SSH-агентом можно использовать для более удобного развертывания на сервере. Она позволяет использовать локальные ключи SSH, не оставляя ключи (без парольных фраз) на вашем сервере.
Если вы уже настроили ключ SSH для взаимодействия с GitHub, то наверняка знакомы с ssh-agent
. Это программа, которая выполняется в фоновом режиме и хранит ключ в памяти, благодаря чему не нужно вводить парольную фразу при каждом использовании ключа. Вы можете разрешить серверам доступ к локальному ssh-agent
, как если бы они уже работали на сервере. Это словно попросить друга ввести пароль, чтобы вы могли использовать его компьютер.
Дополнительные сведения о пересылки с SSH-агентом см. в руководстве Стива Фридла.
Настройка пересылки с SSH-агентом
Убедитесь, что ваш собственный ключ SSH настроен и работает. Если вы еще не создали ключ SSH, можете воспользоваться нашим руководством.
Вы можете проверить, работает ли локальный ключ, введя ssh -T git@github.com
в терминале:
$ ssh -T git@github.com
# Attempt to SSH in to github
> Hi USERNAME! You've successfully authenticated, but GitHub does not provide
> shell access.
Отличное начало. Давайте настроим SSH, чтобы разрешить пересылку на сервер с использованием агента.
-
Откройте файл в папке
~/.ssh/config
в предпочитаемом текстовом редакторе. Если этот файл не существует, вы можете создать его, введя командуtouch ~/.ssh/config
в терминале. -
Введите в файл следующий текст, заменив
example.com
доменным именем или IP-адресом сервера:Host example.com ForwardAgent yes
Warning
Вы можете заманить использовать подстановочный знак, как Host *
просто применить этот параметр ко всем подключениям SSH. Это не очень хорошая идея, так как тогда вы будете делиться своими локальными ключами SSH с каждым сервером, в который вы входите с помощью SSH. У них не будет прямого доступа к ключам, но они смогут использовать их от вашего имени при установке подключения. Добавляйте только те серверы, которым вы доверяете, и которые планируете использовать с функцией пересылки с использованием агента.
Проверка пересылки с SSH-агентом
Чтобы проверить, что пересылка работает с сервером, можете выполнить вход с помощью SSH на сервер и запустить ssh -T git@github.com
еще раз. Если все хорошо, появится та же подсказка, что и в локальной среде.
Если вы не уверены, используется ли локальный ключ, можете также проверить переменную SSH_AUTH_SOCK
на сервере:
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/ssh-4hNGMk8AZX/agent.79453
Если переменная не задана, это означает, что пересылка с использованием агента не работает:
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> [No output]
$ ssh -T git@github.com
# Try to SSH to github
> Permission denied (publickey).
Устранение неполадок с пересылкой с использованием SSH-агента
Ниже приведены некоторые аспекты, которые следует учитывать при устранении неполадок при пересылке с использованием агента SSH.
Для извлечения кода необходимо использовать URL-адрес SSH.
Пересылка SSH работает только с URL-адресами SSH, а не с URL-адресами HTTP. Проверьте файл на сервере .git/config
и убедитесь, что URL-адрес является URL-адресом в стиле SSH, как показано ниже.
[remote "origin"]
url = git@github.com:YOUR_ACCOUNT/YOUR_PROJECT.git
fetch = +refs/heads/*:refs/remotes/origin/*
Ключи SSH должны работать локально
Прежде чем настраивать пересылку с использованием агента, убедитесь, что ключи работают локально. Наше руководство по созданию ключей SSH поможет вам настроить ключи SSH в локальной среде.
Система должна разрешать пересылку с использованием SSH-агента
В некоторых случаях конфигурация системы запрещает пересылку с использованием SSH-агента. Чтобы проверить, используется ли файл конфигурации системы, введите следующую команду в терминале:
$ ssh -v URL
# Connect to the specified URL with verbose debug output
> OpenSSH_8.1p1, LibreSSL 2.7.3
> debug1: Reading configuration data /Users/YOU/.ssh/config
> debug1: Applying options for example.com
> debug1: Reading configuration data /etc/ssh_config
> debug1: Applying options for *
$ exit
# Returns to your local command prompt
В приведенном выше примере сначала загружается файл ~/.ssh/config
, а затем считывается /etc/ssh_config
. Мы можем проверить этот файл, чтобы узнать, переопределяет ли он заданные вами параметры, выполнив следующие команды:
$ cat /etc/ssh_config
# Print out the /etc/ssh_config file
> Host *
> SendEnv LANG LC_*
> ForwardAgent no
В этом примере в файле /etc/ssh_config
указывается ForwardAgent no
, что является способом блокировки пересылки с использованием агента. После удаления этой строки из файла эта функция должна заработать.
Сервер должен разрешить пересылку с использованием агента SSH для входящих подключениях
Пересылка с использованием агента также может быть заблокирована на сервере. Вы можете проверить, разрешена ли пересылка с использованием агента, подключившись по протоколу SSH к серверу и выполнив sshd_config
. Выходные данные этой команды должны указывать на то, что AllowAgentForwarding
задано.
Локальный ssh-agent
должен работать
На большинстве компьютеров операционная система автоматически запускает ssh-agent
. Однако на Windows это необходимо сделать вручную. У нас есть руководство по запуску ssh-agent
при открытии Git Bash.
Чтобы убедиться, что ssh-agent
работает на вашем компьютере, введите следующую команду в терминале:
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/launch-kNSlgU/Listeners
Ключ должен быть доступен для ssh-agent
Чтобы убедиться, что ключ виден ssh-agent
, выполните следующую команду:
ssh-add -L
Если в выходных данных команды указано, что удостоверение недоступно, добавитье ключ:
ssh-add YOUR-KEY
На macOS ssh-agent
"забудет" этот ключ при повторном запуске после перезагрузки, но вы можете импортировать ключи SSH в цепочку ключей с помощью следующей команды:
ssh-add --apple-use-keychain YOUR-KEY
Note
Параметр --apple-use-keychain
сохраняет парольную фразу в цепочке ключей при добавлении ключа SSH в агент SSH. Если вы решили не добавлять парольную фразу в ключ, выполните команду без параметра --apple-use-keychain
.
Вариант --apple-use-keychain
находится в стандартной версии ssh-add
Apple. В версиях macOS до Монтерей (12.0) --apple-use-keychain
и --apple-load-keychain
флаги использовали синтаксис -K
и -A
соответственно.
Если у вас нет стандартной ssh-add
версии Apple, может появиться сообщение об ошибке. Дополнительные сведения см. в разделе «Ошибка: ssh-add: недопустимый параметр - apple-use-keychain».
Если вы продолжаете запрашивать парольную фразу, может потребоваться добавить команду в ~/.zshrc
файл (или ~/.bashrc
файл для bash).