14

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

Конфиг в .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Разрешение на мои ключевые файлы:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Журнал подключений, который я не могу понять:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,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: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
|источник

13 ответов13

10

Это обычно решает большинство проблем с разрешениями авторизованного ключа SSH на стороне сервера, при условии, что кто-то не внес дополнительных изменений в разрешения.

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Если ваш администратор создал каталог .ssh/ или файл .ssh/ authorized_keys в качестве пользователя root (как это чаще всего делается), то файл будет принадлежать другому пользователю (даже если пользователь root!) не допускается

Userify (заявление об отказе: соучредитель) автоматически делает это точно так же. https://github.com/userify/shim/blob/master/shim.py#L285

|источник
8

У меня была точно такая же проблема на двух серверах: в Linux, работающем под управлением Debian Stretch, и на NAS (Synology DS715)

оказалось, что в обоих случаях разрешения домашнего каталога на сервере были неправильными

auth.log на сервере был очень полезным

Authentication refused: bad ownership or modes for directory /home/cyril

в Linux он имел бит записи / группы (drwxrwxr - x), поэтому мне пришлось удалить хотя бы группу записи (chmod gw ~ /), и тогда это сработало

на Synology, по какой-то причине, было немного

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Я должен был изменить это с

chmod -t ~/

и я мог бы тогда подключиться без пароля

|источник
3

Похоже, что разрешения для вашей папки .ssh не были правильно скопированы + вставлены. Не могли бы вы добавить это снова?

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

  • .ssh/ должен иметь Пермь 0700/rwx------
  • Файлы .ssh/*.pub должны быть 644/rw-r--r--
  • .ssh/* (другие файлы в формате .ssh) 0600/rw-------

Как все выглядит для вас с разрешения?

|источник
2

На всякий случай, если кто-то наткнется на этот ответ - ни одна из рекомендаций не сработала в моем сценарии. В конце концов, проблема заключалась в том, что я создал учетную запись без пароля. После того, как я установил пароль, используя usermod -p "my password" username а затем принудительно разблокировал учетную запись usermod -U username все было замечательно.

|источник
2

Когда я использую CentOS 7, я уверен, что он применим и к другим ОС Linux, использующим sshd. С корневым доступом вы можете узнать больше о том, почему аутентификация может быть неудачной. Сделать это:

  1. Включите ведение журнала для sshd: vi /etc/ssh/sshd_config
  2. При ведении журнала раскомментируйте:

SyslogFacility AUTH LogLevel INFO

  1. Измените LogLevel INFO на LogLevel DEBUG
  2. Сохранить и выйти
  3. Перезапустите sshd systemctl restart sshd
  4. Смотреть файл сообщений tail -l /var/log/messages
  5. Используя другой терминал, попытайтесь соединиться с ssh
  6. Попытка соединиться с ssh
  7. Проверьте журнал аутентификации для точной причины

Например, я испытывал некоторые из тех же проблем, что и упомянутые выше. 

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Используя эти шаги, я смог подтвердить, что проблема заключалась в разрешениях для файла authorized_keys. Установив chmod на 644 в файле авторизованных ключей моего пользователя, проблема была исправлена.

|источник
1

У меня была похожая проблема, когда ssh-соединение пробует ключ ~/.ssh/id_rsa прежде чем неожиданно остановиться:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

В моем случае это было связано со старым файлом открытого ключа, лежащим в каталоге .ssh :

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Перемещение / удаление id_rsa.pub из каталога .ssh решило проблему.

Из того, что я понимаю: когда на стороне клиента присутствует открытый ключ, SSH 1st проверяет закрытый ключ на его соответствие. Если это не удается, он не будет пытаться использовать закрытый ключ для удаленного подключения.

Я отправил электронное письмо в список рассылки openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.

|источник
1

Также столкнулся с этой проблемой. setroubleshoot не работает в моей среде, поэтому в /var /log /messages такой записи журнала не было. Отключение SELinux не было для меня вариантом, поэтому я сделал

restorecon -Rv ~/.ssh

После этого логин по ключу rsa работал нормально.

|источник
1

На всякий случай это тоже кого-то спасает. Я пытался скопировать ключ с моей машины Ubuntu 18.04 на 2 сервера CentOS 7. Я использовал ssh-copy-id для их передачи. Один работал, другой нет. Так что я прошел все отладки разрешений и ничего не нашел. Итак, наконец, я поднял файл /etc/ssh/sshd_config на обоих серверах и построчно прошел через них. Наконец я нашел это, вероятно, кое-что, что кто-то изменил задолго до того, как я приступил к работе.

Один читал:AuthorizedKeysFile .ssh/authorized_keys

И еще одно чтение:AuthorizedKeysFile ~/.ssh/authorized_keys , который находился на сервере, который не принимал мои ключи. Очевидно, что поиск между двумя файлами и замечание комментария, в котором говорится, что шаблоны поиска по умолчанию не включают в себя ведущий ~/ I удалил его и перезапустил sshd. Задача решена.

|источник
1

Мы столкнулись с этой проблемой. Права доступа и права доступа к файлам .ssh были правильными. В /var /log /messages мы нашли:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

Итак, решение для разработчика VM, где мы не заботимся о безопасности, это отключить selinux. Отредактируйте /etc /sysconfig /selinux и измените SELINUX = отключено и перезагрузите компьютер.

|источник
0

Журнал ошибок на стороне клиента заканчивается следующим образом:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@x.x.x.x's password:

может быть вызвано серверным (удаленным) ограничением входа в систему root, если файл конфигурации sshd содержит:

PermitRootLogin: no

Предложение JonCav включить ведение журнала было полезно при устранении такой проблемы. В то время как на стороне клиента отладки изрыгать был удивительно бесполезным, помещая следующее в файле sshd_config на Sshd сервера:

SyslogFacility AUTH
LogLevel DEBUG

закончил тем, что производил полезные сообщения журнала:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

В случае, когда происходит сбой только входа в систему root , и если ваша политика безопасности допускает использование только аутентификации на основе ключа для вашей учетной записи root, может помочь изменение файла sshd_config :

 PermitRootLogin without-password

Ваш пробег может отличаться, хотя это часто помогает, некоторые другие конфигурации могут все еще вмешиваться в соответствии с комментарием, найденным в некоторых файлах sshd_config :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

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

|источник
0

Я понимаю, почему безопасность может беспокоить людей. Я только что ssh won't use my key проблему с ключом . Я решил это, войдя в удаленный сервер и запустив

/usr/sbin/sshd -sDp 23456

а затем с моего рабочего стола, (пытается SSH к серверу)

ssh -vvvv server -p 23456

На сервере я получил Authentication refused: bad ownership or modes for directory /

Какой-то новый системный администратор испортил разрешение и права собственности, которые я исправил:

chmod 0755 / ; chown root:root /

(Я привык к тому, что мне нужен chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub но sshd, проверяющий / находящий root-права, является новым для меня.) Теперь я собираюсь проверить руткит, а затем все равно стереть и переустановить.

|источник
0

В моем случае проблемы были с неправильной оболочкой exec.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Изменен файл /etc /passwd для этого пользователя

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....
|источник
0

Причиной в моем случае была специально настроенная опция AuthorizedKeysFile в файле /etc/ssh/sshd_config . Для него был задан домашний каталог другого пользователя (/home/webmaster/.ssh/authorized_keys), поэтому пользователь, которому я пытался войти, не имел доступа к этому файлу / каталогу.

После его изменения и перезапуска ssh-сервера (service ssh restart) все пришло в норму. Я могу войти через свой закрытый ключ сейчас.

|источник

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