Эта статья — часть Большого Мануала по настройке 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-клиент начинает ругаться благим матом, что ваш трафик пытаются прослушать, или сервер подменили (на самом деле, намного чаще из-за того, что систему переустановили). В общем, сносим ключи:

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

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

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

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

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

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

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

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

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

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

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

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