Аутентификация SSH-Key не проходит

30

Я пытаюсь подключиться к серверу 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).

ssh sshd ssh-keys

— Тим
источник

С крышек похоже, что ключ отправлен, но ответа так и не получил. -Вы должны войти в систему как root, или вы входите в систему как Tim, а затем используете sudo? Иногда ssh вход в систему как root отключен. -Каковы разрешения самого каталога .ssh? -У вас есть правильный сервер? DNS разрешается правильно? -Вы можете сделать ключи снова, а затем использовать ssh-copy-id, чтобы вручную скопировать новый открытый ключ в файл авторизованные_ключи. На всякий случай ключ как-то испортился.

— Кайл Х

Спасибо за попытку помочь! разрешения для моей папки .ssh: drwx ------ 2 tim tim 4096 Okt 20 22:13 .ssh. Войдите в систему как root правильно - на самом деле он работал пару недель назад, прежде чем я переформатировал свой компьютер. Администратор говорит, что он добавил новые ключи правильно, но я действительно не знаю, как это могло быть моей ошибкой в этот момент

— Тим

Как упомянул @KyleH, пытались ли вы ssh tim@10.0.12.28в качестве журнала упомянуть Kerberos, что сервер CentOS может быть интегрирован в домен (AD, IPA, ...). Вы должны выяснить, какого пользователя вы должны использовать. Спросите администратора. Например, мы используем IPA, поэтому мы разрешаем пользователям подключаться к определенным серверам с помощью учетной записи домена IPA и пары ключей, и при необходимости они могут выполнять sudo. Нет root-доступа :)

— Зина

18

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

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

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

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

— Джеймисон Беккер
источник

Если бы это была проблема, клиент, во-первых, не пытался бы отправить ключ на сервер; журнал, приведенный в вопросе, явный, что он делает.

— Чарльз Даффи

Это исправляет проблему на стороне сервера. Вы правы, что на стороне клиента все в порядке.

— Джеймисон Беккер,

1

Это наконец решило мою проблему. Потратил часы, пытаясь выяснить, почему мои открытые / закрытые ключи не были приняты.

— Дэниел Харрис

Другой пользователь предложил, sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Rчто сэкономит время при наборе текста, но новичку будет труднее понять

— Jamieson Becker

11

У меня была точно такая же проблема на двух серверах: в 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 ~/

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

— Кирилл Шабойсо
источник

Спасибо за это chmod -t... Я закончил с:

admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users  401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users  396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users  396 Jan 10 10:04 .ssh/known_hosts

— Стефан

6

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

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

SyslogFacility AUTH LogLevel INFO

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

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

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

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

— JonCav
источник

4

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

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

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

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

— Кайл Х
источник

Разрешения для моей домашней папки (tim) - 755 (drwxr-xr-x), а разрешения для самой папки .ssh - 700 (drwx). id_rsa - 600, а файл .pub - 644 ..: / еще раз спасибо, надеюсь, информация поможет

— Тим

У меня SSH работает на многих серверах. Мой домашний каталог - drwxr-xr-x (0755), .ssh - rwx ------ (0700), внутри .ssh - мой ключ паба -rw-r - r-- (0644), а остальные в этой папке -rw ------- (0600). Итак, ваши разрешения хороши, и он должен пройти проверку Строгого Хоста. Что находится в вашем файле / etc / ssh_config? Что-нибудь в ~ / .ssh / config? У меня было создание ключа SSH по той или иной причине не работает, хотя ошибок не было. Можете ли вы попробовать использовать ssh-keygen для регенерации ваших ключей, ssh-copy-id для копирования вашего ключа паба на удаленный сервер, на котором включена аутентификация по паролю?

— Кайл Х

К сожалению, у меня нет доступа к серверу, но я попытаюсь заставить администратора скопировать мой ключ pub на сервер снова в понедельник. Я скопировал содержимое файлов конфигурации в pastebin: pastebin.com/eEaVMcvt - еще раз спасибо за ваше Помогите!

— Тим

Пожалуйста. Я рад помочь! Мне также нравится решать проблемы и особенно помогать другим с Linux. В вашем ssh-config есть одна странная строка, которая может вызвать проблемы, где она находится. Что такое ip 10.0.12.28?

— Кайл Х

@KyleH прав .. это почти наверняка проблема. Я добавил еще один ответ, который показывает, как это исправить с правами root. Если вы управляете своим домашним каталогом, вы можете исправить это самостоятельно, но, конечно, вам нужно будет войти в систему :)

— Jamieson Becker

4

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

— Натан Крауз
источник

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

— Бретт Замир

2

У меня была похожая проблема , когда 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 .

— Элуан Керилл-Эвен
источник

Yeaaahhhh. ШУТКИ В СТОРОНУ! Я бы никогда не посмотрел на это. openssh-8.0p1-5.fc30.x86_64Кстати. У меня был открытый ключ от более раннего сервера с тем же именем, что и у нового сервера fedora@(baloo).sshkey.pub, который fedora@(baloo).sshkeyпередается в командной строке вместе с -iопцией. Ошибка аутентификации с новым ключом сервера, найденным в новом fedora@(baloo).sshkey- ключ RSA.

— Дэвид Тонхофер

2

Мы столкнулись с этой проблемой. Права доступа и права доступа к файлам .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 = отключено и перезагрузите компьютер.

— gaoithe
источник

2

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

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

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

— Аарон Чемберлен
источник

1

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

restorecon -Rv ~/.ssh

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

— lapin_
источник

1

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

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

— ihoru
источник

1

В нашем случае проблемы были связаны с тем, что наши правила брандмауэра и NAT не были правильно настроены.

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

Если кто-то доберется до этой точки. tcpdump и telnet могут быть вашими друзьями

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

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

Ssh может генерировать много трафика, что затрудняет поиск tcpdump, что вы ищете.

Это помогло мне

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Попробуйте подключиться к телнету с 3 разных серверов, а не с вашего текущего компьютера @ [mylocalip]. Вы хотите увидеть, какой трафик фактически достигает вашего сервера.

— nelaaro
источник

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 сервера sshd_config файл:

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 на том же удаленном сервере.

— kbulgrien
источник

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
....

— nelaaro
источник

0

У меня была эта проблема в CentOS 7. Я обычный пользователь Linux на основе Debian, поэтому я был рыбой из воды. Я заметил, что на некоторых серверах это работало, а на одном - нет. Audit.log не сказал ничего полезного, и secure.log тоже ничего не дал. Я обнаружил, что единственной реальной разницей были некоторые различия в контексте безопасности файлов и каталогов между теми, которые работали, и теми, которые не работали. Получить безопасность с

sudo ls -laZ <user-home>/.ssh

каталога (я предполагаю много значений по умолчанию для sshd_config).

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

Например

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

В моем случае я подозреваю, что пользователь был создан нестандартным способом. Его дом был каталогом /var/lib.

Больше информации в: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

— hanzo2001
источник