Почему переадресация агента ssh не работает?

58

На моем собственном компьютере под управлением MacOSX это находится в ~ / .ssh / config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 - это виртуальная машина под управлением Ubuntu 12.04. Я ssh к нему так:

ssh pupeno@b1

и я вошел в систему без запроса пароля, потому что я уже скопировал свой открытый ключ. Из-за переадресации я должен иметь возможность использовать ssh для pupeno @ b1 с b1, и он должен работать, не спрашивая у меня пароль, но это не так. Он просит у меня пароль.

Чего мне не хватает?

Это подробный вывод второго ssh:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

— pupeno
источник

94

Оказывается, мой ключ не был в агенте, и это исправило это:

OS X :

ssh-add -K

Linux / Unix :

ssh-add -k

Вы можете перечислить загруженные ключи, используя:

ssh-add -l

ssh-add -L # for more detail

— pupeno
источник

5

Обратите внимание, что ssh-add -Kэто характерно для OS X.

— Роджер Липскомб

Вы должны делать это при каждой перезагрузке?

— Краузер

8

Проверьте, имеют ли ваши ./ssh/id_rsa .ssh/id_dsa .ssh/id_ecdsaфайлы правильные разрешения, которые должны принадлежать вашему пользователю и быть chmoded 600.
Убедитесь, что у вас есть правильный открытый ключ на pupeno/.ssh/authorized_keysb1, и проверьте, authorized_keysесть ли разрыв строки в конце ключа.
Проверьте, запущен ли ssh-agent, попробуйте загрузить ключи через ssh-add
Попробуйте аутентификацию и пересылку на основе GSSAPI с ssh -K

— Даниэль Прата Алмейда
источник

С разрешениями ключей все в порядке, а с ключом в author_keys все в порядке (в противном случае, я думаю, у меня возникнут проблемы с подключением в первую очередь).

— Пупено

У вас был запущен ssh-agent? Что происходит, когда вы делаете ssh-add, затем ssh -A pupeno @ b1 и затем ssh pupeno @ b1?

— Даниэль Прата Алмейда

Почему бы вам не обновить ответ, чтобы упомянуть ssh-add -K, и я приму ваш вместо моего (так как информация была опубликована почти одновременно).

— Пупено

6

У меня была проблема с запросом перенаправления агента, отклонившим сервер sshd из-за отсутствия свободного места в / tmp. Это потому, что sshd нужно создать сокет в / tmp. Очистка диска решила мою проблему.

ssh -v сказал тогда:

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

— BartBiczBoży
источник

1

У меня была та же проблема, только права были неправильными на / TMP. СПАСИБО!!

— Невин

6

Другая возможная причина - совместное использование соединения: возможно, кто-то уже вошел в систему на другом хосте без включения переадресации агента и совместного использования соединения. Второй вход в систему ssh -A(или эквивалентно указанный в файле конфигурации) через общее соединение будет молча игнорировать -Aфлаг. Переадресация агента будет работать только после полного выхода из системы или отключения общего доступа к подключению для второго входа в систему.

— W.Mann
источник

2

В интересах других гуглеров, которые также пришли к этому вопросу:

Неправильный пробел в файле ~ / .ssh / config также может вызвать царапины на голове.

Я недавно выручил одного из моих коллег, у которого было это:

# incorrect
host foobar ForwardAgent yes

вместо этого:

# correct
host foobar
  ForwardAgent yes

Я также сталкивался с случаями, когда отсутствующие отступы в директивах в списке хостов оказывали влияние на функциональность, хотя это и не предполагалось.

— Дейл Андерсон
источник

0

Добавьте следующие строки в файл .ssh / config

  Host **Server_Address**
     ForwardAgent yes

Добавить ключ к агенту SSH

 ssh-add -K

Подключиться к удаленному серверу

ssh -v **username**@**Server_Address**

Запустите проверку соединения с GitHub

ssh -T git@github.com

Запустите удаленный тест ls для целевого git-репозитория

git ls-remote --heads git@github.com:**account**/**repo**.git

— Тахсин Туркоз
источник