SSH: "нет такой идентичности"

Question

У меня очень специфическая проблема с тем, чтобы заставить SSH работать на моем Linux-компьютере. У меня есть пароль пользователя git, идентифицированный ключом OpenSSH. Если я пытаюсь подключиться к нему по ssh с той же или с другой виртуальной машины Linux в сети, это не удастся (полная информация об отладке приведена ниже).

Но теперь, вот странная часть: я могу просто выполнить ssh из своей коробки Windows 7, используя те же самые ключи! Это говорит мне о том, что мы можем рассматривать проблему на стороне клиента. Если ключи на сервере каким-то образом были повреждены, я не смог бы соединиться откуда угодно.

Я уже несколько дней шлифую свои колеса в грязи. Есть масса тем по этому вопросу, но ни одно из решений не работает и не применяется.

Общие решения, которые я уже пробовал:

Разрешения ~/.ssh были правильно установлены как на клиенте, так и на сервере.

В частности, ~/.ssh/* было установлено равным 600 (один поток рекомендовал изменить значение author_keys (server) на 644, но это не имело никакого эффекта).

Сам каталог ~/.ssh был установлен на 700.

Все в ~ принадлежит одноименному пользователю /группе.

Клиент (/home/kris/.ssh):

drwx------  2 kris kris 4096 Apr 11 01:17 .
drwx------ 38 kris kris 4096 Apr 11 01:29 ..
-rw-------  1 kris kris  458 Apr 11 16:22 config
-rw-------  1 kris kris 1675 Apr 10 22:29 id_rsa_kriscraig_git
-rw-------  1 kris kris 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw-------  1 kris kris  400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw-------  1 kris kris 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw-------  1 kris kris  400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw-------  1 kris kris  951 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris
-rw-------  1 kris kris  214 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris.pub
-rw-------  1 kris kris  381 Apr 10 22:29 id_rsa_kriscraig_git.pub
-rw-------  1 kris kris 1626 Apr 11 17:50 known_hosts

Сервер (/home/git/.ssh; теперь он немного загроможден из-за всех проб /ошибок, которые я делал):

drwx------ 2 git git 4096 Apr 11 01:36 .
drwx------ 8 git git 4096 Apr  9 17:55 ..
-rw-r--r-- 1 git git 2174 Apr 11 01:40 authorized_keys
-rw------- 1 git git  904 Aug  4  2012 authorized_keys_bak
-rw------- 1 git git  354 Aug  4  2012 authorized_keys_bak2
-rw------- 1 git git 2174 Apr 11 01:13 authorized_keys_bak3
-rw------- 1 git git  160 Apr 10 00:32 config
-rw------- 1 git git 1675 Aug  3  2012 id_rsa
-rw------- 1 git git 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw------- 1 git git  400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw------- 1 git git 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw------- 1 git git  400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw------- 1 git git  951 Apr 10 00:32 id_rsa_kriscraig_gitolite_Kris
-rw------- 1 git git  214 Apr 10 00:33 id_rsa_kriscraig_gitolite_Kris.pub
-rw------- 1 git git  381 Aug  3  2012 id_rsa.pub
-rw------- 1 git git  414 Aug  4  2012 known_hosts

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

Я попытался скопировать /вставить те, которые уже работают в Windows, и даже зашел так далеко, что использовал dos2unix, чтобы убедиться, что мы не имеем дело с какими-либо проблемами кодирования (CRLF /LF и т.д.).

Я сгенерировал ключи, используя стандартный подход:
```
ssh-keygen -t rsa
```
Я пытался поиграться с разрешениями родительских домашних каталогов безрезультатно.
Я возился с локальными конфигами, а также с /etc /ssh /* _ config

И да, я перезапускал sshd каждый раз. Я даже на случайный интервал перезагружал сервер, на всякий случай.
Я уверен, что мне не хватает нескольких вещей. Я не спал много в последнее время ....

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

Основная информация о клиенте / сервере

сервер

CentOS 5.9 64-битный (VirtualBox)
4 ГБ ОЗУ
200 ГБ HDD (динамическое распределение)
4 процессора
Мостовая сеть (все они подключаются к одному маршрутизатору)
Тесты: N/A

Linux Client # 1

CentOS 5.9 64-битный (VirtualBox)
1 ГБ ОЗУ
15 ГБ HDD (динамическое распределение)
1 процессор
Мостовая сеть
Тесты: FAIL

Клиент Linux # 2

Сам сервер. Казалось, хороший способ исключить несколько возможностей.
Тесты: FAIL

Клиент Windows

64-разрядная версия Windows 7 Ultimate (хост для VirtualBox)
32 ГБ ОЗУ
200 ГБ HDD
731 ГБ HDD
232 ГБ HDD
465 ГБ HDD
2,72 ТБ HDD
16 CPU
Тесты: УСПЕХ

Отладочная информация (конфиденциальные данные отредактированы)

сервер

Результирующие записи для двух неудачных попыток ssh в /var /log /secure:

    Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14738]: Connection from (WAN IP) port 35326
    Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14739]: Connection closed by (WAN IP)
    Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14741]: Connection from (WAN IP) port 35328
    Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14742]: Connection closed by (WAN IP)

Клиенты Linux (по сути, одинаковые для обоих)

    [kris@CRAIGCOM-LINUX .ssh]$ ssh git@CRAIGCOM-LINUX -vvv
    OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
    debug1: Reading configuration data /home/kris/.ssh/config
    debug1: Applying options for CRAIGCOM-LINUX
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to (SERVER HOST) [(SERVER IP)] port 22.
    debug1: Connection established.
    debug1: identity file "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" type -1
    debug1: loaded 1 keys
    debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
    debug1: match: OpenSSH_4.3 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.3
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: first_kex_follows 0 
    debug2: kex_parse_kexinit: reserved 0 
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: first_kex_follows 0 
    debug2: kex_parse_kexinit: reserved 0 
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 118/256
    debug2: bits set: 484/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug1: Host '(SERVER HOST)' is known and matches the RSA host key.
    debug1: Found key in /home/kris/.ssh/known_hosts:1
    debug2: bits set: 522/1024
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" ((nil))
    debug1: Authentications that can continue: publickey,gssapi-with-mic,password
    debug3: start over, passed a different list publickey,gssapi-with-mic,password
    debug3: preferred publickey
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: 
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
    debug3: no such identity: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
    debug2: we did not send a packet, disable method
    debug1: No more authentication methods to try.
    Permission denied (publickey,gssapi-with-mic,password).

Вот где я застрял

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

Насколько я могу судить, я не могу понять, почему это мешает файлам ключей на обеих коробках CentOS! Полномочия установлены отлично, файлы доступны для чтения, ни один сервер не использует SELinux, те же ключи отлично работают на клиенте Windows и т.д.

Я хорошо ношу шляпу сисадмина; но в конце концов, я разработчик, а не ИТ-специалист. Этот уровень отладки SSH вывел меня за пределы моей компетенции. Ненавижу это говорить, но у меня просто кончились идеи. Согласно каждой вещи, которую я смог найти в интернете, это должно работать. Но это не так. Что мне не хватает?

Спасибо за вашу помощь! Надеюсь, один из вас поймет эту проблему и загрузит мою задницу в правильном направлении. Если вам нужна дополнительная информация, пожалуйста, не стесняйтесь спрашивать.

--Kris

score 2 · Answer 1 · 2011-03-09T19:38:42

Пожалуйста, используйте ssh-agent.

Сначала добавьте ваш ключ к агенту: ssh-add ~/.ssh/$keyfile .
Затем убедитесь, что ключ успешно загружен: ssh-add -l
Затем попробуйте подключиться к ssh. (Агент должен выполнить аутентификацию.)

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

Сейчас выбран русский

SSH: "нет такой идентичности"

Общие решения, которые я уже пробовал:

Основная информация о клиенте / сервере

сервер

Linux Client # 1

Клиент Linux # 2

Клиент Windows

Отладочная информация (конфиденциальные данные отредактированы)

сервер

Клиенты Linux (по сути, одинаковые для обоих)

Вот где я застрял

1 ответ1

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux git ssh centos openssh.

SSH: "нет такой идентичности"

Общие решения, которые я уже пробовал:

Основная информация о клиенте / сервере

сервер

Linux Client # 1

Клиент Linux # 2

Клиент Windows

Отладочная информация (конфиденциальные данные отредактированы)

сервер

Клиенты Linux (по сути, одинаковые для обоих)

Вот где я застрял

1 ответ1

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux git ssh centos openssh.

Похожие