Азы работы с паролями в системе Linux/UNIX

Считается, что UNIX или Linux считаются гораздо более надежными и безопасными, чем Microsoft Windows, чьи постоянные проблемы с безопасностью уже воспринимаются как неизбежное зло. Все очень просто – в каждую систему встроен отработанный десятилетиями механизм безопасности – простой, надежный и понятный. И на новой системе он ВСЕГДА ВКЛЮЧЕН. Дальше каждый администратор системы волен либо поддерживать ее в порядке, выполняя простые рекомендации, либо отключить и игнорировать. Если вы относитесь ко второму типу, то дальше можете не читать и возвращаться на форумы, где обсуждаются антивирусы, антишпионы, скорость перезагрузки системы после BSOD, методы быстрой переустановки системы, когда она придет в полную негодность. Желаю удачи.

Для остальных – несколько простых техник. Во всех примерах использую редактор vi, но вы используйте что-нибудь более дружественное, например pico или nano. Пути к файлам соответствуют их расположению в Ubuntu.

1. НИКОГДА и НИКОМУ не давайте пароль пользователя root! И не используйте его сами! Сделайте его совершенно незапоминаемым, запишите на листе бумаги, запечатайте в конверт и положите в сейф – скорее всего, он вам никогда не понадобится. Но перед этим необходимо сделать базовую настройку системы. В некоторых системах, например Ubuntu, пошли еще дальше, там с момента установки используется команда sudo, войти в систему с логином и паролем пользователя root невозможно.

Создайте новых пользователей, которые будут работать в системе (пока вы еще работаете с правами root), например:

# adduser vpupkin
# passwd vpupkin

Сразу определитесь кто из пользователей будет иметь ВОЗМОЖНОСТЬ использовать права администратора, как минимум один пользователь (вы) должен быть задан. Добавьте их в группу admin (или wheel) (надеюсь, вы добавили только себя?):

# vi /etc/group
admin:x:4:vpupkin

Дайте им возможность выполнять команды с правами администратора – запустите комаду visudo (важно!) и добавьте в конец открывшегося файла строчку:

# visudo
%admin ALL=(ALL) ALL

Теперь КАЖДЫЙ пользователь, добавленный в группу admin, будет иметь возможность запускать команды с правами администратора системы или другого пользователя.

Все, теперь пароль root можно прятать подальше, он нам больше не нужен.

2. Используйте сложные пароли, устойчивые к лобовой атаке, атаке подбором по словарю. Сложные, но легко запоминаемые и НИКАК С ВАМИ НЕ СВЯЗАННЫЕ. А еще лучше, если у вас будет своя система генерации паролей, понятная только вам и которую вы не сможете забыть.
Никогда не передавайте свой пароль в качестве параметра программе и не сохраняйте в файлике на флешке. Кстати, файл истории команд, например .bash_history, кладезь опечаток, и невовремя введенных паролей в том числе.

3. Скорее всего, для удаленного доступа к Linux-серверу вы будете использовать SSH или OpenSSH, так что есть смысл поправить пару параметров в файле конфигурации, осложнив злоумышленнику жизнь, если он попытается взломать систему удаленно. В несвободной реализации SSH более гибкие настройки, например фильтрация по IP, но и в свободной реализации есть что улучшить (принимаем, что на сервере у нас установлен openssh-server, а на клиентской машине openssh-client). Откроем файл конфигурации сервера SSH и внесем кое-какие изменения:

$ sudo vi /etc/ssh/sshd_config
PermitRootLogin no
X11Forwarding no
AllowUsers vpupkin

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

4. Если есть возможность, пользуйтесь аутентификацией не на основе паролей, а на основе публичных ключей. Если всего пяток удаленных серверов и дюжина пользователей, то городить огород с доменной системой или Kerberos смысла не имеет, а вот ключи заслуживают пристального внимания.

Для начала проверим (на машине-клиенте), что наш каталог ключей скрыт от посторонних, он должен иметь атрибуты 700:

$ ls -la ~
drwx------ 2 vpupkin vpupkin 4096 1972-11-23 18:38 .ssh

Если такого каталога нет (хм, странно) или у него другие права, создадим его и зададим права:

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ cd ~/.ssh

Генерируем пару ключей приватный/публичный:

$ ssh-keygen -t rsa -C "vpupkin@vpupkin.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/vpupkin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/vpupkin/.ssh/id_rsa.
Your public key has been saved in /home/vpupkin/.ssh/id_rsa.pub.
The key fingerprint is:
88:a4:8d:38:7c:6b:bc:a3:12:30:b2:84:df:f8:e5:7f vpupkin@vpupkin.com

Проверяем корректность прав доступа к директории .ssh и RSA-ключам:

$ ls -la ~/.ssh
-rw------- 1 vpupkin vpupkin 1675 2008-11-26 02:21 id_rsa
-rw-r--r-- 1 vpupkin vpupkin 412 2008-11-26 02:21 id_rsa.pub
-rw-r--r-- 1 vpupkin vpupkin 12162 2008-11-21 23:41 known_hosts

Добавляем публичный ключ в список авторизованных ключей на удаленной системе:

$ cd ~; ssh-copy-id -i .ssh/id_rsa user@host
или
$ cd ~; ssh user@host "cat >> .ssh/authorized_keys" < .ssh/id_rsa.pub

В случае, если подкаталог .ssh и файл .ssh/authorized_keys на удаленной системе не существуют:

$ ssh user@host "mkdir -m 700 .ssh; umask 077; cat > .ssh/authorized_keys" < .ssh/id_rsa.pub

Для сохранения парольных фраз к приватным ключам запускаем ssh-agent:

$ eval `/usr/bin/ssh-agent`
Agent pid 3855

С помощью ssh-add добавляем в память агента парольную фразу от нашего ключа (если есть):

$ ssh-add
Identity added: /home/vpupkin/.ssh/id_rsa (/home/vpupkin/.ssh/id_rsa)

Для проверки просматриваем отпечаток секретного ключа:

$ ssh-add -l
2048 88:a4:8d:38:7c:6b:bc:a3:12:30:b2:84:df:f8:e5:7f /home/vpupkin/.ssh/id_rsa (RSA)

Выполняем вход на удаленный сервер без ввода пароля и парольной фразы:

$ ssh user@host
Linux rat 2.6.45-10-server #1 SMP Tue Feb 12 08:27:05 UTC 2009 i686

Все, аутентификация по публичному ключу настроена. Копируем публичный ключ на удаленные системы, приватный бережем как зеницу ока.

Можно отключить аутентификацию по паролю, оставив только аутентификацию по ключу. Можно, но не обязательно. Кроме того, в случае потери или повреждения ключа, ssh-сервер не примет ни одного вашего пароля. Если решились, делаем так (на сервере, в локальной консоли, а не по ssh):

$ cd /etc/ssh
$ sudo cp sshd_config sshd_config.orig
$ sudo vi sshd_config

PasswordAuthentication no
UsePAM no

$ sudo /etc/init.d/ssh restart

Voila!

P.S. последнюю часть статьи взял отсюда, некоторые вещи были описаны грамотнее и элегантнее.

1 Comment

[…] в предыдущей заметке я упомянул редактор vi, услышал просто стон “нет, […]

Leave a comment

Your comment