Я пытаюсь ssh две машины, и я предпочел бы использовать ключи, сгенерированные для аутентификации, а не пароль. Это позволит мне автоматизировать переадресацию портов и многое другое.

Примечание. Мой сервер - debian.

Ниже то, что я сделал.

  1. Я сгенерировал ключ:

    ssh-keygen -t dsa

  2. Скопировал id_dsa.pub в ~/.ssh удаленного сервера

  3. ssh-add -D для удаления старых ключей. Думаю, они мне не нужны

  4. ssh-add ~/.ssh/id_dsa для добавления приватного идентификатора 5. попытался подключиться к внешнему серверу как

    ssh root @ remote-ip

  5. Все еще согласился на пароль, даже после того, как мое согласие было добавлено на известных хостах.
  6. Попробовал ssh -vvv root @ remote-ip и получение логов выложено ниже.
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 184.154.191.58 [184.154.191.58] port 18765.
debug1: Connection established.
debug1: identity file /home/eclipse/.ssh/id_rsa type -1
debug1: identity file /home/eclipse/.ssh/id_rsa-cert type -1
debug1: identity file /home/eclipse/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/eclipse/.ssh/id_dsa-cert type -1
debug1: identity file /home/eclipse/.ssh/id_ecdsa type -1
debug1: identity file /home/eclipse/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [184.154.191.58]:18765
debug3: load_hostkeys: loading entries for host "[184.154.191.58]:18765" from file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,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
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: 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: 125/256
debug2: bits set: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 5d:ce:fb:75:de:6f:52:f9:ad:41:e3:92:9a:53:ee:f0
debug3: put_host_port: [184.154.191.58]:18765
debug3: put_host_port: [184.154.191.58]:18765
debug3: load_hostkeys: loading entries for host "[184.154.191.58]:18765" from file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "[184.154.191.58]:18765" from file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug1: Host '[184.154.191.58]:18765' is known and matches the RSA host key.
debug1: Found key in /home/eclipse/.ssh/known_hosts:3
debug2: bits set: 514/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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/eclipse/.ssh/id_rsa ((nil))
debug2: key: /home/eclipse/.ssh/id_dsa (0x21b20e18)
debug2: key: /home/eclipse/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: password,keyboard-interactive
debug3: start over, passed a different list password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
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:

Пожалуйста, помогите кому-нибудь.

|источник

4 ответа4

1

Я потратил слишком много времени на отладку ssh-аутентификации с открытым паролем без пароля, поэтому я хотел опубликовать некоторые предложения для других:

  • После публикации сообщения mgorven убедитесь, что права доступа к файлам установлены на удаленном хосте правильно. Это самая распространенная проблема в моем опыте.
    $ chown -R username:username ~/.ssh
    $ chmod -R 700 ~/.ssh

  • Запуск ssh с клиента с помощью «-v», «-vv» или «-vvv» дал мне много информации, но НИКОГДА не говорил мне, какая конфигурация на удаленной машине неправильная. Это, вероятно, не позволит злым h4x0rs получить слишком много информации или что-то в этом роде.

  • Если у вас есть физический (не ssh) доступ к удаленной машине, вы можете попробовать остановить службу sshd и вручную запустить sshd с флагом «-d», чтобы вывести отладочную информацию на консоль.

  • Настройка аутентификации без пароля для пользователя root является основной защитой. Нет-нет, но если вы все еще хотите это сделать, попробуйте сначала настроить пользователя без полномочий root. Тогда, если у вас возникнут проблемы с включением его для root, вы будете знать, что за настройку отвечает учетная запись root/sysadmin.

  • Проверьте, включен ли SELinux. Если это так, это может помешать. Особенно, если вы пытаетесь настроить пароль без пароля для учетной записи суперпользователя.

Надеюсь, это сэкономит людям время, затрачиваемое на устранение неполадок, которое ssh нанесло остальным.

|источник
1

Вы положили открытый ключ в неправильном месте. На сервере разрешенные ключи хранятся в файле ~/.ssh/authorized_keys, по одному ключу на строку. Сервер SSH игнорирует все остальные файлы в ~/.ssh .

(Вы можете использовать ssh-copy-id <server> для простой авторизации ключа.)

Во-вторых, вы действительно запускали sshd -D и sshd id_dsa? Команда ssh-add:

ssh-add -D
ssh-add ~/.ssh/id_dsa
|источник
0

OpenSSH очень хорошо разбирается в правах доступа к файлам. Убедитесь, что /root/.ssh и все, что в нем, принадлежит правильному пользователю и доступно только для чтения и записи для владельца.

chown -R root:root /root/.ssh
chmod -R u=rwX,g=,o= /root/.ssh

Если это по-прежнему не работает, вставьте содержимое /var/log/auth.log и, возможно, /var/log/syslog на сервер, пытаясь войти в систему.

|источник
0

пытаться 

ssh-copy-id [user@]hostname

Вам будет предложено один раз ввести пароль удаленного пользователя, введите его, и вы должны быть на удаленном сервере, выйти из системы и снова войти в ssh. Пароли не требуются.

* также, проверьте права доступа к файлам, как указано в других ответах.

Надеюсь, поможет

|источник

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