На моем собственном компьютере под управлением 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:
Оказалось, что моего ключа не было в агенте, и это исправило его:
OS X:
ssh-add -K
Linux / Unix:
ssh-add -k
Вы можете просмотреть загруженные ключи, используя:
ssh-add -l
ssh-add -L # for more detail
Проверьте, если ваш ./ssh/id_rsa .ssh/id_dsa .ssh/id_ecdsa файлы имеют правильные разрешения, которые должны принадлежать вашему пользователю и иметь chmoded 600.
Убедитесь, что у вас есть правильный открытый ключ на pupeno/.ssh/authorized_keys на b1 и проверим, authorized_keys имеет разрыв строки в конце ключа.
Проверьте, запущен ли у вас ssh-agent, попробуйте загрузить ключи через ssh-add
Попробуйте аутентификацию и пересылку на основе GSSAPI с ssh -K
Другой возможной причиной является совместное использование соединения: возможно, кто-то уже вошел в систему на другом хосте без включения пересылки агента и совместного использования соединения. Второй логин с ssh -A (или аналогично указанному в файле конфигурации) через общее соединение будет игнорировать -A флаг. Только после полного выхода из системы или отключения совместного использования соединения для второго входа в систему переадресация агента будет работать.
У меня была проблема с сервером sshd, отклоняющим запрос пересылки агента из-за отсутствия места в / tmp. Это произошло потому, что sshd необходимо создать сокет в / tmp. Очистка диска решила мою проблему.
ssh -v сказал тогда:
debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device
В интересах других гуглеров, которые также пришли к этому вопросу:
Неправильные пробелы в файле ~ / .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
Запустить удаленный тест ls для целевого репозитория git
git ls-remote --heads git@github.com:**account**/**repo**.git
Если вы подключаетесь к машине, Byobu/ tmux кажется, что иногда вам нужно создать новое окно на целевой машине (например, Ctrl-B + C) после подключения к ssh -A так что вы можете использовать свой ssh-агент для дальнейшей аутентификации.