CentOS
Серверная ОС CentOS («Синтос»), наряду с FreeBSD, является одним из основных вариантов, которые я выбираю, когда создаю новый (виртуальный) выделенный сервер, если речь идёт о Un*x-сервере.
Подробности, новости и прочие вопросы, относящиеся к Синтосу, просьба искать на его официальных ресурсах, здешняя запись служит скорее сводкой того, как и что я настраиваю в случае, когда использую Синтос.
Содержание |
Ссылки по теме
Выбор версии
По возможности, CentOS 5.4, если возможно — 64-битная.
Первые действия после установки
Условные имена
Далее я использую условное имя для вашего сервера host.example.com, замените его на подлинное имя вашего сервера в приведённых ниже текстах команд.
В качестве номера секретного порта ssh используется 2134, в качестве условного имени технического пользователя tweedledum. Важно: не используйте именно эти значения в вашем конкретном случае! Используйте любые другие! Имя порта лучше брать не менее чем четырёхзначным, и его не должно быть в файле /etc/services; имя пользователя также не должно быть очевидным (типа admin)
Изменить пароль root
Это первое, что вы должны сделать после первого успешного входа по ssh:
passwd root
(можно не указывать root, но я предпочитаю всегда явно указывать существенные аргументы, чтобы вошло в привычку).
Важно: ни в коем случае не закрывайте текущую ssh-сессию. Откройте новую и попробуйте войти с новым паролем. Если в случае виртуального выделенного сервера (VDS/VPS) во многих случаях можно сбросить пароль root, не переустанавливая сервер целиком, то в случае настоящего выделенного сервера это станет приключением и вероятнее всего, влетит вам в копеечку).
Обязательно запишите этот пароль, на лист бумаги (который потом тщательно спрячьте в недоступное место), или же в файл, хранящийся в закодированном хранилище (таком, как том Truecrypt, или же зашифрованный программой вида PGP/GnuPG и т.п.). Не имейте привычки хранить пароли в явном виде в доступном не только вам месте, это неизбежно обойдётся вам весьма и весьма дорого.
Настроить сетевой экран
Установим программу настройки сетевого экрана (брандмауэра):
yum install system-config-securitylevel-tui system-config-securitylevel-tui
открыть порт SSH, если предполагается Web-сервер — 80 и 443, и сразу же открыть вспомогательный, «секретный» порт для SSH (в этом примере я использую порт 2134, в реальности, естественно, использую другие).
Важно: на время настроек установите SELinux в режим предупреждений (Permissive); режим отключения (Disabled), если только он не назначен как единственно возможный (в случае VPS такое часто бывает), слеудет выбирать с осторожностью — это сказывается на уровне общей безопасности системы.
Настроить sshd
Сконфигурируем sshd так, чтобы он принимал соединения на секретный порт. Зачем это делать? Чтобы избежать неизбежного потока попыток войти на ваш сервер из-под словарных, часто встречающихся, или системных имён. Не зная секретного порта, абсолютное большинство желающих попасть к вам без спроса оставят эти попытки.
Вы всегда можете найти все записи о попытках соединений по ssh в системном журнале /var/log/secure.
В файле /etc/ssh/sshd_config найдите строку (по умолчанию она закомментирована решёткой)
Port 22
и добавьте за ней ещё одну строку с указанием секретного порта:
Port 22 Port 2134
Убедитесь, что используется только протокол версии 2 (это по умолчанию), т.е. что есть строка
Protocol 2
Сохраните файл и обязательно проверьте его корректность командой
sshd -t
(в зависимости от настроек, могут потребовать указать полный путь к sshd; полный путь узнаете командой which sshd). Если команда завершилась без сообщений, всё в порядке. Если хоть что-нибудь сообщила — исправьте до перезагрузки sshd. В противном случае возможна ситуация, когда sshd не запустится и единственным выходом станет перезагрузка ОС на VPS (в случае DS не всё так плохо, но потребуется физический контакт с сервером, чтобы вернуть всё в рабочее состояние).
После внесения изменений перезагрузите sshd
service sshd restart
и попробуйте подсоединиться к серверу по секретному порту:
ssh -p 2134 root@host.example.com
Если удалось войти, двигайтесь дальше, если отказывают в соединении — проверьте, что
- в настройках брандмауэра открыт дополнительный порт (заново запустите system-config-securitylevel-tui или, если вам так привычнее, исправьте вручную файл /etc/sysconfig/iptables — но лучше не смешивать эти два метода, потому что программа конфигурирования, скорее всего, перезапишет упомянутый файл, и отменит все вручную введённые правки
- сервис sshd был перезапущен (командой service sshd restart)
После того, как удалось войти по секретному порту, отключим стандартный в sshd. В файле /etc/ssh/sshd_config закомментируйте или удалите строку
Port 22
после чего сохраните файл, проверьте на корректность при помощи sshd -t и перезагрузите sshd. Не закрывая текущей root-сессии, попробуйте открыть новую по секретному порту (см. выше). Если не получилось, проверьте как указано выше, всё ли настроено верно.
После того, как всё сконфигурировано, добьёмся того, чтобы соединяться по ssh под именем root было невозможно вводом пароля — настроим соединение по т.н. ключу, но вначале создадим «технического пользователя», для большинства технических работ.
Создание технического имени
Использовать для все целей root — исключительно плохая идея. Поскольку нет ничего проще, как полностью разрушить всю установку вашего сервиса одной неосторожной командой, используйте для большинства операций вспомогательное, техническое имя пользователя для текущей работы и не забывайте проверять, под каким именно именем вы работаете (командой whoami).
Создаём имя пользователя и устанавливаем ему пароль:
useradd -m -s /bin/bash -c "Auxiliary user" tweedledum passwd tweedledum
Пароли для root и любого другого пользователя ни в коем случае не должны совпадать или быть слишком близкими по написанию. Не забудьте, что вам следует использовать любое другое не слишком легко угадываемое имя вместо tweedledum.
Настройка аутентификации по ключам
Аутентификация по паролю — самая древняя и привычная; но в случае, если ввод пароля можно каким-либо образом перехватить, она разом теряет надёжность. Надёжнее использовать т.н. авторизацию ключами — для начала, если это вы ещё не делали, эти ключи нужно создать. Если ваша основная операционная система, из которой вы управляете сервером, относится к Linux и используется openssh, то ключ создаётся такой командой:
ssh-keygen -t rsa
У вас спросят, куда класть ключ (под каким именем в какой каталог), можно принять предложенный вариант.
У вас спросят пароль (условную фразу, для защиты ключа). Надёжнее всего создать его и сделать как можно более длинным. Чтобы создать ключ, который не будет требовать условную фразу, просто нажмите оба раза ввод на предложение ввести условную фразу. Ключ без условной фразы удобен, если вам нужно производить автоматизированные действия на сервере, когда нет удобного способа вести пароль.
В случае, если вы используете Windows, проще и надёжнее всего установить бесплатный комплект программ, воспроизводящих рабочую среду Linux, Cygwin. Там используются те же самые команды и имена каталогов, поэтому далее я предполагаю, что вы используете Linux.
Создаём на сервере, если он не был уже создан (например, исполнением команд ssh-keygen, ssh и пр.) каталог, куда поместим файл с ключами ~/.ssh (в той сессии, где вы вошли от имени root):
mkdir ~/.ssh chmod 700 .ssh
Пересылаем ключ на ваш сервер:
scp -P 2134 ~/.ssh/id_rsa.pub root@host.example.com:~/.ssh/my_id_rsa.pub
(намеренно указано иное конечное имя для ключа, чтобы не переписать ключ, созданный для записи root на сервере, если такой был)
Теперь в ssh-сессии root на сервере добавляем переданный ключ в хранилище ключей:
cd ~/.ssh cat my_id_rsa.pub >> authorized_keys2 chmod 600 authorized_keys2
Последняя команда необязательна, если файл authorized_keys2 уже существовал. Файл с присланным ключом (my_id_rsa.pub) после этого можно удалить, а можно и сохранить, дело ваше.
Теперь попробуйте открыть новую ssh-сессию ддля пользователя root с вашего рабочего места:
ssh -p 2134 root@host.example.com
Если вошли и пароля не спросили (кроме кодовой фразы для ключа, если вы её указывали) — можно заканчивать конфигурацию sshd; если спрашивают пароль — см. выше, убедитесь, что права доступа к .ssh каталогу и файлу authorized_keys2 именно такие, как указано выше.
Важно: прежде, чем разрешить аутентификацию root только при помощи ключей, убедитесь, что вы можете стать этим пользователем при помощи su/ssh из открытой ssh-сессии. Войдите под техническим именем и выполните su:
ssh -p 2134 tweedledum@host.example.com su -
В ответ на запрос пароля командой su, укажите пароль root. Если удалось стать root (запустите whoami), двигаемся дальше. Если нет, установите пароль root ещё раз (см. выше).
Теперь вносим ещё одно изменение в /etc/ssh/sshd_config — в нём должна быть вот такая строка
PermitRootLogin without-password
Не пугайтесь её смысла — это не означает, что все, кому не лень, смогут стать root без пароля, просто вы потребуете, чтобы аутентификация по паролю в случае root не производилась. Именно для этого мы и создали и перенесли, куда следует, ключ.
Сохраните файл, убедитесь при помощи sshd -t, что с ним всё в порядке, и перезагрузите sshd:
service sshd restart
Важно: не закрывая существующей сессии root, попробуйте открыть новую. Если вошли без требования пароля root, всё в порядке, едем дальше. Если нет — повторите шаги выше. Не закрывайте хотя бы одну активную root-сессию, пока все шаги не будут выполнены и попытка входа не увенчается успехом!
Файлы ключей (id_rsa и id_rsa.pub в ~/.ssh на вашем рабочем месте) берегите как зеницу ока, сделайте их копию в недоступном другим месте и никогда без особой нужды не оставляйте копию файла с секретным ключом, id_rsa, где-либо ещё. Кто владеет секретным ключом, тот получит, если не ограничен доступ по IP, полный доступ к вашему серверу.
комментарии поддерживаются Disqus
