SSH не принимает открытый ключ

31746
Zurahn

При настройке ключей SSH между двумя компьютерами аутентификация работает только в одном направлении. Один сервер не принимает открытый ключ другого при попытке подключения. Есть идеи? Вот подробный вывод.

debug1: Reading configuration data /usr/local/etc/ssh_config  debug1: Rhosts Authentication disabled, originating port will not be trusted.  debug1: Connecting to xxxxxx.com [xx.xx.xx.xx] port 22.  debug1: Connection established.  debug1: identity file /root/.ssh/identity type -1  debug1: identity file /root/.ssh/id_rsa type 1  debug1: identity file /root/.ssh/id_dsa type -1  debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5  debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*  debug1: Enabling compatibility mode for protocol 2.0  debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2  debug1: SSH2_MSG_KEXINIT sent  debug1: SSH2_MSG_KEXINIT received  debug1: kex: server->client aes128-cbc hmac-md5 none  debug1: kex: client->server aes128-cbc hmac-md5 none  debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent  debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP  debug1: SSH2_MSG_KEX_DH_GEX_INIT sent  debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY  debug1: Host 'xxxxxx.com' is known and matches the RSA host key.  debug1: Found key in /root/.ssh/known_hosts:17  debug1: ssh_rsa_verify: signature correct  debug1: SSH2_MSG_NEWKEYS sent  debug1: expecting SSH2_MSG_NEWKEYS  debug1: SSH2_MSG_NEWKEYS received  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: /root/.ssh/identity  debug1: Offering public key: /root/.ssh/id_rsa  debug1: Authentications that can continue: publickey,password  debug1: Trying private key: /root/.ssh/id_dsa  debug1: Next authentication method: password

РЕДАКТИРОВАТЬ: Если это имеет значение, это дляroot

4
Я предполагаю, что root-логины разрешены в вашем sshd_config? heavyd 14 лет назад 0
Это проблема, характерная для этого сервера? Вы успешно настроили авторизацию по ssh-ключу раньше? Doug Harris 14 лет назад 0
Есть другие аккаунты, аутентифицирующиеся таким образом, просто отлично, но не root Zurahn 14 лет назад 0
Я закончил тем, что использовал другой аккаунт, который работал и работал. Хорошо, не так элегантно, но я потратил достаточно времени на это. Zurahn 14 лет назад 0

5 ответов на вопрос

8
Pada

I've just had a case where SELinux prevented sshd from reading the /root/.ssh/authorized_keys file. /var/log/messages will show you that the sshd process was denied access for read operation on the authorized_keys file.

After I ran restorecon -v /root/.ssh/authorized_keys, SSH with the public-key worked fine.

Мои журналы ничего не показывали об отказе в доступе, но я все равно выполнил эту команду. И что вы знаете, это сработало. Спасибо! Kaivosukeltaja 11 лет назад 0
5
derunbekanntschatten

Changing StrictModes to "no" in /etc/ssh/sshd_config worked for me.

sysadmin@suselinux1:~> con sysadmin kaiser Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-25-generic i686) * Documentation: https://help.ubuntu.com/ Last login: Fri Nov 9 15:40:11 2012 from 10.1.3.25 sysadmin@kaiser:~$ date vie nov 9 17:53:11 CST 2012 sysadmin@kaiser:~$
Вместо того, чтобы отключать `StrictModes`, вы можете вместо этого исправить права доступа к файлам в` .ssh` (и в самой директории `.ssh`). Flimm 9 лет назад 0
1
radius

Проверьте значения следующих параметров на сервере ssh:

PubkeyAuthentication Yes RSAAuthentication Yes PermitRootLogin Yes
RSAAuthentication да PubkeyAuthentication да Zurahn 14 лет назад 0
Проверьте, не установлено ли для PermitRootLogin значение no, если для него установлено значение no, установите для него значение nopwd. radius 14 лет назад 0
Было установлено «да», и я изменил его на «без пароля» и перезапустил ssh без какого-либо эффекта - он все еще запрашивал пароль. Это, друг мой, это решимость. Zurahn 14 лет назад 1
@radius нет ни одного nopwd. И установка его без пароля только делает его немного более безопасным, в котором им все еще нужен ключ. И так или иначе ключи в первую очередь приходят в любом случае. Если он не может войти с ключом, он все равно не сможет войти с ключом. Я не знаю, возможно, он не скопировал свой открытый ключ, или, возможно, он не входил в систему как подходящий пользователь на сервере ssh. barlop 12 лет назад 0
1
pfrenssen

Мой ключ не переадресовывался, оказалось, что я запустил агент SSH в другом окне терминала, поэтому $SSH_AUTH_SOCKпеременная среды не была доступна в терминале, в котором я устанавливал соединение.

Поэтому, если вы запускаете агент вручную, убедитесь, что вы установили соединение в том же терминальном сеансе.

0
Andy Zhang

Проверьте разрешение и владельца папки .ssh, файла author_key и домашней папки, /var/log/auth.log выдаст вам больше сообщений при попытке входа в систему.

`/ var / log / auth.log` на сервере, а не на клиенте (в случае, если кто-то предполагает последнее). Daniel Beck 12 лет назад 1

Похожие вопросы