Отключено: нет поддерживаемых методов аутентификации

12

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

Я думаю, что я все правильно настроил на стороне клиента (Windows 7, PUTANT, PUTTYGEN и PLINK в PuTTY), но мне кажется, что механизм открытого ключа не работает (работает логин на основе пароля ssh). Я следовал за всеми шагами, подсказками и подсказками в:

Теперь я подозреваю, что я могу что-то упустить на стороне сервера (Linux, sshd), поэтому я публикую текущий /etc/ssh/sshd_configконтент:

Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Есть идеи, что я делаю не так?

ОБНОВЛЕНИЕ: я нашел совет для запуска sshd в режиме отладки , и вот вывод:

/home/winwin> /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.2p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.8 port 49828
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done

debug1: userauth-request for user winwin service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "winwin"
debug1: PAM: setting PAM_RHOST to "win7client"
debug1: PAM: setting PAM_TTY to "ssh"
Failed none for winwin from 192.168.1.8 port 49828 ssh2
debug1: userauth-request for user winwin service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
Failed publickey for winwin from 192.168.1.8 port 49828 ssh2
Received disconnect from 192.168.1.8: 14: No supported authentication methods available
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

Теперь я заметил два bad ownership or modes for directory /home/winwinсообщения, но я проверил владельца или режимы для директории / home / winwin и AFAICT, они в порядке:

/home> ls -lad winwin
drwxrwxr-x  21 winwin winwin 4096 Jul 13 21:24 winwin

И:

/home/winwin> ls -lad .ssh
drwxr-xr-x  2 winwin winwin 4096 Jul 14 12:06 .ssh

И:

/home/winwin/.ssh> ls -lad *
-rw-r--r--  1 winwin winwin 210 Jul 14 12:06 authorized_keys
-rw-r--r--  1 winwin winwin 210 Jul 14 01:58 authorized_keys.pub
-rw-r--r--  1 winwin winwin 394 Jul 14 01:57 authorized_keys.pub.orig

Что может быть не так?

ОБНОВЛЕНИЕ II: я попробовал chmod 600как предложено в ответе ниже:

/home/winwin> ls -lad .ssh
drw-------  2 winwin winwin 4096 Jul 14 13:13 .ssh

И:

/home/winwin/.ssh> ls -lad *
-rw-------  1 winwin winwin 210 Jul 14 12:06 authorized_keys

Но это все еще не работает. Почему я все еще получаю Authentication refused: bad ownership or modes for directory /home/winwinошибку?

— WinWin
источник

9

Попробуйте взять права на запись группы из вашего домашнего каталога:

chmod g-w ~/

Сделайте вашу папку .ssh доступной для чтения / записи / выполнения только вами :

chmod 700 ~/.ssh

Сделайте ваш авторизованный файл ключей доступным для чтения / записи только вам :

chmod 600 ~/.ssh/authorized_keys

Это должно удалить ошибки разрешений.

— Джон Т
источник

Я сделал так, как вы предложили ~/.sshи ~/.ssh/authorized_keys. Все еще не повезло. Что касается получения групповых разрешений на запись из самого домашнего каталога, я не могу этого сделать, так как это подорвало бы всю цель этого пользователя / группы, для которой он был создан. Домашний каталог этого пользователя должен быть доступен для записи группе (с таким же точным именем и gid!). +1 за попытку помочь.

— WinWin

Спасибо! chmod g-w ~/спас меня после нескольких часов безумия и растягивания волос, когда я не мог ssh с замазкой от имени одного из пользователей, с другими пользователями, работающими нормально ...

— PavelS

Да, спасибо, я создал свой домашний каталог с другим пользователем, и мне не хватало chmod gw ~ /

— Clarence Liu

5

Успех!

Все, что мне нужно было сделать, это изменить StrictModesна нет .

Согласно разделу 3.14 в FAQ по OpenSSH и http://blogs.nullvision.com/?p=114 .

Вау.

— WinWin
источник

Хм, это скорее обходной путь, чем решение. Позвольте мне проверить что-то на моей коробке.

— Роб

Мой ls -lad .sshпоказывает drwx, chmod 700 ~/.sshи все файлы внутри -rw, так что chmod 600 ~/.ssh/*ДОЛЖНЫ работать.

— Роб

Неважно, увидел Домашний каталог этого пользователя должен быть доступен для записи группе (с таким же точным именем и gid!) Ниже

— Роб

Этот способ бесполезен!

— Любовь

3

Была похожая проблема. Просматривая, я заметил, что мои домашние каталоги зашифрованы, и подозревал, что это проблема. Я скопировал файл авторизованных ключей в каталог за пределами зашифрованного домашнего каталога, изменил соответствующие разрешения (chmod 700 [dir], chmod 600 [dir] / authorized_keys и т. Д.).

Затем отредактируйте ваш sshd_config, чтобы сообщить sshd о новом местоположении для файла авторизованных ключей, перезапустите sshd, и все.

Кажется, исправил мою проблему.

— красный
источник

2

Похоже, что ваши разрешения для домашнего каталога (или, возможно, вашей папки .ssh / authorized_keys) неверны. Исправление этих ошибок должно исправить проблему с логином. Попробуйте, chmod 600 /home/winwin/.ssh/*
Вам может понадобиться chmod 700 /home/winwin/.ssh.

SSHd откажется загружать ваш authorized_keysфайл, если он может быть записан кем-либо, кроме вашего пользователя (как владельца), потому что это угроза безопасности.

— Дарт Андроид
источник

Спасибо +1. Посмотрите мое обновление выше, так как я до сих пор не могу понять, какими должны быть права доступа / владельца.

— WinWin

Я только что попробовал chmod 600 /home/winwin/.ssh/*. Это не помогло. : - /

— WinWin

1

@WinWin вы также установили его в .sshкаталоге? (Я обновил свой ответ).

— Дарт Андроид

Да. Все еще не повезло.

— WinWin

2

Я преодолел это и, наконец, нашел решение, которое не вызывает потенциального нарушения безопасности, как это делает StrictModes No.

Убедитесь, что ваши настройки следующие:

chmod 0755 / home / {userdir}

chmod 0700 / home / {userdir} /.ssh

chmod 0600 / home / {userdir} /.ssh/authorized_keys

Где {userdir} каталог, о котором идет речь.

Ключом является chmod 0755, который гарантирует, что только пользователь может писать на домашний диск. Я скопировал это из моего пользовательского конфига, который работал, и, Presto! Другие имена пользователей тоже начали работать!

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

— smcjones
источник

1

Это сообщение об ошибке также может быть вызвано тем, что SELinux препятствует доступу sshd authorized_keys. Попробуй это:

restorecon -FRvv ~/.ssh

(из этого ответа )

— RomanSt
источник

0

chown -R winwin.winwin /home/winwin/
chmod 700 /home/winwin/
find /home/winwin/ -type d -exec chmod 700 {} \;
find /home/winwin/ -type f -exec chmod 600 {} \;

— Дядя боб
источник

3

Добро пожаловать в Супер пользователя! Было бы хорошо, если бы вы могли объяснить, что делают эти команды.

— Slhck

0

В моем случае это был домашний каталог, у которого был другой владелец (root), чем фактический пользователь, которому принадлежит этот домашний каталог (моя глупость при создании домашнего каталога с root для другого пользователя).

Chown [user]:[group] /home/[user]

решил эту проблему (и, конечно, придерживайтесь прав доступа к файлу / директории, как указано в других ответах).

— Philippe
источник