Увійти на сервер ssh: Дозвіл відхилено, будь ласка, спробуйте ще раз

Я намагаюся увійти на свій ssh-сервер за допомогою імені користувача та пароля, але я отримую цю помилку після введення правильного пароля:

Permission denied, please try again.

Я можу ввійти, використовуючи паскі на іншій машині, але я не відключив звичайну автентифікацію паролів. Єдине, що я відключив - це кореневі логіни.

Ось мій файл sshd_config:

# Конфігураційний файл, створений пакетом
# Детальніше див. На сторінці sshd_config (5)

# Які порти, IP-адреси та протоколи ми слухаємо
Порт 22
# Використовуйте ці параметри, щоб обмежити, до яких інтерфейсів / протоколів прив'язуватиме sshd
#ListeAddress ::
#ListenAddress 0.0.0.0
Протокол 2
# HostKeys для протоколу версії 2
HostKey / etc / ssh / ssh_host_rsa_key
HostKey / etc / ssh / ssh_host_dsa_key
HostKey / etc / ssh / ssh_host_ecdsa_key
#Привілейний розділ увімкнено для безпеки
UsePrivilegeSeparation так

# Термін служби та розмір ефемерного ключа сервера версії 1
KeyRegenerationInterval 3600
ServerKeyBits 768

# Ведення журналів
SyslogFacility AUTH
Інформація про LogLevel

# Аутентифікація:
ВхідGraceTime 120
PermitRootLogin немає
StrictModes так

Аутентифікація RSA так
PubkeyAuthentication так
#AuthorizedKeysFile% h / .ssh / санкціоновані_кеї

# Не читайте файли ~ / .rhosts та ~ / .shosts користувача
ІгноруйтеРости так
# Для цього вам також знадобляться ключі хоста в / etc / ssh_known_hosts

RhostsRSAAuthentication no
# подібний для версії протоколу 2
Аутентифікація hostbased
# Відмініть, якщо ви не довіряєте ~ / .ssh / known_hosts для RhostsRSAAuthentication
#IgnoreUserK knownHosts так

# Щоб увімкнути порожні паролі, перейдіть на так (НЕ РЕКОМЕНДУЄТЬСЯ)
PermitEmptyPassword ні

# Змініть на так, щоб увімкнути паролі у відповідь на виклик (будьте обережні
# деякі модулі та потоки PAM)
ChallengeResponseAuthentication no

# Змініть на "ні", щоб вимкнути тунельовані текстові паролі
Аутентифікація пароля так

# Варіанти Kerberos 
#KerberosAuthentication no
#KerberosGetAFSToken немає
#KerberosOrLocalPasswd так
#KerberosTicketCleanup так

# Параметри GSSAPI
#GSSAPIAаутентифікація ні
#GSSAPICleanupCredentials так

X11 Пересилання так
X11DisplayOffset 10
PrintMotd ні
PrintLastLog так
TCPKeepAlive так
#UseLogin ні

#MaxStartups 10:30:60 
#Banner /etc/issue.net

# Дозволити клієнтові передавати змінні середовища локалі
AcceptEnv LANG LC_ *

Підсистема sftp / usr / lib / openssh / sftp-сервер

# Установіть це на "так", щоб увімкнути автентифікацію PAM, обробку облікового запису,
# та обробка сеансу. Якщо це ввімкнено, автентифікація PAM буде
# буде дозволено через ChallengeResponseAuthentication та
# Аутентифікація пароля. Залежно від конфігурації PAM,
# Аутентифікація PAM через ChallengeResponseAuthentication може обійти
# налаштування "PermitRootLogin без пароля".
# Якщо ви просто хочете, щоб PAM-акаунт і перевірки сеансу не працювали
# Ідентифікація PAM, тоді ввімкніть цю функцію, але встановіть пароль
# та ChallengeResponseAuthentication на "ні".
UsePAM так 
IgnoreUserK knownHosts немає
Аутентифікація пароля так

Останні 2 рядки я додав в останній спробі змусити його працювати. (У мене їх є на інших моїх vps, і вони там працюють)

Ось перелік ~ / .ssh / каталогу мого користувача:

ls -la /home/skerit/.ssh
всього 16
drwx ------ 2 skerit skerit 4096 2011-06-25 15:11.
drwxr-xr-x 4 skerit skerit 4096 2011-07-07 21:05 ..
-rw-r - r-- 1 skerit skerit 1882 2011-06-25 15:15 санкціоновані_ ключі
-rw-r - r-- 1 skerit skerit 884 2011-06-23 22:59 відомі_хости 

Це вихід / usr / sbin / sshd -d:

debug1: userauth-запит для користувача skerit service ssh-connection method none
debug1: спроба 0 відмов 0
debug1: PAM: ініціалізація для "skerit"
debug1: PAM: встановлення PAM_RHOST на "82.197.70.70"
debug1: PAM: встановлення PAM_TTY на "ssh"
debug1: userauth-запит для користувача skerit service ssh-connection methodkeykey
debug1: спроба 1 відмов 0
debug1: перевірити, чи pkalg / pkblob прийнятні
debug1: Перевірка файлу чорного списку /usr/share/ssh/blacklist.RSA-2048
debug1: Перевірка файлу чорного списку /etc/ssh/blacklist.RSA-2048
debug1: privremeno_use_uid: 1000/1000 (e = 0/0)
debug1: випробування файлу відкритого ключа /home/skerit/.ssh/authorized_keys
debug1: fd 4 очищення O_NONBLOCK
debug1: Resto_uid: 0/0
debug1: privremeno_use_uid: 1000/1000 (e = 0/0)
debug1: випробування файлу відкритого ключа /home/skerit/.ssh/authorized_keys2
debug1: Не вдалося відкрити авторизовані ключі '/home/skerit/.ssh/authorized_keys2': Немає такого файлу чи каталогу
debug1: Resto_uid: 0/0
Помилка publickey для skerit від порту 82.197.70.70 57154 ssh2
debug1: userauth-запит на пароль користувальницької послуги skerit
debug1: спроба 2 відмов 1
debug1: PAM: не вдалося встановити автентифікацію пароля для skerit: Помилка аутентифікації
Помилка пароля для скарту з порту 82.197.70.70 57154 ssh2 

Потім я спробував увійти на ssh-сервер ІЗ Ssh-сервера (локально), використовуючи ІМЕ ІМЕНТ і пароль, і це спрацювало. Це було у файлі auth.log:

8 липня 12:21:50 vpsnl1 sshd [27298]: debug1: не вдалося відкрити ключовий файл '/ etc / ssh / ssh_host_ecdsa_key': такого файлу чи каталогу немає
8 липня 12:21:50 vpsnl1 sshd [27298]: помилка: не вдалося завантажити ключ хоста: / etc / ssh / ssh_host_ecdsa_key
8 липня 12:22:16 vpsnl1 sshd [27298]: pam_unix (sshd: auth): збій автентифікації; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 82.197.70.70 user =
сквіт
8 липня 12:23:50 vpsnl1 sshd [27439]: прослуховування сервера на порту 0.0.0.0 22.
8 липня 12:23:50 vpsnl1 sshd [27439]: прослуховування сервера :: порт 22.
8 липня 12:24:07 vpsnl1 sshd [27458]: помилка: не вдалося завантажити ключ хоста: / etc / ssh / ssh_host_ecdsa_key
8 липня 12:24:14 vpsnl1 sshd [27458]: Прийнятий пароль для skerit з порту 127.0.0.1 57667 ssh2
8 липня 12:24:14 vpsnl1 sshd [27458]: pam_unix (sshd: сесія): сеанс відкрито для користувача skerit by (uid = 0)
8 липня 12:24:25 vpsnl1 sshd [27471]: отримано відключення від 127.0.0.1: 11: відключено користувачем
8 липня 12:24:25 vpsnl1 sshd [27458]: pam_unix (sshd: session): сесія закрита для користувача skerit 

Ви впевнені, що обліковий запис користувача, до якого ви намагаєтесь отримати доступ, правильно налаштований? Якщо ви ввійдете в систему як root в системі, чи можете ви suв обліковому записі користувача?

# su - username

Що ви бачите у своїх журналах після невдалої спроби з'єднання? У багатьох системах sshd буде входити в щось /var/log/secureабо /var/log/auth.log. Також зазначу, що ви PasswordAuthenticationввімкнули, але ChallengeResponseAuthenticationвимкнено. Чи бачите ви таку саму поведінку, якщо включите ChallengeResponseAuthentication?

Ось кілька загальних кроків діагностики, які потрібно використовувати, коли у вас є проблеми з ssh:

• Увімкнути детальну діагностику в ssh:

  ssh -v host.example.com
  

  Це призведе до того, що клієнт виводить різні діагностичні повідомлення під час узгодження з'єднання. Це часто дасть зрозумілу проблему.

• Запустити сервер у режимі налагодження.

  На своєму сервері зупиніть sshd та запустіть його з командного рядка так:

  /usr/sbin/sshd -d
  

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

Якщо жодне з них не допоможе вам зрозуміти, що відбувається, ви додали б висновок до свого питання?