Debian.pro

Блог для пользователей и администраторов Debian


Большой Мануал: часть 4. Настраиваем openssh-server.

Эта статья — часть Большого Мануала по настройке lamp-сервера на debian.

Предыдущая статья цикла — /etc/apt/sources.list.

Следующая часть цикла — hostname, файл hosts, ptr и вот это вот всё.

Если вы смогли дочитать до сюда, то вы знаете, что такое ssh, скорее всего. Если не знаете — то «это такая штука, через которую обычно вы к консоли сервера подключаетесь через PuTTY или командой ssh из консоли».
Ах да, про PuTTY. Я не представляю, зачем он вам нужен. Есть собранный с cygwin, кажется, внутри настоящий openssh-client под винду. Валяется здесь — http://sshwindows.sourceforge.net/
Если вы настолько несчастный, что вынуждены использовать windows, то советую использовать именно его, а не путтю. Синтаксис у него аналогичен команде ssh в остальных системах (которая в операционных системах как раз и есть openssh-client).

Под макось и линуксы же вы просто открываете консоль и пишете ssh user@host.
В общем, это всё лирика, нам в рамках мануала по настройке сервера важна именно серверная часть ssh (внезапно). Вам хостер поставил какой-то пакет ssh в шаблоне, как-то настроенный. Как прекрасно. Но мы всё же настроим его сами.
Для начала удаляем ключи сервера. Зачем? А есть хостеры-ублюдки, которые эти самые ключи не перегенеривают при установке машины. То есть, ssh-ключ сервера у них на _всех_ машинах, налитых из одного шаблона, одинаковый. Вообще же ключ сервера запоминается клиентом (в случае линуксов — в файле ~/.ssh/known_hosts). При смене ключа ssh-клиент начинает ругаться благим матом, что ваш трафик пытаются прослушать, или сервер подменили (на самом деле, намного чаще из-за того, что систему переустановили). В общем, сносим ключи:

root@server:~# rm /etc/ssh/ssh_host_*

Переставляем пакеты (заодно обновятся, если есть куда):

root@server:~# apt-get install --reinstall libssh2-1:amd64 openssh-blacklist openssh-blacklist-extra openssh-client openssh-server ssh

В этот момент ssh у вас отвалится (но у вас же чистая виртуалка и вам её не жалко, right?), а при новом подключении ssh-клиент обязан начать ругаться примерно так:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
<какая-то непонятная последовательность букв и цифр>
Please contact your system administrator

Мы сами системные администраторы, поэтому в курсе, что случилось. Только вот старый host-key надо удалить на ноуте, чтобы больше не ругалось, а новый запомнило. Если у вас это первый сервер, то вам можно просто сделать так:

user@laptop:~$ > ~/.ssh/known_hosts

Если сервер не первый, то удалите ту строчку, на которую ssh-клиент ругался, из этого файла.
Можно ещё так:

user@laptop:~$ ssh-keygen -f "~/.ssh/known_hosts" -R server_ip
user@laptop:~$ ssh-keygen -f "~/.ssh/known_hosts" -R server_fqdn

Ну а теперь коннектимся, открываем любимым текстовым редактором файл /etc/ssh/sshd_config и начинаем ломать его.
Первое, что нам интересно, это порт:

# What ports, IPs and protocols we listen for
Port 22

Принято считать, что смена порта чем-то помогает. В общем-то да, в 22й порт любого адреса в интернете стучится толпа ботов. Можно поменять. От целенаправленной атаки/сканирования это не спасет — порт ssh-сервера легко найти.
Главный мой вам совет — не забудьте порт потом. А то я на 2 сервера попасть не мог несколько месяцев (хорошо, что они не ломались). На одном ssh висел на 80м порту, на втором — на 443м, кхе кхе. А я всё это время думал, что случайно там запустил неработающий вебсервер, а ssh уронил (благо, серверы не были веб-серверами вовсе).
Вот что намного интереснее, так это строчка:

PermitRootLogin yes

yes — это разрешить вход рутом по паролю через ssh. Вот этого точно не требуется. Можно поставить no (только не забудьте создать отдельного пользователя перед этим, которым вы будете заходить на сервер по ssh, а от него делать su). Когда серверов несколько, использовать no всё же не очень удобно. Намного удобнее выставить PermitRootLogin without-password. Тогда рутом можно будет зайти только по ssh-ключу.

Дальше можно найти строчку такую:

Subsystem sftp /usr/lib/openssh/sftp-server

Вот она нас точно не устроит. Эту строчку удаляем, а в конец файла дописываем это:

Subsystem sftp /usr/lib/openssh/sftp-server -l INFO
Match group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp
AllowTcpForwarding no

Подробнее про это я писал в статье sshfs/sftp chroot, здесь же я вкратце расскажу, что мы только что сделали:
1) мы включили расширенное логгирование sftp-клиентов (в /var/log/auth.log будет записана каждая операция с файлами, которая делалась через sftp).
2) пользователи, входящие в системную группу sftponly не смогут выйти за пределы каталога /home/${username} (и не смогут заодно подключиться к консоли сервера по ssh). То бишь, «ограничивание» пользователя будет происходить одной командой (которая добавит его в группу sftponly), а не пляской с бубном вокруг конфига.
Про таких ограниченных пользователей я напишу позже (где-то в 6й части, вероятно).

В общем-то, этого должно быть достаточно, если за основу вы взяли sshd_config из дебиановского пакета — все остальные параметры из коробки особой опасности не несут. Все параметры подробно описаны в man sshd_config, можете почитать и отредактировать по своему вкусу.
Ну и осталось порестартить ssh-сервер:

root@server:~# /etc/init.d/ssh restart

Можно ехать дальше.

24.05.2015 byinkvizitor68sl|big-manual

Комментарии (10):

  1. а :

    Что насчет ограничения входа по IP, это даже не стоит упоминания?

  2. Это, скорее, про firewall (можно через allowusers накрутить или через hosts.allow/hosts.deny, правда).
    А вообще любые ограничения по ip — вещь печальная частенько ) IP у людей меняются всё чаще и чаще.

  3. evg :

    apt-get update же :-)

  4. evg :

    Хотя да, проглядел, что она есть в конце предыдущей статьи цикла. Отбой :-)

  5. bosha :

    А что насчёт AllowUsers и AllowGroup?

  6. А что с ними? )

  7. bosha :

    Про них стоило бы упомянуть. :)
    Я PermitRootLogin вообще не трогаю, да и ряд других настроек. Достаточно разрешить только определённым ползователям/группа заходить используя ssh.

  8. А. Неудобно каждый раз в конфиг этот лазить. Потом видно будет, почему так(в районе создания пользователей).

  9. mrz :

    https://www.electricmonk.nl/log/2015/07/13/ssh-chrootdirectory-sftponly-not-working-fixed/
    Может будет полезно кому-нибудь, у кого в конфиге включен PAM и ломается ssh из-за Subsystem sftp итд

  10. > Может будет полезно кому-нибудь, у кого в конфиге включен PAM и ломается ssh из-за Subsystem sftp итд
    Я не зря указал конкретную строку, которую заменять надо.
    UsePAM в debian-based всегда включен, а Subsystem sftp всегда после него.

Написать комментарий