Так, хоча це досить рідко, це, безумовно, можливо.
Замість того, щоб намагатися реалізувати його самостійно, оскільки /etc/password
/etc/shadow
метод аутентифікації на основі замовчуванням не передбачає такої конфігурації, більш простим способом є делегування автентифікації до бек-енду, який вже підтримує декілька паролів для користувача.
Добре відомо , один LDAP , який userPassword
атрибут багатозначний в відповідно до RFC4519 :
Прикладом потреби в декількох значеннях в атрибуті 'userPassword' є середовище, коли кожного місяця від користувача потрібно використовувати інший пароль, створений деякою автоматизованою системою. Під час перехідних періодів, як і останній та перший день періодів, можливо, буде потрібно дозволити два паролі, щоб два періоди поспіль були дійсними в системі.
Незважаючи на цей RFC, вам, можливо, знадобиться змінити конфігурацію політики паролів у більшості реалізацій сервера каталогів, щоб цей параметр був фактично прийнятий.
З боку Linux, нічого не забороняє робити це (тут аккаунт з іменем testuser
давались pass1
і pass2
як userPassword
значення атрибутів):
$ uname -a
Linux lx-vb 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ grep VERSION /etc/os-release
VERSION="13.04, Raring Ringtail"
$ grep "^passwd" /etc/nsswitch.conf
passwd: files ldap
$ ldapsearch -LLL -h localhost -p 1389 -D "cn=directory manager" -w xxxxxxxx "uid=testuser" userPassword
dn: uid=testuser,ou=People,dc=example,dc=com
userPassword:: e1NTSEF9b2JWYXFDcjhNQmNJVXZXVHMzbE40SFlReStldC9XNFZ0NU4yRmc9PQ==
userPassword:: e1NTSEF9eDlnRGZ5b0NhKzNROTIzOTFha1NiR2VTMFJabjNKSWYyNkN3cUE9PQ==
$ grep testuser /etc/passwd
$ getent passwd testuser
testuser:*:12345:12345:ldap test user:/home/testuser:/bin/sh
$ sshpass -p pass1 ssh testuser@localhost id
uid=12345(testuser) gid=12345 groups=12345
$ sshpass -p pass2 ssh testuser@localhost id
uid=12345(testuser) gid=12345 groups=12345
$ sshpass -p pass3 ssh testuser@localhost id
Permission denied, please try again.
Ось деякі технічні та безпечні наслідки такого типу конфігурації:
- Обліковий запис користувача, очевидно, буде більш вразливим до атак, хоча тут дійсно важливо якість та захист паролів більше, ніж їх кількість.
- Більшість комунальних служб припускають, що користувач має єдиний пароль, тому не дозволяє користувачеві індивідуально оновлювати один з паролів. Тоді зміна пароля, ймовірно, призведе до отримання єдиного атрибута пароля для користувача.
- якщо мета полягає в тому, щоб дозволити декільком людям ділитися одним і тим же обліковим записом, використовуючи кожен свій власний пароль, не існує механізму, щоб визначити, хто насправді входить у систему, грунтуючись на використаному паролі.
sudo
щоб дозволити user1 запускати команди як user2. (sudo
не тільки для запуску команд як root; він може виконувати команди як будь-який користувач.)