Вопрос: Почему пересылка агента ssh не работает?


На моем собственном компьютере, работающем под 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:

45
2017-07-03 16:32


Источник




Ответы:


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

OS X:

ssh-add -K

Linux / Unix:

ssh-add -k

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

ssh-add -l

73
2017-07-03 16:48



Обратите внимание, что ssh-add -K специфичен для OS X. - Roger Lipscombe


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

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

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

5
2018-05-22 11:02



У меня была такая же проблема, только разрешения были неправильными в / tmp. БЛАГОДАРЯ!! - nevyn


  1. Проверьте, ./ssh/id_rsa .ssh/id_dsa  .ssh/id_ecdsa файлы имеют правильные разрешения, которые должны принадлежать вашему пользователю и должны быть chmoded 600.

  2. Убедитесь, что у вас есть правильный открытый ключ pupeno/.ssh/authorized_keys на b1 и проверить, если authorized_keys имеет разрыв строки в конце ключа.

  3. Проверьте, запущен ли ssh-agent, попробуйте загрузить ключи через ssh-add

  4. Попробуйте аутентификацию и пересылку на основе GSSAPI с помощью ssh -K


5
2017-07-03 16:41



Разрешение ключей в порядке, и ключ в authorized_keys прекрасен (в противном случае, я думаю, у меня возникнут проблемы с подключением на первом месте). - pupeno
Был ли запущен ssh-agent? Что происходит, когда вы делаете ssh-add, затем ssh -A pupeno @ b1, а затем ssh pupeno @ b1? - Daniel Prata Almeida
Почему бы вам не обновить ответ, чтобы упомянуть ssh-add -K, и я соглашусь вместо вас (поскольку информация была опубликована почти одновременно). - pupeno


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


3
2017-08-14 18:43





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

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

Недавно я помог одному из моих сотрудников, у которого было это:

# incorrect
host foobar ForwardAgent yes

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

# correct
host foobar
  ForwardAgent yes

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


1
2017-07-18 20:22





Добавьте следующие строки в файл .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

0
2017-08-17 01:39