Вопросы Теги

SSH не соединяются даже с установленными открытыми ключами

Я пытаюсь подключить два сервера. Я получил id_dsa.pub ключ от пользователя john с сервера A и вставка в authorized_keys пользовательского микрофона с сервера B.

Затем я пытался соединить с сервера к серверу B использование входа в систему микрофона, однако это все еще просит пароль.

В .ssh/каталоге микрофона я имею только authorized_keys файл, как это:

bash-3.00$ ls -l
total 16
-rw-------   1 mike users    2422 Oct  8 14:47 authorized_keys
bash-3.00$

Администраторский парень с сервера B гарантировал, что, имея только этот файл достаточно позволить нам соединиться в сервере B.

Я пропускаю что-то?

Спасибо, ребята!

Править: Вот Журнал:

johndbb3:/home/john/.ssh> ssh -vvv mike@fpnld1.uk.db.com
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to fpnld1.uk.db.com [10.240.1.215] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type -1
debug3: Not a RSA1 key file /home/john/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/john/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /home/john/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/john/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: no match: Sun_SSH_1.1.3
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: ar-EG,ar-SA,bg-BG,ca-ES,cs-CZ,da-DK,de,de-AT,de-CH,de-DE,de-LU,el-CY,el-GR,en-AU,en-CA,en-GB,en-IE,en-MT,en-NZ,en-US,es,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-ES,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et-EE,fi-FI,fr,fr-BE,fr-CA,fr-CH,fr-FR,fr-LU,he-IL,hr-HR,hu-HU,is-IS,it,it-IT,kk-KZ,lt-LT,lv-LV,mk-MK,mt-MT,nb-NO,nl-BE,nl-NL,nn-NO,pl,pl-PL,pt-BR,pt-PT,ro-RO,ru,ru-RU,sh-BA,sk-SK,sl-SI,sq-AL,sr-CS,sv,sv-SE,tr-TR,ar,ca,cz,da,el,et,fi,he,hu,lt,lv,nl,no,no-NO,no-NY,nr,pt,sr-SP,sr-YU,tr,i-default,uk-UA
debug2: kex_parse_kexinit: ar-EG,ar-SA,bg-BG,ca-ES,cs-CZ,da-DK,de,de-AT,de-CH,de-DE,de-LU,el-CY,el-GR,en-AU,en-CA,en-GB,en-IE,en-MT,en-NZ,en-US,es,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-ES,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et-EE,fi-FI,fr,fr-BE,fr-CA,fr-CH,fr-FR,fr-LU,he-IL,hr-HR,hu-HU,is-IS,it,it-IT,kk-KZ,lt-LT,lv-LV,mk-MK,mt-MT,nb-NO,nl-BE,nl-NL,nn-NO,pl,pl-PL,pt-BR,pt-PT,ro-RO,ru,ru-RU,sh-BA,sk-SK,sl-SI,sq-AL,sr-CS,sv,sv-SE,tr-TR,ar,ca,cz,da,el,et,fi,he,hu,lt,lv,nl,no,no-NO,no-NY,nr,pt,sr-SP,sr-YU,tr,i-default,uk-UA
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: Peer sent proposed langtags, ctos: ar-EG,ar-SA,bg-BG,ca-ES,cs-CZ,da-DK,de,de-AT,de-CH,de-DE,de-LU,el-CY,el-GR,en-AU,en-CA,en-GB,en-IE,en-MT,en-NZ,en-US,es,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-ES,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et-EE,fi-FI,fr,fr-BE,fr-CA,fr-CH,fr-FR,fr-LU,he-IL,hr-HR,hu-HU,is-IS,it,it-IT,kk-KZ,lt-LT,lv-LV,mk-MK,mt-MT,nb-NO,nl-BE,nl-NL,nn-NO,pl,pl-PL,pt-BR,pt-PT,ro-RO,ru,ru-RU,sh-BA,sk-SK,sl-SI,sq-AL,sr-CS,sv,sv-SE,tr-TR,ar,ca,cz,da,el,et,fi,he,hu,lt,lv,nl,no,no-NO,no-NY,nr,pt,sr-SP,sr-YU,tr,i-default,uk-UA
debug1: Peer sent proposed langtags, stoc: ar-EG,ar-SA,bg-BG,ca-ES,cs-CZ,da-DK,de,de-AT,de-CH,de-DE,de-LU,el-CY,el-GR,en-AU,en-CA,en-GB,en-IE,en-MT,en-NZ,en-US,es,es-AR,es-BO,es-CL,es-CO,es-CR,es-EC,es-ES,es-GT,es-MX,es-NI,es-PA,es-PE,es-PY,es-SV,es-UY,es-VE,et-EE,fi-FI,fr,fr-BE,fr-CA,fr-CH,fr-FR,fr-LU,he-IL,hr-HR,hu-HU,is-IS,it,it-IT,kk-KZ,lt-LT,lv-LV,mk-MK,mt-MT,nb-NO,nl-BE,nl-NL,nn-NO,pl,pl-PL,pt-BR,pt-PT,ro-RO,ru,ru-RU,sh-BA,sk-SK,sl-SI,sq-AL,sr-CS,sv,sv-SE,tr-TR,ar,ca,cz,da,el,et,fi,he,hu,lt,lv,nl,no,no-NO,no-NY,nr,pt,sr-SP,sr-YU,tr,i-default,uk-UA
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: Negotiated lang: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: Remote: Negotiated main locale: C
debug1: Remote: Negotiated messages locale: C
debug1: dh_gen_key: priv key bits set: 129/256
debug1: bits set: 1594/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/john/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 120
debug3: check_host_in_hostfile: filename /home/john/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 119
debug1: Host 'fpnld1.uk.db.com' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:120
debug1: bits set: 1573/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug3: start over, passed a different list gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/john/.ssh/identity
debug3: no such identity: /home/john/.ssh/identity
debug1: Trying public key: /home/john/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Trying public key: /home/john/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

johndbb3:/home/john/.ssh>
2
07.11.2010, 23:22
4 ответа

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

  1. На Сервере B (как микрофон): rm ~/.ssh/authorized_keys
  2. На Сервере (как Джон): ssh-copy-id -i /path/to/id_dsa.pub mike@serverb

Команда ssh-copy-id в основном соединяется с удаленным хостом (использующий автора пароля) и затем редактирует authorized_keys соответственно. Я полагаю, что это распределяется с OpenSSH при использовании чего-то еще это не может быть доступно.

3
27.01.2020, 22:01
  • 1
    я вводил это и затем должен был пойти, делает что-то и отправил его, когда я возвратился. Тем временем Вы обновили свое сообщение с журналом. Этот ответ не принимает журнал во внимание и не может применяться. –  Steven D 08.10.2010, 21:49
  • 2
    я выполняю Солярис, он не имеет ssh-copy-id управляйте... –  jyz 08.10.2010, 21:50
  • 3
    @jyzuz: Вы проверяли копирование ключей правильно? Выдержать сравнение md5sum id_dsa.pub клиентский и md5sum authorized_keys серверная сторона (использование cksum если Вы не имеете md5sum с обеих сторон). –  Gilles 'SO- stop being evil' 09.10.2010, 00:54

У Вас есть доступ к входу в систему SSH ServerB? В противном случае администратор может отправить соответствующие строки Вам?

На ServerB полномочия для удостоверяются, что у Вас есть корректные полномочия, как описано в странице справочника SSH:

 ~/.ssh/
         This directory is the default location for all user-specific con‐
         figuration and authentication information.  There is no general
         requirement to keep the entire contents of this directory secret,
         but the recommended permissions are read/write/execute for the
         user, and not accessible by others.

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described in the
         sshd(8) manual page.  This file is not highly sensitive, but the
         recommended permissions are read/write for the user, and not
         accessible by others.
2
27.01.2020, 22:01
  • 1
    , у меня временно есть доступ к обоим серверам (пока оба сервера не являются правильно установкой). Что я должен попробовать? Я уже проверил полномочия, и они корректны... –  jyz 08.10.2010, 21:59
  • 2
    Неудачные попытки SSH должны быть в системных журналах. Это должно дать Вам ошибку, которая объясняет, почему это отклонило сессию SSH. Сообщения об ошибках являются немного загадочными, но очень Googleable. Если Вы отправляете ошибки в своем вопросе выше, мы смогли помогать Вам. –  Stefan Lasiewski 08.10.2010, 23:55
  • 3
    я предлагаю две висячих строки. Один, делая 'хвост-f' SSH регистрируется в реальное время (/var/adm/auth Я думаю в системах Соляриса). В Вашем другом окне попытайтесь ssh -l mike serverb. Попробуйте некоторые изменения, как ssh serverb (как самостоятельно), и т.д. чтобы помочь диагностировать. –  Stefan Lasiewski 08.10.2010, 23:58
  • 4
    Я должен использовать authorized_keys или authorized_keys2? О журналах у меня нет корневого доступа к серверу, я проверю, смогу ли я считать этот журнал. Возвратится позже.Спасибо. –  jyz 09.10.2010, 15:39
  • 5
    @jyzuz: По умолчанию или authorized_keys или authorized_keys2 должны работать. –  Stefan Lasiewski 09.10.2010, 23:37

Существует по крайней мере два различных формата для открытых ключей SSH, которые я знаю как формат OpenSSH и формат PuTTY. Так как я вижу жалобы на "-----НАЧНИТЕ" в Вашем журнале, я подозреваю, что Ваш сервер ожидает OpenSSH-стиль, но Вы дали ему ключ стиля ШПАКЛЕВКИ.

Формат OpenSSH помещает весь ключ плюс комментарий к единственной текстовой строке и похож (для ключа DSA):

ssh-dss <ASCII-ENCODED-KEY-MATERIAL> my-comment-for-human-convenience

(Замените "ssh-dss" "ssh-rsa" для ключа RSA.)

Стиль PuTTY является более подробным, но содержит ту же информацию. Это похоже:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "my-comment-for-human-convenience"
<ASCII-ENCODED-KEY-MATERIAL, split into...>
<...multiple lines of 64 characters each>
---- END SSH2 PUBLIC KEY ----

Можно использовать PuTTYgen для преобразования между этими двумя форматами (stackoverflow вопрос). Или если Вы осторожны, и Вы знаете, является ли Ваш ключ стиля ШПАКЛЕВКИ RSA или DSA, можно вручную преобразовать один в другой путем удаления разрывов строки в ключевом материале и добавления тега "ssh-dss" или "ssh-rsa".

0
27.01.2020, 22:01

На клиенте введите:

ssh-keygen-t rsa-b 4096

войдите ВХОДЯТ при запросе пароль.

перейдите к ~/.ssh и скопируйте id_rsa.pub в сервер. кошка id_rsa.pub>>/home/username/.ssh/authorized_keys

Также на сервере редактируют/etc/ssh/sshd_config файл для разрешения основанной на ключе аутентификации

и выполненный перезапуск/etc/init.d/sshd

затем на клиентской машине войдите: ssh usernameOfTheUserOnTheServerWhereYouCopiedTheKeyToAuthorizedKeys@192.168.1.x

-1
27.01.2020, 22:01
  • 1
    у меня есть id_rsa.pub и id_dsa.pub. Разве DSA не более силен, чем RSA? На самом деле к другим серверам мы всегда отправляли ключ паба DSA, и он всегда работал. Я не могу повторно создать ключи (так как много других серверов соединяется с нами), но я попытаюсь выполнить (снова) шаги.Спасибо. –  jyz 09.10.2010, 15:37

Теги

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