Putty — вход в консоль Linux из Windows

Когда я только начинал возиться со своим «сервером»,  то настроил доступ к его графическому рабочему столу при помощи NX. Описано это мной на вот этой странице. Но зачастую для решения «управленческих» задач нет нужды запускать «тяжеловесный» графический десктоп, а достаточно всего-лишь «легкой» и быстрой консоли. В случае с Linux-ом все просто — там ssh-клиент присутствует. Но периодически возникает нужда войти в «сервер» из под Windows. Для этой цели лично я пользуюсь программой PuTTY. Причина моего выбора проста — программа бесплатная, кроме того, она легко устанавливается и также легко настраивается.

Итак, для начала идем на домашнюю страницу программы и качаем инсталятор программы. (Если приведенные мной ссылки устарели, просто «Google-им» по-быстренькому). Устанавливаем. Думаю, тут не возникнет никаких трудностей.

Запускаем PuTTY (обычно это — «Пуск» -> «Программы» -> «PuTTY» -> «PuTTY»).  И видим вот такое окно настройки и запуска PuTTY:

putty_main
Рис. 1 Окно настройки и запуска PuTTY

Чтобы, как говорится, ну совсем уж «по-быстрому»», достаточно всего лишь в поле «Host name (or IP adress)» ввести, как нас и просят, либо имя, либо IP-адрес компьютера, к которому мы будем подключаться и затем щелкнуть кнопку «Open«. В принципе, стоило бы сначала еще подредактировать пару настроек, ну да ладно, мы ведь очень торопимся. К настройкам мы еще вернемся позже, а пока… Если Вы подключаетесь к выбранному компьютеру в первый раз, то получите вот такое сообщение:

putty_host_key
Рис. 2 Запрос на запись ключа удаленного компьютера

Суть его в том, что Вам предлагают убедиться — а к тому ли удаленному компьютеру Вы подключаетесь, и если «да», то сохранить его ключ, чтобы избежать подобного вопроса в будущем. Вы можете сохранить ключ (ответ «Да»), не сохранять ключ (ответ «Нет») и прервать соединение (кнопка «Отмена»). Кстати, такой же самый вопрос Вы получите снова, если попытаетесь обратится к тому же удаленному компьютеру, но уже с использованием другого имени (например, раньше Вы подключались к нему по IP-адресу и сохранили ключ, а теперь пытаетесь подключиться по имени компьютера).

Чтобы продолжить подключение к удаленному компьютеру, жмем «Да». (Можно выбрать и «Нет», но тогда при следующем подключении Вам придется снова отвечать на вопрос о ключе). В любом случае запустится окно консоли, и Вам будет предложено осуществить вход в систему в (скажем так) «ручном» режиме:

ptty_login1
Рис. 3 Процесс входа с вводом имени пользователя и пароля с клавиатуры

Как видно на приведенном выше рисунке, при «ручном» входе первым делом Вы должны указать пользователя, от имени которого подключаетесь к удаленному компьютеру. Затем следует запрос пароля. Если введенные Вами имя и пароль приняты компьютером, то выводится информация о дате и времени предыдущего входа данного пользователя в систему, после чего появляется приглашение — Вы в консоли удаленного компьютера. Можно рулить!..

На что при этом стоит обратить еще внимание, так это на настройку SSH-демона на «принимающей стороне» (в Linux-сервере).  У него может быть запрещена авторизация (вход) по паролю. Вкратце я об этом упоминал тут (параметр «PasswordAuthentication» и его два возможных значения — «yes» и «no»). В случае, если авторизация по паролю запрещена, подключиться так, как только что было описано выше, не получится. В этом случае нужно настраивать доступ по ключу (об этом ниже).

«Нарулившись», вводим комманду «exit» — консоль закрывается, соединение с удаленным компьютером разрывается.

Теперь вернемся к той «парочке настроек», о которой я упоминал выше. Чтобы убедиться в необходимости одной из них, достаточно просто запустить Midnight Commander, или же найти файлы с кирилицей в именах. «Кракозябры»!!! Дело в том, что в подавляющем большинстве дистрибутивов Linux используется кодировка UTF-8, в то время, как в PuTTY по умолчанию включена KOI8-U. Поэтому, если не менять кодировку, то будут проблемы как с отображением кирилицы, так и с отображением псевдографики. Выглядеть это будет примерно так:

putty_wrong_locale
Рис. 4 "бНОПНЯ", обусловленная неправильной настройкой кодировки, а также, вызов контекстного меню PuTTY

Поправить настройку локали можно «по-быстрому», даже не выходя из консоли. Нужно лишь мышью «щелкнуть» в левом верхнем углу окна PuTTY. Появится выпадающее меню (как показано на рис. 4 выше). В меню нужно выбрать пункт «Change Settings«.  Появится то же самое окно настройки и запуска PuTTY, которое мы наблюдали в самом начале (см. рис. 1). В данном меню сначала нужно в левой колонке выбрать пункт «Translation«, затем в правой чвасти меню в выпадающем списке выбрать кодировку UTF-8, и потом внизу справа нажать кнопку «Apply» (как показано на рис. 5 ниже).

putty_tranlation
Рис. 5 Выбор локали (кодировки)

Внимание! Уже отображенные в окне консоли «кракозябры» после смены кодировки таковыми и останутся. Изменения будут видны лишь после перерисовки экрана (например, нажатия Ctrl+R в Midnight Commander)…

Вторая настройка не является критической. Лично я обчно её настраиваю для себя т.к. уже подслеповат. Это возможность выбрать вид и размер шрифта, используемого в консоли PuTTY. Для этого в окне настройки в левой колонке выбираем пункт «Appearance» (см. рис. 6):

putty_font_change
Рис. 6 Изменение шрифта

В правой части меню при этом появится раздел «Font setting». В нем выбираем кнопку «Change«. Откроется окно выбора шрифта, стандартное для многих приложений Windows. В нем выбираем и шрифт, и его размер, как говорится, «по вкусу», и затем жмем кнопку «ОК». Вернувшись в окно настройки,  нажимаем кнопку «Apply»  внизу справа. Изменение этой настройки меняет вид шрифта в окне консоли сразу же.

Недостаток изменения настроек «по быстрому» лишь один — указанные нами значения действуют только на время текущего сеанса и сбрасываются после его закрытия. Согласитесь, неудобно каждый раз работу начинать с того, что настраивать кодировки, шрифты, и т.д. и т.п. По этому, PuTTY позволяет создать сессию (сеанс) и сохранить все настройки в ней. Чтобы создать и сохранить новый сеанс, если сессия у Вас уже запущена, сначала завершите ее командой «exit«. Затем, по-новой запустите PuTTY («Пуск» -> «Программы» -> «PuTTY» -> «PuTTY»).  Мы снова видим окно настройки и запуска PuTTY. Но вместо того, чтобы просто вводить адрес и жать «Open«, мы выполним следующее:

putty_save_session
Рис. 7 Сохранение сессии
  1. Вводим имя или IP-адрес удаленного компьютера.
  2. Проверяем номер порта к которому подключаемся. В большистве случаев SSH-демон Linux-компьютеров настроен ожидать подключения именно на 22-иу порту. Но иногда администраторы меняют номер порта в целях безопасности или по иным причинам. Если у удаленного компьютера, к которому Вы планируете подключаться,  SSH-демон настроен на прослушивание порта с другим номером, то введите в это поле правильное значение.
  3. Проверяем, что подключаемся по протоколу SSH. (Вообще, программа PuTTY позволяет подключаться к различным службам).
  4. Вводим имя сессии. (Это имя Вы придумываете сами — как хотите, так и называйте).
  5. Нажимаем кнопку «Save«.

Все! Сессия сохранена. После этого можно настроить кодировку и шрифт, как показано выше (рис. 5 и 6). Выполнив изменения, возвращаемся в закладку «Session» и снова нажимаем кнопку «Save«. До изменения любых параметров убедитесь в том, что имя сессии присутствует в поле, на которое указвает указатель №4 на рис. 7. Если там пусто, то сначала нужно выбрать  имя своей сессии в списке начинающмся с пункта «Default settings» и шелкнуть кнопку «Load» справа.  Лишь после этого имеет смысл менять и сохранять настройки сессии…

Впоследствии, когда сессия создана, ей присвоено имя, и все настройки выполнены и сохранены, то для того, чтобы запустить сеанс, достаточно будет лишь дважды щелкнуть на имени сессии в списке (пониже  «Default settings»), а затем — все как на рис. 3 выше — логин, пароль… И еще — Вы можете сохранить не одну сессию, а столько, сколько Вам понадобится (если есть необходимость подключаться к разным компьютерам).

На этом можно было бы и поставить точку. Если бы не лень! О чем это я? Да о том, что лично мне лень каждый раз при старте сессии вводить имя пользователя и пароль! А что, можно и не вводить? Да, можно! По крайней мере, вручную… SSH-демон допускает автоматическую аутентификацию по ключу вместо пароля, а PuTTY предоставляет возможность указать имя пользователя, используемое при входе в удаленный компьютер. В итоге — вот так выглядит процедура входа в автоматическом режиме:

putty_login_auto
Рис. 8 Вход в автоматическом режиме

Как мы видим на приведенном рисунке, при авторизации программа сама подставляет имя пользователя «dmitry», а вместо пароля используется публичный ключ «rsa-key-20090211». Таким образом, мое вмешательство в процесс подключения к серверу минимизировано и по сути сведено к двойному щелчку мышью по имени выбранного сеанса. Для такого лентяя как я — в самый раз. Но, и для злоумышленника, который захочет взломать Ваш сервер — это тоже прекрасный подарок! По этому, настройку такого подключения стоит осуществлять лишь на тех компьютерах, про которые Вы уверены, что ими никто другой не пользуется, и не сможет использовать эту дыру в безопасности для доступа к Вашему серверу.

Начать стоит с генерации ключей. Для этой цели в комплекте с PuTTY поставляется программа PuTTYgen. Ее назначение — как раз генерировать эти самые файлы ключей. На компьютере, с которого планируем подключатся к серверу, запускаем PuTTYgen: «Пуск» -> «Программы» -> «PuTTY» -> «PuTTYgen»

PuTTYgen - генерация SSH ключа
Рис.9 программа PuTTYgen - генератор SSH ключей

И в программе этой выполняем следующие действия:

  1. Нажимаем кнопку «Generate«. После нажатия начинаем хаотично перемещать мышку по столу. При этом идет генерация ключа. Ход процесса показывает растущая слева напараво полоса индикации.
  2. После того, как ключ сгенерирован (пропадат индикатор прогресса, а вместо него появляются данные о ключе как на рис.9), жмем кнопку «Save public key«, чтобы соохранить файл т.н. «публичного» ключа. Назовем его, например, id_rsa.pub.
  3. Затем нажмем кнопку «Save private key«, чтобы сохранить файл т.н. «приватного» ключа. Назовем его, например, id_rsa.ppk.

Порядок сохранения ключей (кого первым, кого последним) — неважен. Важно лишь не забыть, куда мы их сохранили. Ключи эти парные. Приватный ключ хранится на компьютере, с которого осуществляется доступ. А публичный должен быть импортирован на сервер в специальный файл SSH-ключей того пользователя, от имени которого мы будем впоследствии подключаться. Для этого файл  id_rsa.pub нужно скопировть на сервер (дискетой, флешкой, почтой, ftp — как Вам будет удобно). А затем его нужно импортировать в файл ключей сервера, которй хранится у каждого пользователя в его «домашней» папке в подпапке .ssh и называется authorized_keys. Для этого нужно выполнить команду:

ssh-keygen -i -f id_rsa.pub >> $HOME/.ssh/authorized_keys

ВНИМАНИЕ!

  1. Команда эта должна выполняться уже в консоли сервера, к которому мы впоследствии будем подключаться по ключу. Поэтому, чтобы ее выполнить, сначала нужно войти в консоль сервера в «ручном» режиме, введя имя пользователся и пароль на клавиатуре.
  2. Команда должна выполнятться из той самой директории (папки), в которую был скопирован файл id_rsa.pub. В противном случае в команде нужно будет указать полный путь к файлу ключа.
  3. Команду необхдимо выполнять от имени того пользователя, который впоследствии будет осуществлять подключение к серверу.

Теперь сервер готов к авторизации данного пользователя по ключу. Осталось лишь настроить PuTTY на использование этого самого ключа. Для этого в окне настройки в левой колонке выбираем пункт «SSH», а в нем подпункт «Auth». В правой половине открывшегося окна жмем  кнопку «Browse» и указываем месторасположение второго файла ключа — id_rsa.ppk. (см. рис. 10 ниже)

Выбор файла ключа
Рис. 10 Настройка PuTTY на использование файла приватного ключа.

Теперь при соединении с сервером PuTTY будет использовать указанный файл ключа вместо пароля. Ну и последнее, что осталось сделать, это указать PuTTY какое имя пользователя подставлять при подключении к серверу. Для этого в окне настройки в левой колонке выбираем пункт «Data«, а в правой половине окна в поле «Auto-login username» вводим имя пользователя (как показано на рис. 11 ниже).

putty_user
Рис. 11 Ввод имени пользователя для автоматического входа в систему

Выполнив эти два пункта (выбор имени и ключа) не забываем сохранить сессию, как показано на рис. 7 выше. Все. Отныне при запуске этой сессии PuTTY будет автоматом подставлять и имя пользователя и ключ (вместо пароля). При этом ничего руками вводить не нужно будет.

Почитать подробнее про SSH, а также настройку этой службы на сервере можно по ссылкам:

  1. http://www.opennet.ru/base/sec/ssh_intro.txt.html
  2. http://baybox.narod.ru/linux/putty.html
  3. http://www.pentarh.com/wp/2008/07/21/ssh-public-key-authentication/

А если все-таки чуток GUI ?..

Иногда все-таки вознкает необходимость запустить программу с графическим интерфейсом. Одну-одинешеньку, а не весь десктоп. В случае, когда мы с одного компьютера, работающего под управлением Linux, подключаемся по SSH к другому компьютеру, также работающему под управлением Linux, с этим нет никаких проблем. Дело в двух нюансах. Первый — само построение сервера графической подсистемы X-Window, позволяющее сформировать «каартинку» одним Х-сервером, переслать его, например, по сети на другой и воспроизвести уже там. Второй нюанс — SSH-демон поддерживает X-форвардинг (параметр, вкючается в файле настроек sshd). С SSH для Windows мы разобрались выше. Но вот при запуске какой-нибудь GUI-программы в сессии PuTTY мы получаем ообщение о том, что Х-сервер не найден. И это верно — в Windows нет никакого Х-сервера. Надо бы «организовать присутствие»! И в этом нам может помочь еще одна программа — Xming. Сайт проекта — тут, почитать можно (на английском) — тут. Идем, качаем, устанавливаем.

Запускаем Xlaunch («Пуск» -> «Программы» -> «Xming» -> «Xlaunch»). Эта программа настраивает Xming. Настраиваем (в принципе, там все вполне понятно). Единственный нюанс — это раскладки клаватуры. Их параметры задаются дополнительными опциями в одном из окон конфигурирования. Подробнее можно прочесть например тут (ну или же в документации 😉 )…  После настройки запускаем Xming («Пуск» -> «Программы» -> «Xming» -> «Xming»). Единственное, что видим при этом — добавившуюся в трей возле часов иконку программы («сервер» все-таки)…

Теперь нужно настроить X-форвардинг в PuTTY. Для этого запускамем окно кофигурирования PuTTY (если SSH-сеанс был уже запущен, из него обязательно нужно выйти).  В окне Session выбираем и загружаем (кнопкой «Load«) свою сессию. Потом в левой колонке выбираем пункт «X11» (Connection -> SSH -> X11) и там ставим галочку «Enable X11 forwarding» (см. рис. 12 ниже):

putty_x_forvard
Рис. 12. Включение в PuTTY форвардинга X-Window

После этого сохраняем параметры и запускаем сеанс по-новой. В консоли запускаем какую-нибудь программу, имеющую графический интерфейс. Например, если на Linux-компьютере используется графический десктоп KDE, то можно попробовать запустить Konqueror. Вводим с командной строке «konqueror», немножко ждем и наблюдаем:

putty_x_window
Рис. 13 GUI-приложение (Konqueror), запущенное из консоли PuTTY на графический десктоп Windows

Вот и все…

Еще чуток о кракозябрах…

На форуме LinuxForum прочел тему в которой у пользователя возникли вопросы уже, скажем так, по поводу нюансов. Цитирую:

Вопрос скорее относится к рюшечкам, т.к. все функции работают. Есть несколько серверов на SuSE от 9.3 до 10.3 и при работе с ними через Putty при запуске Yast в консольном режиме, вместо псевдографики рисуются буквы (приходится вглядываться, где поле кончается для ввода текста и т.п.). Причем, если запустить mc, то вся псевдографика отображается корректно. Попробовал с одного сервака зайти на другой через ssh — все также отображается корректно, поэтому сделал вывод, что это заморочки либо Putty, либо самого Yast. (Translation в Putty выставлена корректно, русский текст и ввод с клавиатуры — ок)

Решил и я проверить свою Mandriva на это дело. Запустил из Windows коноль в PuTTy, а Xming при этом не запустил. После этого в консоли запустил mcc (Mandriva Control Center — Центр управления Mandriva). Дело в том, что когда нет возможности запустить Центр управления Mandriva в чисто графическом виде (нет «принимающего» X-сервера), он стартует в псевдографике. Оказалось, что и у меня тоже «с буковками вместо границ». Вот так:

wrong_borders_of_mcc
Рис. 14 - Неверное отображение границ в псевдографике

В указанной теме форума присутствовал и вариант решения проблемы:

Это глюк Putty.
Идём в terminal -> Keyboard -> The Function keys and keypads ставим Linux
Идём в Connection -> Data, в графе Terminal-type string пишем linux

Попробовал — действительно границы нарисовало как надо. Однако быстро обнаружились два нюанса. Первый — некорректная работа половины функциональных клавиш. Исправилось простым возвращением значения «xterm» (как собственно и было изначально) для параметра «Keyboard » — «The Function keys and keypads». А вот второй нюанс мое естество так и не смогло «принять»! Дело в том, что совсем по другому стала использоваться мышь. Этот факт я не вынес, и решил, что пусть лучше уж «границы из буковок», но мышь пусть работает «так как было». Поэтому, вернул я назад «xterm» и в параметре «Terminal-type» тоже, созранил настройки и работаю дальше. Хотя, может стоило бы почитать help к программе…

Ну «Secure», так «secure» (часть 2)

В прошлой заметке я уже описал, как боролся с «подбирателями паролей» на моем ssh-демоне. В принципе, я считаю, что принятых мер достаточно для защиты моего сервера (да и кому он надо-то?!). Но, с другой стороны, тысячи строк с сообщением об ошибке в логе авторизации просто «напрягают зрение понапрасну». И вот, просматривая сайт с новостями программного обеспечения, я наткнулся на название программы, которое меня заинтересовало — «Fail2Ban«. Открыл у себя «Центр управления Mandriva Linux», в нем выбрал «Управление программами» и ввел имя программы в поле «Поиск». «Есть у нас такая программа» — сказал поиск. Поставил «птичку», установил. Чем заинтересовала-то меня данная программа? Вот что про нее написано;

Fail2Ban scans log files like /var/log/secure and bans IP that makes too many password failures. It updates firewall rules to reject the IP address. These rules can be defined by the user. Fail2Ban can read multiple log files including sshd or Apache web server logs.

А если вкратце и по русски, программа сканирует логи и динамически меняет правила файервола, запрещая доступ тем IP, с которых происходит слишком много НЕУДАЧНЫХ попыток авторизации (читай, «происходит подбор пароля»)!!! Вот и все!

Остается лишь в качестве подтверждения эффективности программы процитировать два лога. Первый — протокол авторизации в системе (файл /var/log/auth.log):

Jul 25 20:12:31 smb-svr sshd[26144]: Invalid user guest from 61.168.222.170
Jul 25 20:12:31 smb-svr sshd[26144]: error: Could not get shadow information for NOUSER
Jul 25 20:12:31 smb-svr sshd[26144]: Failed password for invalid user guest from 61.168.222.170 port 1652 ssh2
Jul 25 20:12:36 smb-svr sshd[26147]: Invalid user guest from 61.168.222.170
Jul 25 20:12:36 smb-svr sshd[26147]: error: Could not get shadow information for NOUSER
Jul 25 20:12:36 smb-svr sshd[26147]: Failed password for invalid user guest from 61.168.222.170 port 2597 ssh2
Jul 25 20:12:42 smb-svr sshd[26149]: Invalid user guest from 61.168.222.170
Jul 25 20:12:42 smb-svr sshd[26149]: error: Could not get shadow information for NOUSER
Jul 25 20:12:42 smb-svr sshd[26149]: Failed password for invalid user guest from 61.168.222.170 port 3700 ssh2

А второй — протокол работы самой программы (файл /var/log/fail2ban.log):

2008-07-25 20:12:43,045 fail2ban.actions: WARNING [ssh-iptables] Ban 61.168.222.170
2008-07-25 20:22:43,414 fail2ban.actions: WARNING [ssh-iptables] Unban 61.168.222.170

Для «полного понимания» добавлю лишь, что по умолчанию программа:

  • запрещает доступ с IP-адреса после трех неверных попыток ввода пароля;
  • блокирует доступ на 600 секунд.

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

…С тех пор у меня нет в логах авторизации многотысячных записей «Failed password for invalid user...» Чего и вам желаю!,,,

ЗЫ. Балуясь на днях (зкспериментируя) с авторизацией в ssh, заполучил бан самого себя. «Сервер» дома, я на работе, а дела-то не ждут! Пришлось себя срочно «разрешать»… Спас Webmin. У него в разделе «Прочее» есть пункт «Командная оболочка (shell)» (командная строка). Вот в ней-то я и запустил команду:

fail2ban-client status

Сервер fail2ban ответил, что запущен следующий фильтр (Jail): ssh-iptables. Чтобы остановить его, ввел команду:

fail2ban-client stop ssh-iptables

И напоследок, чтобы на будущее меня ни в коем случае не банило, прописал свой рабочий адрес в файл /etc/fail2ban/jail.conf в строке:

ignoreip = 127.0.0.1 XXX.XXX.XXX.XXX

(адреса, когда их несколько, разделяются пробелами)…

Ну «Secure», так «Secure»…

«Сервер» мой домашний — это просто системный блок, лежащий на холодильнике. Ни монитора, ни клавиатуры с мышью к нему не подключено. Все управление своим «сервером» я осуществляю дистанционно по сети. Для этого я установил и настроил службу удаленного доступа — «сервер-NX». Процедура установки и настройки уже описана мной тут. NX-сервер в своей работе использует механизмы службы SSH (secure shell), и поэтому, у сервера запущен демон SSH, который постоянно ожидает соединений на 22 порту. Естественно, с этой же целью в моем ADSL-маршрутизаторе настроен «port forvarding» 22-го порта на мой «сервер» (я им не только из дома, но и с работы «порулить» могу). А с другой стороны «бог даровал» народу всевозможные программы «сканеров портов». И как следствие, периодически кто-то пытается подобрать к моему серверу имя пользователя и пароль, о чем «сервер» мой все четко пишет в файл протокола аутентификации /var/log/auth.log :

Failed password for invalid user bin from XXX.XXX.XXX.XXX port 52100 ssh2
Failed password for invalid user daemon from XXX.XXX.XXX.XXX4.32.126 port 52567 ssh2
Failed password for invalid user sync from XXX.XXX.XXX.XXX port 52610 ssh2
Failed password for invalid user shutdown from XXX.XXX.XXX.XXX port 52676 ssh2
Failed password for invalid user halt from XXX.XXX.XXX.XXX port 52728 ssh2
Failed password for invalid user uucp from XXX.XXX.XXX.XXX port 52777 ssh2
Failed password for invalid user smmsp from XXX.XXX.XXX.XXX port 53021 ssh2

Причем, число подобных строк в протоколе может достигать нескольких тысяч за час (неймется им!). «Хорошая» штука — сканер портов. Без нее у «гражданина-хакера» уже все пальцы «в дым стерлись бы»!.. А так — сиди, чай попивай!..

Получится ли у «хакера» войти в мой «сервер» или нет — это еще вопрос. Но, как говорится, «береженого бог бережет». Чтож, будем защищаться! В принципе, у SSH существует сравнительно простой способ напрочь забыть о таких «взломщиках». Для этого нужно просто настроить доступ к серверу по SSH-ключу, и полностью отключить возможность входа по паролю. Ключ может быть длинный, например, 2048 байт, и подобрать его будет, мягко говоря, затруднительно. Как настроить службу SSH, подробно описано на вот этой странице, и дублировать тут ее целиком я не вижу смысла. Если вкратце, то лично я, руководствуясь информацией с этой страницы, находясь в консоли той клиентской машины и с правами того пользователя, для которых настраиваем доступ к серверу по ключу, выполнил всего две команды. Сначала я выполнил следующее:

ssh-keygen -t rsa -b 2048

Данная команда сначала спрашивает имя файла ключа (используем значения, предложенные по умолчанию), потом предлагает ввести дополнительный пароль (passphrase) для ключа (это повышает безопасность, но потом пароль нужно будет вводить все время), и затем создает пару ключей (приватный и публичный) в папке $HOME/.ssh/ на клиентской машине. Именно эти ключи и будут в дальнейшем использоваться вместо пароля при идентификации пользователя на сервере. После этого, перейдя в папку $HOME/.ssh/ я выполнил вторую команду:

ssh-copy-id -i id_rsa.pub dmitry@myserver

Эта команда сперва спрашивает пароль пользователя на сервере, а затем копирует публичный ключ (файл id_rsa.pub) в папку указанного пользователя на указанный сервер (естественно, вместо «dmitry» Вы подставляете свое имя пользователя, а вместо «myserver» имя своего сервера). После этого проверяем возможность беспарольного входа — в консоли клиентской машины вводим команду:

ssh dmitry@myserver

Результат успешного выполнения данной команды — вы входите в консоль сервера, не вводя никаких паролей. После этого можно в SSH отключить возможность доступа по паролю — в файле /etc/ssh/sshd_config сервера строку «PasswordAuthentication yes» заменить на «PasswordAuthentication no«. Учтите, что после внесения изменений в конфигурацию сервера, его нужно перезапустить. После этого сканеры портов не смогут подбирать пароль к Вашему компьютеру по той простой причине, что доступ по паролю будет отключен!

И все было бы хорошо, если бы не одно «но». После таких манипуляций становится невозможным вход в сервер при помощи NX! Об этом, кстати, четко сказано в документации к NX-серверу — «работа службы в случае запрета SSH-доступа по паролю невозможна». Читаем мы, правда, обычно уже «потом»… Честно говоря, поначалу я был удивлен. Еще при настройке сервера NX я видел, что им при аутентификации используется не пароль, а публичный ключ. Понимание того, «почему нельзя», пришло после прочтения все того же файла протокола аутентификации в начале NX-сессии. В нем мы видим следующие три строки:

Accepted publickey for nx from 192.168.1.15 port 3640 ssh2
Accepted password for dmitry from 127.0.0.1 port 45410 ssh2
Accepted publickey for dmitry from 127.0.0.1 port 45411 ssh2

Как мы видим в приведенном фрагменте лога, ИЗВНЕ в сервер входит не пользователь «dmitry«, а пользователь «nx«. Причем, входит не по паролю, а по ключу (тому самому, который и «длинный», и «трудно подбираемый»). А вот имя пользователя (в моем случае — «dmitry«) и пароль (как следует из второй приведенной строки), используется уже для запуска сессии только ВНУТРИ сервера.

Что нам это дает? Во-первых, понимание того, что доступ по паролю все-таки нужно включить обратно. А то «кина не будет»!… Поэтому, в файле /etc/ssh/sshd_config сервера снова возвращаем на место строку «PasswordAuthentication yes» (аутентификация по паролю разрешена). Не забываем при этом перезапустить сервер. Выходит, что мы вернулись к тому, с чего начинали! Но, у SSH есть еще одна возможность — управление доступом пользователей. Причем, с учетом адреса(ов) машин(ы), с которой(ых) данный пользователь пытается получить доступ к серверу. Каким образом мы можем это использовать? Возьмем всё тот же файл конфигурации демона SSH (/etc/ssh/sshd_config), и впишем в него следующие строки:

AllowUsers nx
AllowUsers dmitry@127.0.0.1

А теперь о том, что это строки обозначают. И начнем со второй строки. В ней указано, что пользователю «dmitry» разрешен вход в сервер ТОЛЬКО ЛИШЬ С ВНУТРЕННЕГО АДРЕСА «127.0.0.1» (того, что указан после «собаки»). И ни с каких других! Кстати, вместо конкретного адреса может быть указан шаблон, например, «192.168.0.*» (вся локальная сеть). А теперь вернемся к первой строке — она разрешает доступ к серверу пользователю «nx«. Причем, так как в ней нет никаких указаний адресов после «собаки», то данному пользователю доступ разрешен с ЛЮБОГО адреса. И еще один нюанс — сам факт наличия в конфигурации SSH-сервера пользователей, разрешенных директивой «AllowUsers«, обозначает, что всем другим доступ к серверу ЗАПРЕЩЕН!

Если быть более точным, то директив, управляющих доступом по SSH четыре: DenyUsers (запрещенные пользователи), AllowUsers (разрешенные пользователи), DenyGroups (запрещенные группы), и AllowGroups (разрешенные группы). До тех пор, пока в конфигурации демона SSH нет ни одной из этих директив, доступ разрешен ВСЕМ. Наличие ЛЮБОЙ из указанных директив будет ограничивать доступ соответствующим образом. В случае использования НЕСКОЛЬКИХ (или всех) указанных директив порядок проверки будет следующим: DenyUsers, AllowUsers, DenyGroups, и наконец AllowGroups.

В итоге, указавши двух пользователей как приведено выше, мы получили следующее — ИЗВНЕ в наш сервер может войти только лишь один пользователь «nx«. Войдя в сервер, пользователь «nx» запускает уже ЛОКАЛЬНУЮ (с адреса 127.0.0.1) сессию пользователя «dmitry«, который хоть и аутентифицируется по паролю, но уже ВНУТРИ сервера …

Таким образом, сейчас тому, кто захочет войти в мой «сервер» понадобится всего лишь подобрать публичный ключ. Тот, который длинной 2048 бит… Кому не лень, пусть подбирает!

ЗЫ. Если же для «себя любимого» (или другого пользователя) нужно оставить и возможность входа в Secure Shell (SSH), то во все тот же файл конфигурации демона SSH (/etc/ssh/sshd_config) нужно вписать соответствующие «разрешающие» строки с указанием адреса(ов) компьютера(ов), с которых необходимо разрешить доступ. Например вот так:

AllowUsers dmitry@91.121.15.100

(разрешает доступ пользователю «dmitry» с компьютера с адресом «91.121.15.100«). Или, например, вот так для всей подсети (внутренней):

AllowUsers dmitry@192.168.0.*