SSH продовжує пропускати мій пабі і просити пароль


52

Кожен раз, коли я наштовхуюсь на віддалений сервер, мені потрібно вказати пароль. Я скопіював свій відкритий ключ (id_dsa.pub) на віддалений сервер, використовуючи:

ssh-copy-id -i id_dsa.pub user@server

Я перевірив, що правильно додано до санкціонованих_кілей. Усі дозволи файлу / каталогу правильні:

~user 755
~user/.ssh 700
~user/.ssh/authorized_keys 640
~user/.ssh/id_dsa.pub 644

Поле PasswordAuthentication в / etc / ssh / sshd_config встановлено так. Я перевів sshd в режим налагодження і додав до команди ssh команду перемикання. У мене складається враження, що сервер не намагався використовувати id_pub.dsa через лінію

Skipping ssh-dss key: ........... not in PubkeyAcceptedKeyTypes

На стороні сервера немає зашифрованого диска. Будь-які ідеї, як прогресувати? Ось інформація про налагодження в ssh daemon:

sudo /usr/sbin/sshd -d
====
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx port 63521 on yyy port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user damian service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "damian"
debug1: PAM: setting PAM_RHOST to "freebox-server.local"
debug1: PAM: setting PAM_TTY to "ssh"
Connection closed by xxxx [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup

Ось багатослівний висновок ssh:

$ ssh -v user@server
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Connecting to server [xxxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to server:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:v4BNHM0Q33Uh6U4VHenA9iJ0wEyi8h0rFVetbcXBKqA
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
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/user/.ssh/id_rsa
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@server's password:

1
Дивіться також superuser.com/q/1016989/93541 щодо тієї ж проблеми (і по суті того ж рішення).
DW

Зауважте, що якщо sshd_config у пункті призначення має PubkeyAuthentication ні , вам завжди буде запропоновано ввести пароль. Встановіть його так і перезавантажте sshd (на хості призначення), щоб увімкнути автентифікацію порту.
C. Келлі

Відповіді:


84

У новій відкритій версії (7.0+) застарілі клавіші DSA і не використовують клавіші DSA за замовчуванням (не на сервері чи клієнті). Ключі більше не вважають за краще використовувати, тому, якщо можете, я рекомендую використовувати ключі RSA, де це можливо.

Якщо вам дійсно потрібно використовувати ключі DSA, вам потрібно чітко дозволити їх у налаштуваннях вашого клієнта за допомогою

PubkeyAcceptedKeyTypes +ssh-dss

Має бути достатньо, щоб поставити цей рядок ~/.ssh/config, як багатослівне повідомлення намагається сказати вам.


5
+1, але кращою порадою було б скористатися іншим,
незастареним

@jasonwryan Дякую за коментар. Звичайно. Я оновлю відповідь.
Jakuje

Дякую Якує! Це має сенс, я не розумів, що ДСА був старим. Я створив нову пару ключів ssh-keygenrsa - це типовий параметр. Я спробую увійти в цю програму з іншої машини завтра.
Дамо

Якщо вас ~/.ssh/configнемає, просто створіть його. І пам'ятайте , щоб встановити Corect дозволу: chmod 600 ~/.ssh/config.
Флоріан Брюкер

@knb цього не роби. Це дозволить уникнути використання інших алгоритмів у майбутньому, оскільки ви видалили всі алгоритми еліптичної кривої.
Jakuje

2

У моєму випадку у мене виникло це питання, оскільки інший користувач змінив AuthorizedKeysFileмісцеположення. Оскільки authorized_keysінших користувачів у цьому місці не було, для входу в систему за замовчуванням вводиться пароль, хоча вони authorized_keysіснували з правильними дозволами в домашньому каталозі за замовчуванням.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Прокоментував цю змінену лінію і перезапустив службу sshd, щоб повернутися до налаштувань за замовчуванням, що дозволило іншим користувачам пройти автентифікацію за допомогою своїх ключів.


Я щойно вирішив подібну проблему в системі RHEL7, де контекст SELinux не був ініціалізований належним чином на homedir користувача, тому ssh не зміг прочитати файл авторизованих ключів, незважаючи на стандартні дозволи. Я врешті-решт закінчився, restorecon -Rv /homeщоб виправити це для інших користувачів, які також були неправильно налаштовані в тій же системі.
dannysauer

1

Я спробував відповідь Джакує Не пощастило. Але я розумію проблему звідти. Спробував додати коментар, але потрібна репутація, чому для цього додавати відгук.

Але файл конфігурації для мене / etc / ssh / ssh_config

  1. sudo nano /etc/ssh/ssh_config
  2. PubkeyAcceptedKeyTypes +ssh-dss Додано цей рядок внизу.
  3. Збережіть і спробуйте знову.

Працювали!


1

Просто підсумувати те, що я зробив для того, щоб SSH малини пі .

У серверній машині (малиновий Pi):

$ ip addr show 

або просто ip a, це відобразить IP-адресу машини Pi - host_ip

$ mkdir .ssh

На клієнтській машині (ubuntu):

$ ssh-keygen -t rsa  

Заслуга @Jakuje вище. Спочатку я використовував ssh-keygen -t dsa для генерації ключів, і ssh постійно запитував мене про пароль. ssh -v ip-адреса не дає мені багато корисної інформації, поки я не побачив відповідь @ Jakuje

$ cat .ssh/id_rsa.pub | ssh user_id@host_ip 'cat >> ~/.ssh/authorized_keys'  

при запрошенні замініть user_id та host_ip, вкажіть пароль для машини Pi

$ ssh user@ip_address

успішно увійшов у PI, більше не було пароля


0

dsa не працював для мене. rsa зробив.

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat /Users/user_name/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

І я можу ssh без пароля.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.