С помощью защищенного протокола SSH администраторы подключаются к своим серверам для безопасной работы. Рассмотрим особенности этого протокола подробнее:
Что такое SSH-протокол
SSH-протокол (от англ. Secure Shell ) - криптографический сетевой протокол, предназначенный для удаленного доступа к операционной системе и осуществления безопасного удаленного управления в рамках незащищенной сети (например, через интернет).
SSH обеспечивает защищенный канал связи между клиентом и сервером, через который можно передавать данные (почтовые, видео, файлы), работать в командной строке, удаленно запускать программы, в том числе графические. SSH-сервер должен быть установлен на удаленной операционной системе. SSH-клиент должен быть запущен на машине, с которой будет осуществляться удаленное подключение.
Основные функции, доступные при использовании SSH-протокола:
- Передача любых данных через защищенное SSH-соединение, включая сжатие данных для последующего шифрования.
- X11 Forwarding - механизм, позволяющий запускать программы UNIX/Linux-сервера в виде графической оболочки, как в Windows (использовать X Window System).
- Переадресация портов - передача шифрованного трафика между портами разных машин.
Безопасность SSH-соединения обеспечивается:
- шифрованием данных одним из существующих алгоритмов
- аутентификацией сервера и клиента одним из нескольких доступных методов
- наличием дополнительных функций протокола, направленных на предупреждение различных хакерских атак
Аутентификация сервера дает защиту от:
- взлома путем подмены IP-адресов (IP-spoofing), когда один удаленный хост посылает пакеты от имени другого удаленного хоста
- подмены DNS-записей (DNS-spoofing), когда подменяется запись на DNS-сервере, в результате чего соединение устанавливается с хостом, который указан в подмененной записи, вместо необходимого
- перехвата открытых паролей и других данных, передаваемых в открытом виде через установленное соединение
На сегодняшний день существуют две версии протокола SSH (SSH-1 и SSH-2), причем вторая версия усовершенствована и расширена по сравнению с первой. Например, вторая версия устойчива к атакам вида MITM («человек посередине», атака посредника). Также существуют две редакции данного протокола: открытая версия (бесплатная) и коммерческая (платная). Бесплатная версия - OpenSSH - встроена во все UNIX-подобные операционные системы в виде стандартных утилит SSH-клиента и SSH-сервера.
Коммерческая реализация SSH-протокола - SSH Communications Security - разработана одноименной организацией. Имеет небольшие отличия от бесплатной версии, такие как доступность коммерческой технической поддержки, наличие инструментов веб-управления и др. Основной набор команд и возможностей практически одинаковый у обоих продуктов.
Для ОС Windows выпущены различные SSH-клиенты и оболочки, самые распространенные из них - это бесплатные PuTTY и WinSCP . Для других операционных систем также существуют свои SSH-клиенты.
Что такое SFTP-протокол
SFTP-протокол (от англ. SSH File Transfer Protocol ) – сетевой протокол прикладного уровня, предназначенный для передачи файлов и других действий с ними через имеющееся надежное соединение. Протокол был разработан как расширение SSH-2, предназначенное для операций с файлами по защищенному каналу, однако может работать и с другими протоколами, обеспечивающими безопасное соединение сервера с клиентом. Иными словами, для надежной работы через SFTP-протокол необходимо иметь установленное защищенное соединение (например, SSH), которое проводит аутентификацию клиента и сервера и устанавливает факт их надежности, поскольку сам SFTP-протокол не проводит аутентификацию и не обеспечивает безопасность.
SFTP имеет ряд преимуществ перед своими предшественниками - FTP и SCP - таких, как прерывание передачи файла, удаление, возобновление передачи, связь переданных файлов с основными атрибутами, например, меткой даты/времени, а также более высокая платформонезависимость.
SFTP-протокол реализуется через SFTP-сервер и SFTP-клиент, которые являются подсистемами OpenSSH.
Для чего используются SSH и SFTP протоколы
Чаще всего протоколы SSH и SFTP используются для удаленной работы с операционной системой или переноса большого количества файлов.
Например, клиент берет в аренду сервер или какую-то часть серверного пространства. Возникает необходимость переносить туда уже имеющиеся данные клиента, например, сайт или почтовые файлы. Провайдер должен обеспечить надежность и быстроту обмена данными с его сервером, особенно если речь идет о больших объемах информации и ее высокой конфиденциальности. В этом случае на удаленной машине (в данном случае - виртуальном сервере) устанавливается SSH-сервер (со встроенным SFTP-протоколом), а на клиентском компьютере - SSH-клиент. Создается SSH-туннель, и обмен данными между клиентом и удаленным сервером осуществляется через надежное соединение со всеми преимуществами протокола, описанными выше.
Также SSH может использоваться для удаленной работы по защищенному соединению с различными сервисами провайдера, такими как программное обеспечение, операционные системы и т.д.
Как работает SSH
По протоколу SSH работает набор программ, служащих для выполнения различных действий на удаленной операционной системе. Например, программа sshd обеспечивает серверную функциональность SSH, она должна быть запущена на SSH-сервере. Программа ssh запускается на SSH-клиенте и позволяет устанавливать соединение с удаленным хостом, регистрироваться на нем, работать с удаленной машиной через SSH-соединение.
Для запуска тех или иных программ SSH-протокола существуют специальные команды с набором различных опций. Эти команды могут отличаться в зависимости от используемой клиентской операционной системы и оболочки SSH-клиента. Команды запускаются либо из командной строки, если речь идет о UNIX-подобных системах, либо посредством графического интерфейса в соответствующих SSH-оболочках.
Как подключиться по SSH
Если на вашем компьютере установлена ОС Windows, а на удаленной машине UNIX-подобная система (например, Linux), то для установки SSH-соединения можно использовать PuTTY . Это бесплатная программа под Windows состоит из одного запускаемого файла и не требует инсталляции.
Чтобы установить соединение при помощи PuTTY, необходимо проделать следующие действия.
Запустить PuTTY (putty.exe).
По умолчанию никаких дополнительных настроек проводить не нужно, можно убедиться, что указан 22-й порт и тип соединения Connection type - SSH. В поле Host Name (or IP address) нужно ввести имя удаленного компьютера или его IP-адрес и нажать кнопку Open .
Может появиться предупреждение системы безопасности PuTTY, однако если есть уверенность в том, что хост достоверен, то нужно нажать Да и продолжить соединение.
В появившейся командной строке нужно ввести имя пользователя, под которым будет выполняться вход на удаленный компьютер.
В следующей строке нужно ввести пароль для данного пользователя. При вводе пароля никакие символы в командной строке не отображаются, поэтому необходимо просто набрать пароль и нажать клавишу ввода (Enter). Если введены неправильные имя пользователя и пароль, то выведется ошибка « Access denied », в случае успешного подключения предоставляется командная строка удаленного компьютера.
В этой статье мы рассмотрим современные и удобные способы работы с сервером по SSH с VPS от Infobox и облаком .
Мы расскажем не только про обычный способ подключения, но и про организацию устойчивого соединения через нестабильный интернет (например 3G модемы), а также о дополнительных утилитах, помогающих в работе по SSH.
Если вы пользователь Windows и вам нужно просто и быстро подключиться к Linux–серверу - переходите в раздел «Putty или как быстро подключиться к SSH из Windows».
Что необходимо знать для подключения по SSH
Для подключение необходимы:- IP адрес сервера
- логин
- пароль
Где взять данные для подключения к серверу VPS NG от Infobox
После заказа услуги войдите в панель управления https://panel.infobox.ru .Выберите услугу «VPS NG» в правом верхнем углу панели управления в выпадающем списке.
Затем перейдите во вкладку «VPS».
В этом разделе вы увидите ip-адрес сервера и можете установить пароль для доступа к серверу .
Для подключения используйте имя пользователя root
, ip–адрес
с этой страницы и установленный пароль
.
Если вы забыли пароль, нажмите на пункт «Редактировать параметры доступа», показанном на скриншоте выше.
Где взять данные для подключения к серверу VPS от Infobox
Войдите в панель управления https://panel.infobox.ru .Выберите услугу VPS в правом верхнем углу панели управления в выпадающем списке (в названии услуга содержит имя заказанной ОС и регион размещения).
Затем перейдите во вкладку «Управление VPS».
Используйте имя пользователя root
, пароль и ip–адрес сервера с этой страницы.
Где взять данные для подключения к серверу InfoboxCloud
После создания сервера данные для подключения придут к вам на электронную почту. Этого достаточно для подключения.
Если вы потеряли письмо с данными для доступа и хотите получить доступ к серверу
По-умолчанию логин администратора сервера: rootВойдите в панель управления по адресу: https://panel.infobox.ru .
Выберите услугу «Облачные серверы» в правом верхнем углу панели управления в выпадающем списке.
Выделенный IP–адрес для сервера можно посмотреть во вкладке «Облачная инфраструктура» панели управления.
Если поле "Выделенный IP адрес " пустое, значит при создании сервера вы не добавили серверу хотя бы 1 выделенный ip–адрес (и следовательно доступа через Интернет к серверу нет, есть только из локальной сети).
Чтобы добавить выделенный IP–адрес, нажмите на имя сервера.
В группе настроек «Сеть» нажмите «Настроить».
Убедитесь, что пропускная способность (скорость) сети достаточна (или поставьте больше при необходимости).
Затем нажмите «Добавить IPv4–адрес» и нажмите «Сохранить изменения».
Теперь у сервера есть выделенный IP–адрес.
Для изменения пароля доступа к серверу нажмите «Изменить», как показано на скриншоте выше. Так вы можете установить пароль для доступа к серверу.
Теперь вы знаете ip–адрес сервера
, логин (root
) и пароль
.
Настройка SSH–клиентов
Для Windows
Для подключения к серверу вам потребуется SSH–клиент. Если необходимо быстро подключиться - рекомендуется Putty . Если требуется работа с unix–утилитами, такими как scp, rsync и ssh-copy-id – используйте Cygwin .Putty или как быстро подключиться к SSH из Windows
Скачайте инсталлятор Putty для Windows из раздела The latest release version и установите Putty с настройками по-умолчанию.
Запустите Putty (Пуск -> Все приложения -> PuTTY -> PuTTY).
Введите IP–адрес сервера. Убедитесь, что выбран порт 22, а тип подключения SSH и нажмите «Open».
Вам будет задан вопрос, доверяете ли вы серверу, к которому подключаетесь. Нужно ответить «Да».
Откроется окно подключения. В качестве логина используйте root, в качестве пароля - ваш пароль от сервера. Пароль можно вставить из буфера обмена правой кнопкой мыши. Он не отображается при вводе и вставке в целях безопасности.
Подключение было успешно установлено.
Cygwin или Unix–окружение на вашем Windows компьютере
Работая с Linux–серверами вам может понадобиться подобное окружение на вашем компьютере. Использовать единый набор утилит на сервере и рабочем компьютере очень удобно, поэтому обязательно попробуйте Cygwin. Linux только с первого взгляда кажется сложным. Постепенно осваивая эту ОС вы все больше будете нуждаться в Cygwin. Хорошее затягивает.Нестабильное интернет-соединение при подключении по SSH – что делать?
Часто, работая через нестабильную сеть (например через мобильный интернет 3G/4G или различные точки доступа WiFi) соединение с SSH обрывается. Давайте посмотрим, что можно сделать на уровне клиента, чтобы предотвратить необходимость переподключения. Данные инструменты не подходят для выполнения критически важных операций на сервере (например апгрейд ОС). Для выполнения критически важных операций нужно дополнительно использовать утилиты, описанные в следующем разделе статьи. Предназначение утилит в этом разделе - более удобная работа по SSH для пользователя.AutoSSH
AutoSSH запускает копию ssh–клиента и осуществляет мониторинг за соединением, перезапуская ssh–клиент при необходимости.Autossh использует ssh для построения петли ssh–перенаправлений (соединение с локального компьютера на удаленный и в обратном направлении) и пересылает тестовые данные, ожидая, что они вернутся назад. Также поддерживается использование удаленного эхо-сервиса для отправки назад тестовых данных.
AutoSSH поддерживает только 3 параметра:
- -M <порт>[: эхо-порт] - используется для указания порта мониторинга или порта мониторинга и порта эхо-сервиса. Если не указан порт эхо-сервиса, для него используется следующий по номеру порт. Например, если установлен флаг -M 20000, тестовые данные будут отправляться по порту 20000, а получаться по порту 20001. Если указать -M 0 – мониторинг соединения будет отключен и autossh будет перезапускать ssh только при выходе из ssh (можно использовать это с опциями ServerAliveInterval и ServerAliveCountMax в OpenSSH, если мониторинг в вашей ситуации не может быть использован);
- -f - отправляет autossh в фон еще до запуска ssh (пароль в таком режиме ввести вы не сможете);
- -V - отображает версию autossh.
Для того, чтобы при восстановления соединения вам не пришлось вводить пароль повторно, разрешите для данного пользователя вход на сервер по ключу, как показано в разделе выше.
Установка AutoSSH в Cygwin в Windows
При использовании Cygwin в Windows введите:apt-cyg update
apt-cyg install autossh
Теперь можно выполнить подключение к серверу:
autossh -M 20000 root@ip_адрес_сервера
Соединение успешно установлено.
В целом autossh – достаточно удобный инструмент для работы через нестабильные интернет-соединения и для организации ssh–туннелей на сервере (этот сценарий мы рассмотрим в отдельной статье). Недостаток autossh в том, что эта утилита не решает проблему, если в момент ввода команд на сети возникают значительные задержки (что в 3G сети случается). В этом случае вы будете ждать ответа от сервера на ввод каждого символа, что несколько замедляет работу. Тем не менее в обычных условиях работы autossh очень помогает поддерживать ssh–соединение.
Возможность вводить команды не дожидаясь ответа сервера решает Mosh , но совместимость этой утилиты пока сильно ограничена, а надежность невысока, поэтому пока использовать ее не рекомендуется.
Как выполнять критически важные и длительные операции на сервере: терминальные мультиплексоры
Если вы обновляете ОС, устанавливаете какое-то ПО или просто редактируете файл на сервере, после подключения через ssh или autossh не работайте напрямую. Если соединение по SSH будет разорвано - вы потеряете сессию, запущенную при подключении по SSH. Чтобы этого не произошло и при переподключении по SSH вы точно попали в продолжающуюся операцию на сервере или в открытое окно редактирования файла с того же момента, используйте на сервере терминальные мультиплексоры: GNU Screen или tmux .GNU Screen
Изначально программа screen создавалась, чтобы запускать несколько терминальных сессий внутри одного терминала. Однако есть у screen и другое полезное свойство: возможность отсоединять виртуальные сеансы от физического терминала и подсоединять к другому. Это, в частности, позволяет запускать долгоиграющие процессы на удалённых машинах, без необходимости быть постоянно на них залогиненным.1. Зайдите на удаленный сервер по SSH.
2. Запустите там screen
3. Вы увидите приветствие, нажмите Enter.
4. Теперь вы можете делать что угодно, как будто вы просто подключены к серверу по SSH (например запустите любой долгий процесс).
5. Вы можете отсоединить сессию, нажав CTRL + a, затем d. Можете даже завершить подключение по SSH к серверу.
6. Чтобы вернуться в сессию, переподключитесь по SSH (или это сделает autossh) и введите screen -r
Вы вернетесь в запущенную сессию, а в ней продолжается запущенный вами процесс ранее. Более подробно терминальные мультиплексоры мы разберем в последующих статьях.
Заключение
В этой статье мы попытались рассказать основы, необходимые для удобной работы по SSH из различных ОС. Конечно это далеко не все, что возможно, но хорошая база для начала. Если вы нашли ошибку в статье, считаете, что нужно добавить что-то важное или просто у вас есть вопрос -SSH (Secure Shell) - это сетевой протокол удаленного доступа, использующий шифрование и сжатие для передаваемых данных. Проще говоря - это весьма полезный и мощный инструмент, позволяющий аутентифицироваться в системе и полноценно работать от имени локального пользователя, находясь за много километров от работающей машины. Также, в отличие от telnet и rsh - SSH шифрует весь трафик, так что вся переданная информация остается конфиденциальной.
Итак, ssh у нас уже установлен и ssh-daemon добавлен в автозагрузку при старте системы. Управлять им можно по команде:
service ssh stop|start|restart
В Ubuntu, или:
/etc/init.d/ssh {start|stop|reload|force-reload|restart|status}
В Debian, или:
systemctl start|stop|restart sshd.service
В ArchLinux (после каждой правки конфига нужно делать рестарт). В комплект входит клиент и сервер.
Опробуем в деле! Для начала создайте папку ~/.ssh
mkdir ~/.ssh
Сгенерируйте ключи для данного пользователя сервера командой:
ssh-keygen (от имени обычного пользователя).
При генерации, вы можете задать парольную фразу для ключа (желательно задать, и длинную - тогда даже заполучив ключ но не зная пароль от ключа, злоумышленник не сможет залогинится), а можете пропустить, просто нажав "Enter" - в таком случае, пароль никогда не спросится. В папке ~/.ssh появились те самые публичный и закрытый ключ.
Найдите ещё одну машину (даже смартфон подойдет - на Android есть несколько замечательных SSH-клиентов, вроде ConnectBot или JuiceSSH), установите на ней ssh и подключитесь к серверу командой:
ssh user@server
Если всё сделано правильно, будет запрошен пароль пользователя, и после ввода вы окажетесь в своей системе с видом из командной строки.
Для Windows, к слову, также есть сервера и клиенты ssh.
Насладившись результатом трудов своих, приступим к ещё более скучной части - настройке клиента/сервера.
Конфиг клиентской части лежит в /etc/ssh/ssh_config , а серверной - /etc/ssh/sshd_config . Наиболее полным руководством по настройке является, пожалуй, страница в man - man ssh и man sshd_config, так что рекомендуем прочититать её. А в данной статье рассмотрим наиболее необходимые вещи.
Настройка
Стандартный порт ssh - 22. Его можно сменить на любой нестандартный (усложняя возможный взлом благодаря безопасности через неясность, или же для привлечения внимания потенциальных взломщиков:) - для этого расскомментируйте строчку:
#Port 22
И добавьте любой желаемый до 65535 (убедившись, что порт не конфликтует с другими сервисами командой #netstat -tupln | grep LISTEN ).
Теперь при подключении к серверу, клиенту потребуется писать с ключом:
ssh -p [порт] :
По умолчанию доступ от имени root разрешен. Крайне желательно ограничить его (и вместо этого правильно разграничить права локального пользователя с помощью sudo). Для этого найдите строчку "PermitRootLogin" и смените значение на "no". Можно также сменить на "without-password" - в таком случае, логин под рутом будет разрешен только из под машин с доверенным ключом.
Можно отключить аутентификацию по паролю и работать только с ключами - найдите строчку: "PasswordAuthentication" и смените значение на "no". Зачем? Если кто-то очень захочет получить доступ к вашей системе, то он сможет либо перебрать пароль при попытках авторизации, либо прослушать и расшифровать ваше соединение. Если отключить аутентификацию по паролю и добавить в ~/.ssh/authorized_keys на сервере публичный ключ своего, например, рабочего ноутбука, то, как мы помним, нас пустит на сервер сразу. Но как быть, если вы работаете на чужой машине и срочно нужно получить доступ на ssh-сервер, а он нас ожидаемо не пускает? Тогда можно не отключать парольную аутентификацию, а воспользоваться утилитой fail2ban. Просто установите её из вашего репозитория, после чего она применит настройки по умолчанию и, как минимум, защитит ваш ssh-канал от взлома методом перебора. Подробнее о fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.
На тот случай, если на вашем сервере хранятся ключи запуска ядерных ракет, то можно сделать как-то так:
PermitRootLogin no - запрещен логин под рутом.
PasswordAuthentication no - вход без пароля
Сгенерируем на удаленной машине длинный ключ (-t тип_шифрования, -b битовая длина):
ssh-keygen -t rsa -b 4096
С не менее сложной парольной фразой (восстановить забытый пароль, к слову, нельзя. Можно сменить его командой "ssh-keygen -p", но с вас в любом случае спросят старый). Перенесем публичный ключ удаленной локальной машины в ~/.ssh/authorized_keys сервера, и вуаля - теперь доступ можно получить с единственной машины, с помощью парольной фразы зыкрытого ключа. SSH позволяет настроить множество конфигураций безопасности и имеет для этого множество специфичных настроек - о них читайте в man.
Этим же целям служат два параметра sshd_config:
LoginGraceTime - задает время, по истечении которого будет разорвано соединение, если не произойдет аутентификация.
MaxAuthTries - задает количество неверных попыток ввода логина, по достижении которого соединение будет разорвано.
MaxSessions - количество одновременных сессий (если сервер - ваш домашний компьютер, к которому вы собираетесь подключаться из универа или с работы, то разумно будет ограничить число сессий до одной - отклоненный логин, в таком случае, станет поводом для повышения паранойи, генерации новых ключей и смены пароля). Впрочем, если вы внимательны, то могли заметить, что при каждом логине на сервер высвечивается строчка "Last Login". Помимо неё, можно добавить собственное приветственное сообщение - найдите строчку "Banner" и вместо none задайте путь к файлу с текстом, который будет прочитан и выведен при логине.
Помимо прочего, можно разрешить вход в систему только определенным пользователям, или разрешить всем, помимо определенных пользователей:
AllowUsers user1 - разрешить вход только user1.
DenyUsers user1 - разрешить всем, кроме user1.
И аналогичные параметры для доступа определенных групп - AllowGroups и DenyGroups.
Также по SSH можно передавать сеанс X11. Для этого найдите строчку "ForwardX11" и измените значение на "yes".
Аналогичную строку найдите в конфиге клиента - /etc/ssh/ssh_config, и также смените на "yes".
Теперь присоединяться к серверу по ssh нужно с аргументом -X:
ssh -X user@server>
Можно сразу запуcтить приложение при коннекте:
ssh -X user@server "приложение"
Вот так выглядит работающий GIMP в ssh-сессии:
Или можно получить вывод с веб-камеры ноутбука ничего не подозревающего пользователя:)
Вычисления производятся непосредственно на сервере, а вывод передается на клиентскую машину (то есть, даже если на самом сервере не стоят X11, графические приложения можно отрисовывать на вашей удаленной машине). Работает такая схема довольно медленно (не забываем, что весь трафик динамически шифруется) - но функция эта весьма полезна.
По SSH-сессии можно также копировать файлы - для этого есть простенькая утилита "scp". Передавать файлы можно прямо в сессии как с сервера на клиент:
scp user@server:/путь/к/файлу/на/сервере /куда/сохранить/на/локальной/машине
Так и с клиента на сервер:
scp путь/к/файлу/клиента user@server:/путь/на/сервере
Это достаточно удобно, если нужно скопировать текстовик или фотографию, но как быть, когда предстоит работа с многими файлами? Для этого существует удобнейшая вещь - sshfs (доступна для установки в репозиториях большинства *nix-систем).
Просто задайте путь аналогично scp:
sshfs user@server:/home/user /mnt/
И папка /home/user сервера появится в точке монтирования /mnt локальной машины!
Отмонтирование производится через umount.
И, напоследок, расскажем об одной малоизвестной фиче. Если создать файл /.ssh/config и заполнить его подобным образом:
Host [имя]
Hostname
User [имя пользователя сервера]
желаемые опции
вроде
ForwardX11 yes
Port 30000
То можно будем логиниться по:
ssh [имя]
ssh -X -p 30000 user@server
И все опции подхватятся автоматически. Таким образом, при частой аутентификации на определенном сервере, вы упростите этот процесс к делу пары мгновений.
Что ж, мы рассмотрели всё (и даже больше) что нужно знать об SSH, для его бытового использования - научились пользоваться аутентификацией по ключу, защитили сервер от взлома перебором и в целом, наложили заплатки на большинство потенциальных дыр. На самом деле, SSH может ещё много разных штук - например, туннелирование и проброс портов через ssh-сессию, но вряд ли вы, как самый обычный пользователь, когда-либо этим воспользуетесь. Дополнительные ресурсы
SSH (Secure Shell) — это сетевой протокол, предназначенный для удалённого управления сервером и передачи данных по зашифрованным TCP соединениям. Большинство хостингов , даже виртуальных, сегодня предоставляет доступ как по FTP, так и по SSH. На мой взгляд, это здорово, SSH намного удобнее и безопаснее в использовании.
Настройка SSH
Настройка будет происходить под выделенный сервер, VDS, VPS на Debian, Ubuntu. Конфигурационный файл располагается тут: /etc/ssh/sshd_config .
Если у вас обычный хостинг, всё и так должно быть настроено как надо, переходите к разделу .
По умолчанию, демон SSHD (именно в него мы вносим изменения) не нуждается в каких-либо настройках и работает нормально. Мы внесём лишь пару небольших изменений с целью ограничить доступ нежелательных лиц к серверу.
В результате внесения неправильных изменений в конфигурационный файл вы можете потерять доступ к серверу по ssh, поэтому убедитесь, что у вас есть альтернативные варианты для доступа к нему, например, с помощью панели управления ISPManager.
Как ограничить доступ по SSH
Все изменения вносятся в /etc/ssh/sshd_config
Чтобы изменения вступили в силу, необходимо
Сменить порт
Port 9724Теперь при авторизации вам нужно вместо стандартного 22 порта указывать 9724 .
Способ очень простой и действенный против большинства простых ботов хакеров, которые стучатся в стандартные порты. Тут главное не создать конфликт с другими службами и подобрать заведомо неиспользуемое число.
Запретить связь по старому протоколу
Здесь мы определяем, что связь возможна только по протоколу v2
Если вы авторизованы не под root , перед всеми консольными командами нужно добавлять sudo — расшифровывается как Substitute User and DO — подмени юзера и делай (под ним). Например, позволяет исполнять команды от имени суперпользователя root .
Уменьшить число попыток авторизации
MaxAuthTries 2Количество попыток ввода пароля. По умолчанию 6. При неудачном переборе сеанс связи обрывается.
Уменьшить время ожидания авторизации
LoginGraceTime 30sПо умолчанию, 120 секунд может длиться сеанс авторизации. По истечению этого времени он обрывается. 2 минуты на авторизацию — это перебор, всё это время сервер держит связь открытой, что очень нерационально. Полминуты за глаза хватит.
Закрыть доступ по IP
Если доступ нужен только вам, самым простым и надёжным будет закрыть доступ отовсюду, кроме вашего IP или, если он динамический, то диапазона IP.
- Открываем /etc/hosts.allow и добавляем туда
SSHD: 192.168.1.1
где 192.168.1.1 — ваш IP. Если у вас динамический IP, определите IP с маской подсети и запишите Вашу подсеть вместо IP, например:
SSHD: 192.168.0.0/16
- Открываем /etc/hosts.deny и добавляем туда: SSHD: ALL
Ещё один способ ограничения доступа по IP
Можно воспользоваться следующей директивой:
AllowUsers = *@1.2.3.4
Здесь мы разрешаем доступ только для IP 1.2.3.4
Авторизация SSH по ключам
Намного безопаснее, удобнее и правильнее будет настроить ssh авторизацию без пароля. Для этого будет использоваться авторизация по ключу.
Итак, вот инструкция:
Подключение настроено. Если что-то сделали не так, при авторизации появится ошибка Server refused our key , то есть Сервер не принял наш ключ . В этом случае пройдитесь по всем пунктам последовательно и поищите ошибку
Эта статья помечена как незаконченная. См. заметку в конце статьи.
Данная статья посвящена клиенту и серверу защищенного терминала (secure shell) в Ubuntu, их настройке и использованию. SSH - это специальный сетевой протокол, позволяющий получать удаленный доступ к компьютеру с большой степенью безопасности соединения. Более подробно про протокол ssh можно прочитать .
Описание принципов работы и используемых приложений
В основном, SSH реализован в виде двух приложений - SSH -сервера и SSH -клиента В Ubuntu используется свободная реализация клиента и сервера SSH - OpenSSH . При подключении клиент проходит процедуру авторизации у сервера и между ними устанавливается зашифрованное соединение. OpenSSH сервер может работать как с протоколом ssh1, так и с протоколом ssh2. В настоящее время протокол ssh1 считается небезопасным, поэтому его использование крайне не рекомендуется. Я намеренно опускаю различные технические подробности работы протокола, т. к. основной целью данного руководства является описание его настройки и использования. Про сам протокол, принципы его работы, алгоритмы шифрования и т. д. существует множество статей в интернете, например подробно про это можно почитать .
Установка
Установить OpenSSH можно из терминала командой:
sudo apt-get install sshВ метапакете ssh содержится как клиент, так и сервер, но при этом, скорее всего, будет установлен только сервер, т. к. клиент уже есть в Ubuntu по умолчанию.
Настройка сервера
При установке SSH -сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:
sudo service ssh stop| start| restartОсновной файл конфигурации SSH -сервера - файл /etc/ssh/sshd_config , доступный для чтения или редактирования только суперпользователю . После каждого изменения этого файла необходимо перезапустить ssh-сервер для применения таких изменений.
Пример конфигурации SSH -сервера в Ubuntu по умолчанию :
# Пример конфигурации open-ssh сервера с русскими # # комментариями..2010. # # # # # # Условные обозначения: # # Под "по умолчанию" - подразумевается поведение sshd при # # неуказанной явно директиве. Стоит заметить, что в Ubuntu # # файл sshd_config уже содержит ряд настроек, которые # # являются настройками по умолчанию для именно для Ubuntu. # # Такие настройки указаны в этом файле. # # # ############################################################ ################ Настройки адресов/портов и т.д. ########### ############################################################ # # ## Port #################################################### # # # Используемый порт. Можно указывать несколько, например: # # Port 22 # # Port 23 # # Port 24 # # Рекомендуется использовать нестандартный порт, т.к. # # стандартный часто сканируется ботами на предмет # # потенциальных "дырок". Может быть опущен, если задан # # через адрес. См. также параметр ListenAddress. # # # Port 22 # # ## ListenAddress ########################################### # # # Сетевой адрес, на котором "слушает" сервер. Адрес можно # # записывать так: # # ListenAddress host|IPv4_addr|IPv6_addr # # ListenAddress host|IPv4_addr:port # # ListenAddress :port # # Если порт не задан, sshd будет слушать на этом адресе и # # на порту, указанному в опции Port. Если вы будете # # использовать ListenAddress не указывая порт, то опция # # Port должна предшествовать опции ListenAddress. Если не # # указывать, то по умолчанию слушает на всех локальных # # адресах. Можно указывать несколько адресов. # # # ## AddressFamily ########################################### # # # Указывает, какое семейство IP адресов должно быть # # использовано sshd. Возможные варианты: # # “any” - любые # # “inet” (только IPv4) # # “inet6” (только IPv6) # # По умолчанию - “any”. # AddressFamily inet # # ## UseDNS ################################################## # # # Указывает, должен ли sshd проверять имя хоста и # # используя это имя сверять IP адрес переданный клиентом с # # полученным от DNS. # # Значение по умолчанию - “yes”. # # # ############################################################ ############# Настройки доступа пользователей ############## ############################################################ # # # Пустить/не пустить пользователя определяется директивами # # DenyUsers, AllowUsers, DenyGroups, и AllowGroups. # # при этом, проверка проходит сверху - вниз по цепочке: # # ## DenyUsers ## # # || # # ## AllowUsers ## # # || # # ## DenyGroups ## # # || # # ## AllowGroups ## # # Принимаются только имена пользователей и групп, числовые # # идентификаторы (UserID) - не распознаются. Корректная # # запись нескольких пользователей/групп по очереди, через # # пробел. Если записано в виде пользователь@хост - то # # пользователь и хост проверяются отдельно, это позволяет # # разграничить доступ определенных пользователей с # # определенных хостов. Стоит помнить, что директивы # # DenyUsers и AllowUsers принимают в качестве параметра # # имя пользователя, а DenyGroups и AllowGroups - имя # # группы. См. PATTERNS в man ssh_config для дополнительной # # информации о формах записи имен пользователей и групп. # # # ## DenyUsers ############################################### # # # Список ПОЛЬЗОВАТЕЛЕЙ, которым НЕЛЬЗЯ пользоваться sshd. # # По умолчанию - не указан = не запрещен никто. Т.е. если # # тут указан пользователь, то ему будет отказано в доступе # # к ssh серверу. # # # ## AllowUsers ############################################## # # # Список ПОЛЬЗОВАТЕЛЕЙ, которым МОЖНО пользоваться sshd, # # По умолчанию - не указан = разрешено всем. Т.е. если # # указан хотя бы один пользователь, ssh доступ к серверу # # доступен только для него. # # # ## DenyGroups ############################################## # # # Список ГРУПП, которым НЕЛЬЗЯ пользоваться sshd. # # По умолчанию - не указан = не запрещена ни одна группа. # # Т.е. если указана хотя бы одна группа, то пользователям, # # входящим в эту группу будет отказано в доступе к ssh # # серверу. # # # ## AllowGroups ############################################# # # # Список ГРУПП, которым МОЖНО пользоваться sshd. # # По умолчанию - не указан = разрешено всем. Т.е. если # # указана хотя бы одна группа, то только тем пользователям,# # которые в нее входят будет разрешен доступ к ssh серверу.# # # ############################################################ ######### Опции определения состояния соединения ########### ############################################################ # # ## TCPKeepAlive ############################################ # # # Указывает, нужно системе посылать TCP сообщения клиенту # # с целью поддержания соединения. Если посылать эти пакеты,# # можно определить разрыв соединения. Однако это также # # означает, что соединение может быть разорвано в случае # # кратковременного перебоя в работе маршрутизации и # # некоторых это сильно раздражает. С другой стороны, если # # таких сообщений не посылать - сеансы на сервере могут # # длиться бесконечно, порождая пользователей - "призраков",# # и пожирая ресурсы сервера. Значение по умолчанию - “yes”,# # т.е. посылать такие сообщения. Для отключения отправки # # таких сообщений нужно задать значение “no”. Ранее эта # # опция называлась KeepAlive. Стоит заметить, что # # существуют более защищенные способы проверки состояния # # соединения (см. ниже). # # # TCPKeepAlive yes # # ## ClientAliveCountMax ##################################### # # # Задает количество сообщений к клиентам, которые sshd # # посылает подряд, не получая какого либо ответа от # # клиента. Если пороговое значение будет достигнуто, а # # клиент так и не ответил - sshd отключит клиента, прервав # # ssh сессию. Стоит отметить, что использование таких # # сообщений в корне отличается от директивы TCPKeepAlive. # # Сообщения к/от клиентов посылаются по зашифрованному # # каналу и поэтому не подвержены спуфингу. Сообщения же # # TCPKeepAlive спуфингу подвержены. Механизм client alive # # особо ценен в тех случаях, когда серверу и клиенту нужно # # знать когда соединение стало неактивным. По умолчанию # # значение равно 3. В случае, если ClientAliveInterval # # задан равным 15 и ClientAliveCountMax оставлен по # # умолчанию, неотвечающие клиенты будут отключены примерно # # через 45 секунд. Эта директива работает только для # # протокола ssh2. # # # ## ClientAliveInterval ##################################### # # # Задает временной интервал в секундах. Если в течении # # этого интервала не было обмена данными с клиентом, sshd # # посылает сообщение по зашифрованному каналу, # # запрашивающее ответ от клиента. По умолчанию - 0, т.е. # # не посылать таких сообщений. Эта директива работает # # только для протокола ssh2. # # # ############################################################ ################ Общие опции аутентификации ################ ############################################################ # # ## AuthorizedKeysFile ###################################### # # # Указывает файл, в котором содержатся публичные ключи, # # используемые для аутентификации пользователей. Директива # # может содержать маркеры вида %М, которые подставляются в # # процессе установки соединения. # # Определены следующие маркеры: # # %% - заменяется литералом "%" # # %h - заменяется домашней директорией # # аутентифицируещегося пользователя # # %u - заменяется именем аутентифицируещегося пользователя # # Таким образом, файл с ключами может быть задан как # # абсолютным путем (т.е. один общий файл с ключами), так и # # динамически - в зависимости от пользователя (т.е. по # # файлу на каждого пользователя). # # По умолчанию - “.ssh/authorized_keys”. # # Пример для файла ключа в домашней папке пользователя: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Пример для общего файла: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # См. описание файла authorized_keys для большей # # информации. # # # ## ChallengeResponseAuthentication ######################### # # # Указывает, разрешить ли аутентификацию вида вопрос-ответ # # (challenge-response authentication). Поддерживаются все # # виды аутентификации из login.conf По умолчанию - “yes”, # # т.е. разрешить. # # В Ubuntu - выключена по соображениям безопасности. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ######################### # # # Указывает, как сервер должен получать имя хоста клиента # # при схеме аутентификации, основанной на проверке хоста. # # Если задать "yes" - при проверке соответствия в файлах # # ~/.shosts, ~/.rhosts или /etc/hosts.equiv sshd будет # # использовать имя хоста, предоставленное клиентом. # # (выполняя реверсивное DNS распознование) Если задать "no"# # - sshd будет ресолвить имя из самого TCP соединения. # # По умолчанию - "no". # # # ## IgnoreRhosts ############################################ # # # Запрещает использование файлов.rhosts и.shosts # # в процессе аутентификации, основанной на проверке хоста. # # (RhostsRSAAuthentication или HostbasedAuthentication). # # Файлы /etc/hosts.equiv и /etc/ssh/shosts.equiv все еще # # используются. # # По умолчанию - “yes”. # # # IgnoreRhosts yes # # ## IgnoreUserKnownHosts #################################### # # # Указывает должен ли sshd игнорировать пользовательские # # "известные хосты" - файл ~/.ssh/known_hosts в процессе # # аутентификации, основанной на проверке хоста # # (RhostsRSAAuthentication или HostbasedAuthentication). # # По умолчанию - “no”. # # # ## PermitBlacklistedKeys ################################### # # # Указывает, стоит ли sshd принимать ключи, занесенные в # # черный список как скомпрометированные (known-compromised # # keys (см. ssh-vulnkey)). Если задано значение “yes” - # # попытки аутентификации с такими ключами будут занесены в # # журнал и приняты, если значение “no” - попытки # # аутентификации будут отвергнуты. # # По умолчанию - “no”. # # # ## PermitEmptyPasswords #################################### # # # В случае разрешенной аутентификации с помощью пароля, # # указывает, возможен ли вход с пустым паролем. # # По умолчанию - “no”. # # # PermitEmptyPasswords no # # ## PermitRootLogin ######################################### # # # Указывает, возможен ли ssh-вход под суперпользователем # # (root). Может принимать значения: # # “yes” - суперпользователь может зайти. Применяется # # текущая глобальная схема аутентификации. # # # # “without-password” - суперпользователь может зайти. # # Парольная аутентификация для него будет отключена. # # # # “forced-commands-only” - суперпользователь сможет зайти, # # пользуясь аутентификацией на основе публичного ключа и # # только если передаст необходимую к исполнению комнаду. # # Это удобно для осуществления резервного копирования, # # даже в том случае, когда нормальный (т.е. не через ssh) # # вход суперпользователя запрещен. Все остальные методы # # аутентификации для суперпользователя будут заблокированы.# # # # “no” - суперпользователь не может использовать ssh для # # входа в систему. # # # # Значение по умолчанию - “yes”. # # # PermitRootLogin yes # # ## Protocol ################################################ # # # Указывает, какой протокол должен использовать sshd. # # Возможные значения ‘1’ и ‘2’ - ssh1 и ssh2 # # соответственно. Возможна одновременная запись, при # # которой значения следует разделять запятыми. # # По умолчанию - “2,1”. # # Стоит отметить, что порядок следования протоколов в # # записи не задает приоритет, т.к. клиент выбирает какой # # из нескольких предложенных сервером протоколов ему # # использовать.Запись "2,1" абсолютно идентична # # записи "1,2". # # # Protocol 2 # # ## UsePAM ################################################## # # # Включает интерфейс PAM (Pluggable Authentication Module # # interface).Если задано значение "yes" - для всех типов # # аутентификации помимо обработки модуля сессии и аккаунта # # PAM будет использоваться аутентификация на основе # # запроса-ответа (ChallengeResponseAuthentication и # # PasswordAuthentication) Т.к. аутентификация # # запросов-ответов в PAM обычно выполняет ту же роль, # # что и парольная аутентификация, вам следует отключить # # либо PasswordAuthentication, либо # # ChallengeResponseAuthentication. Стоит отметить, что # # если директива UsePAM включена - вы не сможете запустить # # sshd от имени пользователя, отличного от root. # # Значение по умолчанию - “no”. # # # UsePAM yes # # ## PasswordAuthentication ################################## # # # Указывает, разрешена ли аутентификация с использованием # # пароля. # # По умолчанию - “yes”. # # # ## HostKey ################################################# # # # Указывает файл, содержащий закрытый хост-ключ, # # используемый SSH. По умолчанию - /etc/ssh/ssh_host_key # # для протокола ssh1 и /etc/ssh/ssh_host_rsa_key и # # /etc/ssh/ssh_host_dsa_key для протокола ssh2. Стоит # # отметить, что sshd не станет пользоваться файлом, # # который доступен кому либо, кроме пользователя. Можно # # использовать несколько файлов с ключами, ключи “rsa1” - # # для протокола ssh1 и “dsa”/“rsa” для протокола ssh2. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # # ############################################################ ########## Опции протокола SSH версии 1 (ssh1) ############# ############################################################ # Настоятельно НЕ РЕКОМЕНДУЕТСЯ использовать протокол ssh1.# # Протокол ssh2 намного более безопасен, чем ssh1 # ############################################################ # # ## KeyRegenerationInterval ################################# # # # Для протокола ssh1 - раз в определенное время # # автоматически генерируется новый временный ключ сервера # # (если он был использован). Это сделано для # # предотвращения расшифровки перехваченных сеансов,с целью # # позже зайти с параметрами этих сеансов на машину и # # украсть ключи. Такой ключ нигде не хранится (хранится в # # оперативной памяти). Данная директива указывает период # # "жизни" ключа в секундах, после которого он будет # # сгенерирован заново. Если значение задать равным 0 - # # ключ не будет генерироваться заново. # # По умолчанию значение - 3600 (секунд). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ################################# # # # Указывает, нужна ли аутентификация на основе файлов # # rhosts или /etc/hosts.equiv совместно с успешной # # аутентификацией хоста через RSA. # # Актуально только для протокола ssh1. # # По умолчанию - “no”. # # # RhostsRSAAuthentication no # # ## RSAAuthentication ####################################### # # # Указывает, разрешена ли "чистая" RSA-аутентификация. # # Актуально только для протокола ssh1. # # По умолчанию - “yes”. # # # RSAAuthentication yes # # ## ServerKeyBits ########################################### # # # Определяет число бит во временном ключе сервера для # # протокола ssh1. Минимальное значение 512. # # Значение по умолчанию - 1024. # ServerKeyBits 768 # # ############################################################ ########### Опции протокола SSH версии 2 (ssh2) ############ ############################################################ # # ## Ciphers ################################################# # # # Указывает алгоритмы шифрования, разрешенные для # # протокола ssh2. Несколько алгоритмов должны быть # # разделены запятыми. Поддерживаемые алгоритмы: # # “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, # # “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “arcfour128”, # # “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”. # # По умолчанию используются: # # aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, # # arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, # # aes192-ctr,aes256-ctr # # # ## HostbasedAuthentication ################################# # # # Указывает, разрешена ли аутентификация, основанная на # # проверке хоста. Проверяется rhosts или /etc/hosts.equiv, # # и в случае успеха, совместного с успешной проверкой # # публичного ключа, доступ разрешается. Данная директива # # одинакова с директивой RhostsRSAAuthentication и # # подходит только для протокола ssh2. # # По умолчанию - "no". # # # HostbasedAuthentication no # # ## MACs #################################################### # # # Указывает допустимый алгоритм MAC (message # # authentication code). Алгоритм MAC используется # # протоколом ssh2 для защиты целостности данных. Несколько # # алгоритмов должны быть разделены запятыми. # # По умолчанию используются: # # hmac-md5,hmac-sha1,[email protected],hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication #################################### # # # Указывает, разрешена ли аутентификация на основе # # публичного ключа. Актуально только для протокола ssh2. # # По умолчанию - “yes”. # # # PubkeyAuthentication yes ############################################################ #################### Опции GSSAPI ########################## ############################################################ # # ############ Применимо только для протокола ssh2 ########### # # ## GSSAPIAuthentication #################################### # # # Указывает, разрешена ли аутентификация пользователя на # # основе GSSAPI. По умолчанию - "no", т.е. запрещена. # # # ## GSSAPIKeyExchange ####################################### # # # Указывает, разрешен ли обмен ключами, основанный на # # GSSAPI. Обмен ключам при помощи GSSAPI не полагается на # # ssh ключи при верификации идентичности хоста. # # По умолчанию - "no" - т.е. обмен запрещен. # # # ## GSSAPICleanupCredentials ################################ # # # Указывает, нужно ли автоматически уничтожать # # пользовательский кеш аутентификационных полномочий при # # завершении сеанса. # # По умолчанию - "yes" - т.е. нужно уничтожать. # # # ## GSSAPIStrictAcceptorCheck ############################### # # # Указывает, насколько строгой должна быть проверка # # идентичности клиента при аутентификации через GSSAPI. # # Значение "yes" заставляет клиента аутентифицироваться в # # принимающей хост-службе на текущем хосте. Значение "no" # # позволяет клиенту аутентифицироваться при помощи любого # # ключа служб. # # Значение по умолчанию - "yes". # # Стоит заметить, что задание значения "no" может # # сработать только с редкими библиотеками Kerberos GSSAPI. # # # ############################################################ ################### Опции Kerberos ######################### ############################################################ # # ## KerberosAuthentication ################################## # # # Указывает, требует ли пароль, предоставленный # # пользователем для аутентификации # # (PasswordAuthentication) валидации в Kerberos KDC. # # Для использования этой опции серверу нужно # # удостовериться в истинности KDC. (Тhe server needs a # # Kerberos servtab which allows the verification of the # # KDC’s identity) # # По умолчанию - “no”. # # # ## KerberosGetAFSToken ##################################### # # # Если активен AFS и пользователь получил Kerberos 5 TGT, # # пытаться ли получить AFS токен до того, как пользователь # # получит доступ к своей домашней папке. # # По умолчанию - “no”. # # # ## KerberosOrLocalPasswd ################################### # # # Указывает, как поступать в случае, если аутентификация # # через Kerberos завершилась неудачей. Если # # значение = "yes" - пароль будет проверен при помощи # # любого дополнительного локального механизма авторизации, # # например - /etc/passwd. # # По умолчанию - “yes”. # # # ## KerberosTicketCleanup ################################### # # # Указывает, нужно ли автоматически уничтожать файл с # # кешем тикета пользователя по завершению сеанса. # # По умолчанию - “yes”. # # # ############################################################ ################# Опции перенаправления #################### ############################################################ # # ## AllowAgentForwarding #################################### # # # Указывает, разрешить или запретить перенаправление # # ssh-agent"а. По умолчанию - “yes”, т.е. разрешить. # # Стоит заметить, что отключение перенаправления не # # увеличит безопасности пока пользователям также не будет # # запрещен shell доступ, т.к. они всегда смогут установить # # свои собственные аналоги агента. # # # ## AllowTcpForwarding ###################################### # # # Указывает, разрешить или запретить перенаправление TCP. # # По умолчанию - “yes”, т.е. разрешить. Стоит заметить, # # что как и в случае с AllowAgentForwarding отключение # # перенаправления не увеличит безопасности, пока у # # пользователей будет консольный доступ, т.к. они смогут # # установить свои аналоги. # # # # # ## GatewayPorts ############################################ # # # Указывает, разрешать ли удаленным хостам доступ к # # перенаправленным портам. По умолчанию, sshd слушает # # соединения к перенаправленным портам только на локальном # # интерфейсе (loopback). Это не дает другим удаленным # # хостам подсоединяться к перенаправленным портам. Можно # # использовать GatewayPorts, чтобы разрешить sshd это # # делать. Директива может принимать 3 значения: # # "no" - только loopback. # # "yes"- любые адреса. # # "clientspecified" - адреса указанные клиентом. # # # ## PermitOpen ############################################## # # # Указывает куда разрешено перенаправление TCP портов. # # Указание перенаправления должно принимать одну из # # следующих форм: # # PermitOpen host:port # # PermitOpen IPv4_addr:port # # PermitOpen :port # # Несколько записей можно задать, разделяя их пробелами. # # Аргумент “any” можно использовать для снятия всех # # запретов на перенаправление портов. По умолчанию любое # # перенаправление разрешено. # # # ## PermitTunnel ############################################ # # # Указывает, разрешено ли перенаправление tun-устройств. # # Может принимать значения: # # “yes” # # “point-to-point” (3-й сетевой уровень) # # “ethernet” (2-й сетевой уровень) # # “no” # # Значение “yes” разрешает одновременно и “point-to-point” # # и “ethernet”. По умолчанию - “no”. # # # ############################################################ ################## Опции журналирования #################### ############################################################ # # ## SyslogFacility ########################################## # # # Задает код объекта журнала для записи сообщений в # # системный журнал от sshd. Возможные значения: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # По умолчанию используется AUTH. # # # SyslogFacility AUTH # # ## LogLevel ################################################ # # # Задает уровень детальности журнала sshd. # # Возможные варианты: # # SILENT # # QUIET # # FATAL # # ERROR # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # По умолчанию - INFO. # # DEBUG и DEBUG1 эквивалентны друг другу. # # DEBUG2 и DEBUG3 задают самые высокие уровни отладочного # # вывода. Запись логов с уровнем DEBUG угрожает # # приватности пользователей и не рекомендована. # # # LogLevel INFO # # ############################################################ ################### Перенаправление X11 #################### ############################################################ # # ## X11Forwarding ########################################### # # # Указывает, разрешено ли перенаправление графической # # подсистемы X11. Может принимать значения “yes” или “no”. # # По умолчанию - “no”. # # Внимание - включение простого перенаправления Х11 - # # большой риск как для сервера, так и для клиентов, т.к. в # # случае такого перенаправления прокси-дисплей sshd # # принимает соединения с любых адресов. Используйте # # директиву X11UseLocalhost для ограничения доступа к # # серверу перенаправления "иксов". Стоит отметить, что # # отключение перенаправления не даст гарантии, что # # пользователи не смогут перенаправлять Х11, т.к. имея # # консольный доступ они всегда установить свой # # перенаправлятель. Перенаправление Х11 будет # # автоматически отключено, если будет задействована # # директива UseLogin. # # # X11Forwarding yes # # ## X11UseLocalhost ######################################### # # # Указывает, должен ли sshd ограничить область # # перенаправления Х11 локальным loopback адресом, или # # должен разрешить любые адреса. По умолчанию - sshd # # "сажает" сервер перенаправления Х11 на локальный адрес # # и задает часть переменной окружения DISPLAY, отвечающую # # за имя хоста как “localhost”. Стоит заметить, что # # некоторые старые клиенты Х11 могут не работать с такими # # настройками. По умолчанию - "yes", т.е. перенаправление # # ограничено локалхостом, значение - “no” - отключает # # ограничения. # # # ## XAuthLocation ########################################### # # # Указывает полный путь к программе xauth. # # По умолчанию - /usr/bin/X11/xauth. # # # ## X11DisplayOffset ######################################## # # # Указывает номер первого дисплея, доступного sshd в # # качестве перенаправления X11. Это сделано для того, # # чтобы перенаправленные "иксы" не пересекались с # # реальными. По умолчанию - 10. # # # X11DisplayOffset 10 # # ############################################################ ################### Различные опции ######################## ############################################################ # # ## LoginGraceTime ########################################## # # # Время, по прошествии которого сервер отключает # # пользователя, если тот не смог удовлетворительно # # залогиниться. Значение 0 - разрешает пользователю # # логиниться бесконечно. По умолчанию - 120 (секунд). # # # LoginGraceTime 120 # # ## MaxAuthTries ############################################ # # # Указывает максимальное число попыток аутентификации, # # разрешенное для одного соединения. # # Как только число неудачных попыток превысит половину # # заданного значения, все последующие попытки будут # # заноситься в журнал. Значение по умолчанию - 6. # # # ## MaxSessions ############################################# # # # Указывает максимальное число одновременных подключений # # для каждого сетевого соединения. По умолчанию - 10. # # # ## MaxStartups ############################################# # # # Указывает максимальное число одновременных # # неавторизованных подключений к sshd. В случае, если # # число подключений превысит лимит - все дополнительные # # подключения будут сброшены до тех пор, пока текущие # # подключения не завершатся либо успешной авторизацией, # # либо истечением периода времени указанного в директиве # # LoginGraceTime. Значение по умолчанию - 10. # # Дополнительно, можно задать ранний сброс соединений, # # указав в качестве параметра три значения, разделенные # # двоеточием “start:rate:full” (например: "10:30:60"). # # sshd отклонит попытку соединения с вероятностью равной # # “rate/100” (т.е. в нашем примере - 30%), если уже # # имеется “start” (10) неавторизованных соединений. # # Вероятность увеличивается линейно и любые попытки # # соединения будут отклонены, если число неавторизованных # # соединений достигнет значения “full” (60). # # # ## Compression ############################################# # # # Указывает, разрешено ли сжатие данных. Может быть # # "yes" - сжатие разрешено. # # "delayed" - сжатие отложено до тех пор, пока # # пользователь успешно не аутентифицируется. # # "no" - сжатие запрещено. # # По умолчанию - "delayed". # # # ## UseLogin ################################################ # # # Указывает, должен ли использоваться login для # # интерактивного сеанса. Значение по умолчанию - “no”. # # Стоит отметить, что login никогда не использовался для # # выполнения удаленных команд. Так же заметим, что # # использование login сделает невозможным использование # # директивы X11Forwarding, потому что login не знает, что # # ему делать с xauth. Если включена директива # # UsePrivilegeSeparation - она будет отключена после # # авторизации. # # # ## UsePrivilegeSeparation ################################## # # # Указывает, должен ли sshd разделять привилегии. Если да # # - то сначала будет создан непривилегированный дочерний # # процесс для входящего сетевого трафика. После успешной # # авторизации будет создан другой процесс с привилегиями # # вошедшего пользователя. Основная цель разделения # # привилегий - предотвращение превышения прав доступа. # # Значение по умолчанию - “yes”. # # # UsePrivilegeSeparation yes # # ## StrictModes ############################################# # # # Указывает должен ли sshd проверить режимы доступа и # # владения пользовательских папок и файлов перед тем, как # # дать пользователю войти. Обычно это объясняется тем, что # # новички часто делают свои файлы доступными для записи # # всем подряд.По умолчанию - “yes”. # # # StrictModes yes # # ## AcceptEnv ############################################### # # # Указывает, какие переменные окружения, переданные # # клиентом будут приняты. См. опцию SendEnv в клиенте. # # Стоит заметить, что передача переменных возможна только # # для протокола ssh2. Переменные указываются по имени, # # можно использовать маски (‘*’ и ‘?’). Можно указывать # # несколько переменных через пробел, или разбить на # # несколько строк AcceptEnv. Будьте осторожны - некоторые # # переменные окружения могут быть использованы для обхода # # запрещенных пользовательских окружений. Пользуйтесь этой # # директивой аккуратно. По умолчанию никакие # # пользовательские переменные окружения не принимаются. # # # AcceptEnv LANG LC_* # # ## PermitUserEnvironment ################################### # # # Указывает, должен ли sshd воспринимать # # ~/.ssh/environment и опцию environment= в # # ~/.ssh/authorized_keys. По умолчанию - “no”. Стоит # # заметить, что разрешение обработки окружения может дать # # пользователям возможность обойти ограничения в некоторых # # конфигурациях, использующих такие механизмы, как # # LD_PRELOAD. # # # # # ## PidFile ################################################# # # # Указывает файл, содержащий идентификатор процесса # # (process ID, PID) демона SSH. # # По умолчанию - /var/run/sshd.pid # # # # # ## PrintLastLog ############################################ # # # Указывает, должен ли sshd выводить на экран дату и время # # последнего севнса при интерактивном входе пользователя. # # По умолчанию - “yes”. # # # PrintLastLog yes # # ## PrintMotd ############################################### # # # Указывает, должен ли sshd выводить на экран /etc/motd # # при интерактивном входе пользователя. На некоторых # # системах (например в Ubuntu) эта информация так же # # выводится на экран оболочкой. # # Значение по умолчанию - “yes”. # # # PrintMotd no # # ## Banner ################################################## # # # Указывает какой файл содержит текстовый баннер, который # # будет показан пользователю ПЕРЕД процедурой # # аутентификации. Опция доступна только для протокола ssh2.# # По умолчанию - не показывает ничего. # # В Ubuntu файл issue.net содержит фразу Ubuntu {version}, # # например, для karmic это "Ubuntu 9.10". Можно # # использовать для дезориентации возможных атакующих, # # написав туда например "My D-Link Interet Router" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ######################################### # # # Если указан - предоставляет путь, по которому будет # # выполнен chroot после аутентификации. Путь и все его # # содержимое должны соответствовать принадлежащим # # суперпользователю папкам и быть не доступными для # # записи другими пользователями. # # В пути могут быть указаны метки, подставляемые в # # процессе аутентификации: # # %% - заменяется литералом "%" # # %h - заменяется домашней директорией # # аутентифицируещегося пользователя # # %u - заменяется именем аутентифицируещегося пользователя # # chroot-папка должна содержать все необходимые файлы и # # папки для пользовательского сеанса. Для интерактивного # # сеанса нужны как минимум: # # оболочка, обычно - sh # # базовые устройства в /dev, такие как: # # null, zero, stdin, stdout, stderr, arandom и tty # # для сеанса передачи данных при помощи sftp никаких # # дополнительных настроек не нужно, если используется # # внутренний процесс sftp сервера. См. Subsystem для # # большей информации. По умолчанию chroot не выполняется. # # # ## ForceCommand ############################################ # # # Заставляет выполняться указанную команду. Игнорирует # # любые команды переданные клиентом или записанные в # # ~/.ssh/rc. Команда вызывается из пользовательской # # оболочки с опцией -с. Подходит для запуска оболочки, # # команды или подсистемы. Наиболее полезна внутри блока # # Match. Команда, изначально переданная клиентом, хранится # # в переменной окружения SSH_ORIGINAL_COMMAND. Если # # указать команду "internal-sftp", будет запущен # # внутренний sftp сервер, которому не нужны дополнительные # # файлы и папки, описанные в директиве ChrootDirectory. # # # ## Subsystem ############################################### # # # Определяет и настраивает внешнюю подсистему (например # # демона передачи файлов - file transfer daemon). # # Аргументами служат имя и команда (с возможными # # аргументами), которая будет выполнена во время запроса # # на подсистемы. Команда sftp-server запускает “sftp” - # # подсистему передачи файлов. Дополнительно можно указать # # в качестве подсистемы “internal-sftp” - что запустит # # внутренний sftp сервер. Это может значительно упростить # # настройку в случае использования директивы # # ChrootDirectory По умолчанию никаких подсистем # # не вызывается. Актуально только для протокола ssh2. # # # Subsystem sftp /usr/lib/openssh/sftp-server # # ############################################################ ##################### Блок Match ########################### ############################################################ # # # Специально вынес в конец файла, чтобы было удобнее # # писать Match правила. # # MadKox. # # # # Директива Match представляет собой начало условного # # блока. Если выполнены все критерии, указанные в строке # # Match, директивы в последующих строках блока выполняются,# # позволяя обойти значения глобальных директив файла # # sshd_config для случая, являющегося критерием директивы # # Match. Блоком считаются все строки, идущие после строки # # с критерием (Match - строки) до следующей match-строки # # или до конца файла. Аргумент директивы Match - одна или # # несколько пар записей критериев. Возможные виды записей: # # User # # Group # # Host # # Address # # Записи могут содержать как одиночные значения # # (например User=user), так и несколько значений, # # разделенные запятыми (User=user1,user2). Так же могут # # быть использованы регулярные выражения, описанные в # # секции PATTERNS файла ssh_config. Записи в критерии # # Address могут содержать адреса в нотации CIDR # # (Адрес/Длинна маски, например “192.0.2.0/24” или # # “3ffe:ffff::/32”). Стоит заметить, что представленная # # длинна маски должна соответствовать адресу, и слишком # # длинные/короткие для адреса не будут работать. # # В качестве директив Match может использовать только # # определенный набор директив: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAuthentication # # MaxAuthTries # # MaxSessions # # PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #
Можно скопировать приведенный выше текст в ваш собственный sshd_config и использовать в дальнейшем для настройки.
Сам по себе, неправильно настроенный SSH -сервер - огромная уязвимость в безопасности системы, т. к. у возможного злоумышленника есть возможность получить практически неограниченный доступ к системе. Помимо этого, у sshd есть много дополнительных полезных опций, которые желательно включить для повышения удобства работы и безопасности .
Port, ListenAddress и AddressFamily
Эти три параметра определяют, на каких портах и адресах ваш сервер будет ждать входящие соединения. Во-первых, имеет смысл по возможности ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 - отключите IРv6, и наоборот. Сделать это можно при помощи параметра AddressFamily, например (для разрешения IPv4 и запрета IPv6):
AddressFamily inet
Во-вторых, желательно сменить стандартный порт (22) на котором слушает sshd. Это связано с тем, что многочисленные сетевые сканеры постоянно пытаются соединиться с 22-м портом и как минимум получить доступ путем перебора логинов/паролей из своей базы. Даже если у вас и отключена парольная аутентификация - эти попытки сильно засоряют журналы и (в большом количестве) могут негативно повлиять на скорость работы ssh сервера. Если же вы по какой либо причине не желаете изменить стандартный порт вы можете использовать как различные внешние утилиты для борьбы брутфорсерами, например fail2ban , так и встроенные, такие как MaxStartups .
Задать порт можно как абсолютным значением для всех интерфейсов при помощи директивы Port , так и конкретным значением для каждого интерфейса, при помощи директивы ListenAddress . Например:
Port 2002
ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004
Запрещение удаленного доступа для суперпользователя
По умолчанию root-доступ запрещен по паролю (по ключу - можно) - опция PermitRootLogin установлена в without-password . Но, при условии, что по умолчанию в Ubuntu пользователь, добавленный при установке системы имеет возможность решать все административные задачи через sudo, создавать возможность root доступа к системе через ssh - выглядит неразумно (даже при аутентификации по ключу). Рекомендуется совсем отключить. эту опцию, или применять ее только в режиме forced-commands-only . Отключить root-доступ можно так:
PermitRootLogin no
Парольная аутентификация
Разрешенная по умолчанию парольная аутентификация является практически самым примитивным способом авторизации в sshd. С одной стороны это упрощает конфигурацию и подключение новых пользователей (пользователю достаточно знать свой системный логин/пароль), с другой стороны пароль всегда можно подобрать, а пользователи часто пренебрегают созданием сложных и длинных паролей. Специальные боты постоянно сканируют доступные из интернета ssh сервера и пытаются авторизоваться на них путем перебора логинов/паролей из своей базы. Настоятельно не рекомендуется использовать парольную аутентификацию. Отключить ее можно так:
PasswordAuthentication no
Если по каким либо причинам вам все таки хочется использовать парольную аутентификацию - позаботьтесь о том, чтобы никто не мог авторизоваться с пустым паролем. Для этого задайте директиву PermitEmptyPasswords:
PermitEmptyPasswords no
Протоколы SSH1 и SSH2
Как уже было сказано, sshd может работать с протоколами SSH1 и SSH2. При этом использование небезопасного SSH1 крайне не рекомендуется. Заставить sshd работать только с протоколом SSH2 можно так:
Аутентификация на основе SSH2 RSA-ключей
Наиболее предпочтительным способом авторизации является аутентификация на основе SSH2 RSA-ключей. При таком способе пользователь генерирует на своей стороне пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ копируется на сервер и служит для проверки идентичности пользователя. Более подробно про создание пары ключей и способы размещения их на сервере см. в описании SSH -клиента. Включить аутентификацию по публичному ключу можно так:
PubkeyAuthentication yes
Сервер должен знать, где ему следует искать публичный ключ пользователя. Для этого применяется специальный файл authorized_keys . Синтаксис его может быть следующим:
# Коментарии записываются только с новой строки # общий вид записей в файле authorized_keys # [опции] тип_ключа(ssh-rsa или ssh-dss) очень_длинная_строка_непонятная_простому_человеку [логин@хост] ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss AAAAB5...21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [email protected]
Можно указать как один общий файл с ключами, так и по файлу на каждого пользователя. Последний способ является более удобным и безопасным, т. к. можно во-первых указывать разные комбинации ключей для каждого пользователя , а во-вторых ограничить доступ к публичному ключу пользователя. Задать файл с ключами можно при помощи директивы AuthorizedKeysFile:
AuthorizedKeysFile %h/.ssh/my_keys
для схемы пользователь - файл
или
AuthorizedKeysFile /etc/ssh/authorized_keys
для схемы с общим файлом. По умолчанию SSH -клиент ищет ключи в файле ~/.ssh/authorized_keys .
Еще про безопасность
Дополнительные настройки
Пользователи и группы.
Если у вас на сервере «живет» много пользователей, а доступ через ssh вы хотите разрешить только нескольким из них - вы можете использовать директивы DenyUsers , AllowUsers , DenyGroups , и AllowGroups . Более подробно про эти директивы см. комментарии в примере sshd_config .
Опции определения состояния соединения
По умолчанию из способов определения состояния соединения включен только способ проверки TCP соединения - TCPKeepAlive , однако, sshd умеет определять состояния соединения и более удобными и безопасными способами. Подробнее см. соответствующий раздел в примере sshd_config .
Производительность. MaxStartups
Перенаправление портов
Перенаправление X11
На сервере в файле /etc/ssh/sshd_config выставить параметр (по умолчанию включено):
ForwardX11 yes
На клиенте в файле /etc/ssh/ssh_config выставить параметры (по умолчанию выключено):
ForwardAgent yes ForwardX11 yes
Запускать на клиенте можно так ssh yurauname@serverip firefox . Или сначала заходим ssh yurauname@serverip потом запускаем, например sudo synaptic .
SFTP
В sshd по умолчанию встроен SFTP-сервер. Протокол SFTP (SSH File Transfer Protocol) - SSH -протокол для передачи файлов. Он предназначен для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Как правило, в качестве базового протокола, обеспечивающего соединение, и используется протокол SSH2. Для того чтобы включить поддержку SFTP добавьте в sshd_config строку
Subsystem sftp /usr/lib/openssh/sftp-server
По умолчанию поддержка SFTP включена.
Использование критериев. Директива Match
Настройка SSH-клиента
Наиболее безопасным считается вход по ключу, и в большинстве случаев на стороне сервера такая возможность включена, так что для её использования никаких прав суперпользователя не требуется. На клиентской машине генерируем ключ:
ssh-keygen -t rsaПолучаем предложение ввести пароль для защиты файла ключа (оказывается полезным при попадании файла в чужие руки). Если мы собираемся по SSH выполнять скрипты, то оставляем пустым. Передаём публичный ключ на сервер командой
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub user@ server
Всё, можно заходить.
Когда ssh работает на нестандартном порту:
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub "-p port user@server"
Если возникает ошибка: Bad port "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"
попробуйте взять параметры в кавычки:
Ssh-copy-id "-i /home/user/.ssh/id_rsa.pub "-p port user@server""
Удобно при подключени на удалённой системе пользоваться утилитой screen .
Настройка удаленной ssh-директории в Nautilus
Монтирование удаленной директории с помощью sshfs
Монтирование удаленного каталога в локальный каталог
sshfs user@ hostingserver.ru:/ home/ userdir ~/ sshfsdirРазмонтирование
Fusermount -u ~/ sshsfdir
SSH aliases
При использовании нескольких серверов с различными параметрами доступа (нестандартный порт, длинное имя хоста, логин отличный от локального, и т.п.) порой утомительно вводить все настройки подключения каждый раз заново. Для облегчения этого можно использовать aliases.
Настройки хранятся в ~/.ssh/config для одного пользователя и в /etc/ssh/ssh_config глобально для всех пользователей.
Пример конфига. Описано может быть множество серверов. Подробнее в man ssh_config (не путать с sshd_config )
Host AliasName # Произвольное имя хоста HostName 1.2.3.4 # Можно указывать как IP, так и hostname (если работает DNS) User YourUserName # Если пользователь не совпадает с локальным пользователем Port YourSSHPort # Если нестандартный порт
После этого можно подключаться к серверу командой
ssh AliasNamessh-agent
Диагностика проблем подключения
Анализ лога подключения:
Анализ конфигурационных файлов клиента и сервера.
Расположение конфигурационных файлов можно узнать из
Man ssh man sshd
Использование смарт-карт
1. Создание сертификата и экспорт открытого ключа, а также клиентская часть на Windows + Putty SC описано на сайте: http://habrahabr.ru/post/88540/ Описанное там дополнение Key Manager доступно только в старых версиях Firefox. Проверено на версии 3.5 для Windows. Прямая ссылка на дополнение: https://addons.mozilla.org/ru/firefox/addon/key-manager/
2. Подготовка сервера. Вам необходимо убедиться что в конфигурации sshd разрешена аутентификация при помощи публичных ключей. Для этого необходимо в файле «sshd_config» указать значение параметра «PubkeyAuthentication» в «yes». Затем в файл «~/.ssh/authorized_keys» добавляем наш публичный ключ полученный ранее (одной строкой). Обратите внимание, файл «.ssh/authorized_keys» находится в домашнем каталоге того пользователя, который потом будет логиниться по публичному ключу.
3. Клиентская часть на Linux. Потребуется пересборка пакета OpenSSH без параметров. Рекомендуется только указать префиксы каталогов, например –prefix=/usr. Также следует учесть, что файлы конфигов будут в /usr/etc. Перед началом необходимы пакеты: opensc-lite-devel, zlib-devel, openssl-devel. Устанавливаем драйвер смарт-карты. Для удобства в конфиге ssh_config (не путать с sshd_config) указать путь к библиотеке pkcs: PKCS11Provider=<путь к библиотеке>
4. На клиенте запускаем ssh user@host Если смарт-карта (токен) подключена, будет запрошен пароль и выполнен вход в сессию SSH .
Возможные проблемы при использовании
Привычная комбинация клавиш Ctrl + S , используемая во многих редакторах для сохранения исправлений, при работе в терминале с ssh-cервером приведёт к выполнению команды XOFF что внешне напоминает зависание сессии. Однако это не так. Сервер продолжает принимать вводимые символы и команды, но не выводит это на экран. Что бы выйти из такого затруднительного положения достаточно применить комбинацию Ctrl + Q , тем самым включив режим XON обратно.
Ссылки
Т. е. user1 может быть прописан как у себя - в файле /home/user1/.ssh/keys) так и у другого пользователя, что позволит ему выполнять со своего компьютера вход как «под собой», так и под «другим»
