SSH ігнорує символів після правильної строки пароля?


18

Віддалена машина 10.10.10.1 має пароль "asdFGH12" для користувача з ім'ям "користувач". Я можу увійти, навіть якщо введіть пароль "asdFGH12dasdkjlkjasdus" або будь-які інші символи після рядка "asdFGH12".

$ ssh -v 10.10.10.1
OpenSSH_5.2p1 FreeBSD-20090522, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 10.10.10.1 [10.10.10.1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type 0
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1
debug1: match: OpenSSH_4.1 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2p1 FreeBSD-20090522
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.10.10.1' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:58
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
Last login: Tue Apr 23 14:30:59 2013 from 10.10.10.2
Have a lot of fun...
user@server:~> 

Це відома поведінка (певних) версій сервера SSH?


Що це за ОС?
slm

1
Мій демон ssh (OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 березня 2012) не дозволяє мені додавати зайві символи після пароля.
Антон

1
Проблема, безумовно, у схемі хешування. DES / традиційні скріплення хеш-файлів або прокладки всіх заданих паролів до восьми символів, щоб алгоритм хешування працював. Я би ставлю, що ви використовуєте традиційний варіант Unix, більшість дистрибутивів BSD та Linux принаймні були на рівні md5 за останнє десятиліття або близько того.
Братчлі

Відповіді:


26

Це не обмеження з боку вашого SSH-сервера, це обмеження з боку алгоритму хешування пароля вашого сервера.

Під час хешування паролів на Unix crypt()функція викликається. Тут може бути використаний один із багатьох резервних даних, можливо, використовується DES або інший обмежуючий алгоритм (для цього конкретного випадку я припускаю, що ваш сервер використовує DES). DES зазвичай не використовується за замовчуванням у сучасних операційних системах, оскільки це призводить до особливо поганого обмеження: міцність пароля та перевірка обмежена 8 байтами.

Це означає, що якщо ваш пароль був встановлений як "foobarbaz", він стає "foobarba", як правило, без попередження або повідомлення. Це ж обмеження стосується і валідації, що означає, що "foobarbaz", "foobarba" і "foobarbazqux" підтверджують цей конкретний випадок.


20

Я підозрюю, що ви використовуєте ОС для шифрування паролів DES, яка підтримує максимум 8 символів.

/server/361591/ssh-accepts-only-the-half-password

З man crypt(3)

РОЗШИРЕННЯ ГНУ

Версія цієї функції glibc2 має такі додаткові функції. Якщо сіль - це символьна рядок, що починається з трьох символів "$ 1 $" з наступним, щонайменше, вісьмома символами, і необов'язково закінчується "$", то замість використання машини DES, функція криптів glibc використовує алгоритм на основі MD5, і виводить до 34 байт, а саме "$ 1 $ <string> $", де "<string>" означає до 8 символів, що слідують за "$ 1 $" в солі, а потім 22 байти, вибрані з набору [a – zA –Z0–9./].
Весь ключ тут вагомий (замість лише перших 8 байт).

Ви можете перевірити налаштування пам’яті, щоб побачити, чи використовуєте ви MD5 чи DES:

% egrep "password.*pam_unix.so" /etc/pam.d/system-auth
password    sufficient    pam_unix.so md5 shadow nis nullok try_first_pass use_authtok

Ви також можете підтвердити, яку функцію хешування використовує ваша система за допомогою цієї команди:

% authconfig --test | grep hashing
 password hashing algorithm is md5

І ви можете побачити в цьому системному /etc/shadowфайлі, що він також використовує MD5:

root:$1$<DELETED PASSWORD HASH>:14245:0:99999:7:::

Коди, які ви побачите в /etc/shadowдля кожного типу хешування:

  • $ 1 - MD5
  • $ 2 - міхур
  • $ 2а - експлом
  • 5 доларів - SHA-256
  • 6 доларів - SHA-512

Ви можете налаштувати систему за допомогою цієї команди:

% authconfig --passalgo=sha512 --update

Будь-які існуючі паролі потрібно буде відновити. Ви можете використовувати цю команду, щоб змусити користувачів скинути їх наступного разу, коли вони ввійдуть:

% chage -d 0 userName

Список літератури


2
Перевірка конфігурації PAM лише покаже вам, що система використовує зараз , а не те, що було використано для шифрування пароля, який користувач використовує. Можливо, вони будуть іншими, якщо вони коли-небудь змінювалися.
Кріс Даун

Вибачте, це було як гаряче запитання, я не міг набрати відповідь так швидко, як усі думали 8-).
slm

Зауважте, що, authconfigяк правило, специфічно для RHEL (та похідних).
Кріс Даун

1
якщо authconfigконкретний, то альтернативний варіантgrep ENCRYPT_METHOD /etc/login.defs
Рахул Патіл,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.