Чому пересилка агента 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:

Виявляється, мій ключ був не в агенті, і це виправлено:

ОС X :

ssh-add -K

Linux / Unix :

ssh-add -k

Ви можете перерахувати завантажені ключі, використовуючи:

ssh-add -l

ssh-add -L # for more detail

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

2. Перевірте, чи увімкнено правильний відкритий ключ на pupeno/.ssh/authorized_keysb1, і перевірте, чи authorized_keysє розрив рядка в кінці ключа.

3. Перевірте, чи працює у вас ssh-агент, спробуйте завантажити ключі через ssh-add

4. Спробуйте аутентифікацію та переадресацію на основі GSSAPI ssh -K

У мене виникли проблеми із запитом переадресації агента sshd, оскільки в / tmp не залишилось місця. Це було тому, що sshd потрібно створити сокет в / tmp. Чищення диска вирішило мою проблему.

ssh -v сказав тоді:

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

Інша можлива причина - це спільний доступ до з'єднання: один з них може вже увійти в систему на другому хості, без переадресації агента та спільного доступу. Другий логін з ssh -A(або еквівалентно вказаний у конфігураційному файлі) через спільне з'єднання мовчки ігнорує -Aпрапор. Лише після повного виходу з системи або відключення спільного доступу для другого входу переадресація агента запрацює.

На користь інших гуглерів, які також дійшли цього питання:

Неправильне пробіл у файлі ~ / .ssh / config також може спричинити подряпини в голові.

Нещодавно я допоміг одному зі своїх колег, у якого це було:

# incorrect
host foobar ForwardAgent yes

замість цього:

# correct
host foobar
  ForwardAgent yes

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

Додайте наступні рядки до .ssh / config файла

  Host **Server_Address**
     ForwardAgent yes

Додати ключ до агента SSH

 ssh-add -K

Підключення до віддаленого сервера

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

Запустіть тест на зв’язок проти GitHub

ssh -T git@github.com

Запустіть віддалений тест на цільове сховище git

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