Подключение по ssh из windows. Работа по SSH на виртуальном хостинге

Заметка о том, как подключиться через SSH к серверу под управлением Linux. Что такое SSH (Secure Shell) ? Говоря простым языком – безопасный протокол передачи данных. Что нужно что бы подключиться через SSH ?

• IP адрес сервера,
• Логин,
• Пароль,
• SSH клиент.

С первыми тремя пунктами, думаю, вопросов не возникнет. Что такое SSH клиент? Это программа с помощью, которой мы подключаемся к серверу. Наиболее популярный SSH клиент это PuTTY. Скачать программу можно с официального сайта разработчика https://www.putty.org/ PuTTY устанавливается в два клика.

Как подключиться через PuTTY по SSH

Программа довольно простая. Вводим IP адрес нашего сервера и нажимаем Соединиться. После соединения вводим логин и пароль. При этом логин будет отображаться, а пароль нет. Подтверждаем ввод пароля клавишей Enter и попадаем на наш сервер. Итак, мы подключились к нашему серверу с помощью PuTTY через SSH.

Как подключиться к MySQL через SSH

Для консольного подключение к MySQL выполняем действия описанные выше, после чего вводим команду.

Этот документ поможет Вам выполнить подключение к Вашему виртуальному серверу по протоколам SSH и SFTP.

SSH (англ. Secure SHell - «безопасная оболочка») - сетевой протокол сеансового уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Сходен по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли.

SFTP (англ. SSH File Transfer Protocol) - протокол прикладного уровня, предназначенный для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Существует заблуждение, что SFTP это просто обычный FTP, работающий поверх SSH. В действительности SFTP - это новый протокол, разработанный с нуля.

Данные для подключения к виртуальному серверу

Все данные, необходимые для подключения к Вашему виртуальному серверу по SSH, Вы можете получить на главной странице панели управления .

Нам необходимо знать IP адрес виртуального сервера (1) и пароль для пользователя root (2).

Получив необходимые данные для подключения, можно приступать непосредственно к процессу.

Подключение к виртуальному серверу по SSH из Mac OS X или Linux

Пользователи операционных систем Mac OS X или Linux могут использовать стандартное приложение terminal для подключения к виртуальному серверу по SSH протоколу. Для подключения к Вашему виртуальному серверу используйте следующую команду (измените 188.127.236.62 на IP адрес вашего виртуального сервера):

Ssh [email protected]

Так выглядит процесс подключения к виртуальному серверу в терминале Unix или Mac OS X:

Ssh [email protected] The authenticity of host "188.127.236.62 (188.127.236.62)" can"t be established. RSA key fingerprint is 4f:e8:84:42:51:80:48:70:45:6c:69:47:79:e7:c0:56. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added "188.127.236.62" (RSA) to the list of known hosts. [email protected]"s password: #

Подключение к виртуальному серверу по SSH из Windows

Пользователи операционной системы Windows могут использовать для соединения с виртуальным сервером по протоколу SSH программу PuTTY. PuTTY - очень популярный telnet/ssh клиент, распространяется бесплатно.

Официальный сайт программы - http://www.chiark.greenend.org.uk/~sgtatham/putty/ Русскоязычный сайт поддержки - http://putty.org.ru/

После запуска программы вы увидите следущее окно:

Введите в поле “Host Name (or IP address)” IP-адрес Вашего виртуального сервера (на примере вводится helios.asu). Убедитесь, чтобы в пункте “Protocol” была выбрана радио-кнорка “SSH”.

Также, для того, чтобы каждый раз не вводить адресс и тип протокола вы можете сохранить сессию. Для этого введите ее название в поле “Saved Sessions” и нажмите кнопку “Save”.

После этого ваша сессия появится ниже в списке. Для того чтобы загрузить сохраненную сессию нужно выбрать ее из списка и нажать кнопку “Load”.

Для подключения нажмите кнопку “Open” внизу формы. Может появиться следующее сообщение:

Если вы уверены в том, что подключаетесь к нужному хосту, то нажмите кнопку “Yes/Да”. Появится следующее:

Введите свой логин (root), затем пароль. Перед вами консоль системы:

Для выхода введите:

Подключение к виртуальному серверу по SFTP

По умолчанию вам не нужно настраивать FileZilla, мы просто сразу начнём работать с программой.

Для того, чтобы подключиться к SFTP-серверу, введите IP-адрес вашего виртуального сервера в поле быстрого подключения (вместо example.com, как показано на рисунке ниже введите sftp://ip_адрес_вашего_vps). Введите порт подключения в соответствующее поле, для SFTP - 22. Введите имя пользователя и пароль, в соответствующие поля. Нажмите на кнопку “Быстрое соединение” или нажмите Enter для подключения.

Отметим, что панель быстрого подключения, как ясно из названия, приспособлена для быстрых подключений, т.е. у вас нет возможности редактировать список из 10-ти последних подключений. Для сохранения параметров подключения используйте Менеджер Сайтов.

Используйте Менеджер сайтов FileZilla для задания определённых параметров сайта и подключения к нужному SFTP-серверу. В Менеджере сайтов у вас есть возможность сохранять свои подключения и настраивать большее число параметров, чем доступно в панели быстрого подключения.

После подключения, в правой стороне главного окна будет отображён список файлов и директорий. Текущая директория будет показана в редактируемом поле в верхней части. Ниже отображается удалённое дерево директорий, а ещё ниже - содержимое текущей удалённой директории. Перейти в другую директорию можно тремя разными путями. Первый: сделайте двойной щелчок на директории в списке. Второй: кликните на директории в дереве. Последний способ: введите имя директории в редактируемое поле и нажмите Enter. Обратите внимание на директорию “..”, присутствующую практически во всех остальных директориях. Эта ссылка позволяет вам перейти к родительскому каталогу текущей директории.

Навигация на вашем компьютере работает почти так же, как и на сервере. Текущая локальная директория и дерево каталогов по умолчанию отображаются на левой стороне главного окна.

Подробную документацию по работе с FileZilla, Вы можете найти на официальном сайте по адресу http://filezilla.ru/documentation/Using

Условия использования документа

Материал представленный на данной странице может быть использован Вами по своему усмотрению. Разрешается копирование и распространение предоставленного материала без изменения содержания и без предварительного уведомления администрации Clodo.ru .

Мы будем признательны Вам за сообщения об ошибках в представленной документации и за предложения об улучшении документации. По этим вопросам необходимо обращаться по адресу [email protected] . При обращении не забывайте указывать URL-адрес публикации.

Что такое и для чего нужен SSH

Безопасный шелл (SSH) - это сетевой протокол, обеспечивающий функции шелла на удалённой машине через безопасный канал. SSH несёт в себе различные улучшения безопасности, среди них аутентификация пользователя/хоста, шифрование данных и целостность данных, благодаря чему невозможны популярные атаки вроде подслушивания (eavesdropping), DNS/IP spoofing, подделка данных (data forgery), перехват соединения (connection hijacking) и т. д. Пользователям ftp, telnet или rlogin, которые используют протокол, передающий данные в виде открытого текста, крайне рекомендуется переключиться на SSH.

OpenSSH - это реализация с открытым исходным кодом протокола SSH, позволяющая шифровать соединение в сети посредством набора программ. Если вам хочется иметь SSH на Linux, вы можете установить OpenSSH, который состоит из сервера OpenSSH и клиентских пакетов.

OpenSSH серверные/клиентские пакеты поставляются со следующими утилитами:

• OpenSSH сервер: sshd (SSH daemon)
• OpenSSH клиент: scp (безопасное удалённое копирование), sftp (безопасная передача файлов), slogin/ssh (безопасный удалённый вход), ssh-add (дополнение закрытого ключа), ssh-agent (агент аутентификации), ssh-keygen (управление ключами аутентификации).

Если вы хотите установить сервер/клиент OpenSSH и настроить автоматический запуск сервера OpenSSH, следуйте следующим инструкциям, которые различаются в зависимости от дистрибутива.

Debian, Ubuntu или Linux Mint

$ sudo apt-get install openssh-server openssh-client

В системах основанных на Debian, сразу после установки, OpenSSH будет запускаться автоматически при загрузке. Если по каким либо причинам сервер OpenSSH не запускается автоматически при запуске системы, вы можете выполнить следущую команду для однозначного добавления ssh в загрузку при старте системы.

$ sudo update-rc.d ssh defaults

$ sudo yum -y install openssh-server openssh-clients $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service

$ sudo yum -y install openssh-server openssh-clients $ sudo service sshd start $ sudo chkconfig sshd on

$ sudo pacman -Sy openssh $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service

Если вы хотите настроить сервер OpenSSH, вы можете редактировать общесистемный файл конфигурации размещённый в /etc/ssh/sshd_config.

Есть пара опций OpenSSH, которые могут заинтересовать:
По умолчанию, sshd прослушивает порт 22 и ожидает входящие соединения ssh. Изменив порт по умолчанию для ssh, вы можете предотвратить различные автоматизированные атаки хакеров.
Если ваша машина имеет более чем один физический сетевой интерфейс, возможно вы заходите уточнить, какой из них связан с sshd, для этого вы можете использовать опцию ListenAddress. Эта опция помогает улучшить безопасность посредством ограничения входящих SSH только через особый интерфейс.

HostKey /etc/ssh/ssh_host_key

Оция HostKey определяет гда размещён персональный хост ключ.

PermitRootLogin no

Оция PermitRootLogin – может ли root входить в систему посредством ssh.

AllowUsers alice bob

Используя опцию AllowUsers вы можете выборочно отключить службу ssh для определённых пользователей Linux. Можно задать множество пользователей, разделяя их пробелами.

После того, как был изменён /etc/ssh/sshd_config , убедитесь, что перезапустили службу ssh.

Для перезапуска OpenSSH на Debian, Ubuntu или Linux Mint:

$ sudo /etc/init.d/ssh restart

$ sudo systemctl restart sshd.service

$ sudo service sshd restart

Подключение к SSH из Linux

Пользователям Linux не нужно устанавливать дополнительных программ.

Подключение к SSH из Windows

Скрыто от гостей

Cygwin – это не просто клиент SSH. Это мощный комбайн, в котором поддерживаются многие команды Linux. Например, в Cygwin очень легко создавать SSL-сертификаты (точно также, как и в Linux). В Windows для создания самоподписанных сертификатов нужно поплясать с бубном. В Cygwin очень удобно пользоваться cURL (не нужно ничего устанавливать отдельно) и т. д. Те, кому не хватает на Windows командной строки и программ Linux, в лице Cygwin найдут себе отдушину.

Установка Cygwin проста. Переходим на

Скрыто от гостей

И скачиваем

Скрыто от гостей

Скрыто от гостей

Скачается крошечный файл - это установщик. Установщик графический. Хоть он и содержит большое количество опций, все они довольно простые и многие знакомы по другим графическим установщикам. Если что-то непонятно, просто нажимайте «Далее». Пожалуй, только следующее окно может привести в замешательство:

Здесь представленные все доступные для установки элементы. Нам не нужно прямо сейчас разбираться в них. Поскольку самые востребованные уже помечены для установки. А если чего-то в будущем будет не хватать, то легко можно доустановить нужное.

Соединение SSH (общее для Linux и Windows)

Пользователи Linux открывают консоль, пользователи Windows печатают в Cygwin.

SSH нужна следующая информация для подключения:

• IP или имя хоста
• номер порта
• имя пользователя
• пароль пользователя

Ssh 192.168.1.36

Я вижу следующее

Alex@MiAl-PC ~ $ ssh 192.168.1.36 The authenticity of host "192.168.1.36 (192.168.1.36)" can"t be established. ECDSA key fingerprint is SHA256:sIxZeSuiivoEQ00RXAQHxylxuEA8SC5r/YPhL8wfp8s. Are you sure you want to continue connecting (yes/no)?

Поскольку я подключаюсь к хосту первый раз, то это незнакомый хост. У меня спрашивают, хочу ли я продолжить. Я набираю yes :

Warning: Permanently added "192.168.1.36" (ECDSA) to the list of known hosts. [email protected]"s password:

Хорошо, хост 192.168.1.36 добавлен в список знакомых хостов. У меня запрашивается пароль для пользователя Alex. Поскольку на сервере с SSH нет такого пользователя, но я нажимаю Ctrl+C (для разрыва) и ввожу команду вместе с именем пользователя удалённой системы. Пользователь вводится перед адресом удалённой машины и отделяется от адреса символом @. Символ @ на английском читается как at и можно перевести как «в». Т.е. запись [email protected] можно истолковать как «пользователь mial в машине 192.168.1.36 ».

Ssh [email protected]

Приглашение Alex@MiAl-PC сменилось приглашением mial@mint . Это означает, что мы уже на удалённой машине, т. е. у нас уже произошло соединение. Если нужно указать порт (если он отличается от стандартного), то порт нужно указывать после ключа -p. Например так:

Ssh [email protected] -p 10456

После подключения нас встречает примерно такое приветствие:

Linux mint 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Jun 16 15:32:25 2015 from 192.168.1.35

Из него следует, что удалённая машина - это Linux Mint, с ядром 3.16, 64-битная версия. Также важная информация о времени последнего входа и IP адресе с которого произошло соединение. Если время и IP вам незнакомы, а вы являетесь единственным пользователем, то ваша система скомпрометирована и нужно принимать соответствующие меры.

Наберём несколько команд, чтобы убедиться где мы и кто мы: pwd, [B]uname -a и т. д.:

Чтобы закончить сессию (отключиться), наберите

Или нажмите Ctrl+D .

Вход в SSH без ввода пароля

Во-первых, это просто удобнее. Во-вторых, это безопаснее.

Во-первых, нам нужно создать rsa ключи. Если вы пользователь Linux, то у вас всё в порядке. Если вы пользователь Windows, но вы не послушали мой совет и выбрали PuTTY, то у вас проблема и думайте сами, как её решать. Если у вас Cygwin, то всё также в порядке.

Если вы успели залогиниться на удалённой системе, разлогинтесь. После этого наберите

Ssh-keygen -t rsa

У нас спрашивают имя файла, не нужно ничего вводить, будет использовано имя по умолчанию. Также спрашивается пароль. Я пароль не ввожу.

Теперь на удалённой машине нам нужно создать каталог.ssh. Про выполнение команда на удалённой машине ещё будет рассказано ниже. Пока просто копируете команду, не забывая поменять IP адрес и имя пользователя на свои:

Ssh [email protected] mkdir .ssh

Теперь нам нужно скопировать содержимое файла id_rsa.pub на удалённую машину. Сделать это очень просто (не забываем менять данные на свои):

Cat .ssh/id_rsa.pub | ssh [email protected] "cat >> .ssh/authorized_keys"

Теперь просто логинимся и больше никакой пароль у нас не спрашивают. И так теперь будет всегда.

Выполнение команд на удалённом сервере без создания сессии шелла

Кроме открытия сессии шелла на удалённой системе, ssh также позволяет выполнять отдельные команды на удалённой системе. Например, для выполнения команды tree на удалённом хосте с именем remote-sys и отображением результатов на локальной системе, нужно сделать так:

Ssh remote-sys tree

Мой реальный пример:

Ssh [email protected] tree

Используя эту технику, можно делать интересные вещи, вроде такой, как выполнение команды ls на удалённой системе и перенаправление вывода в файл на локальной системе:

Ssh remote-sys "ls *" > dirlist.txt

Реальный пример:

Ssh [email protected] "ls *" > dirlist.txt cat dirlist.txt

Обратите внимание на одиночные кавычки в вышеприведённой команде. Это сделано потому, что мы не хотим, чтобы раскрытие пути было выполнено на локальной машине; поскольку нам нужно это выполнение на удалённой системе. Также если мы хотим стандартный вывод перенаправить в файл на удалённой машине, мы можем поместить оператор редиректа и имя файла внутри одиночных кавычек:

Ssh remote-sys "ls * > dirlist.txt"

Не менее интересный вариант выполнения команд приведён немного выше:

Cat .ssh/id_rsa.pub | ssh [email protected] "cat >> .ssh/authorized_keys"

• Команда cat построчно считывает и отображает содержимое файла.ssh/id_rsa.pub , расположенного на локальной машине.
• | (труба) передаёт то, что должно было бы появиться в стандартном выводе, другой команде.
• Вместо команды, которая должна была бы обрабатывать передаваемые ей строки, происходит соединение к удалённой системе (ssh [email protected]).
• На удалённую систему приходят строки, для которых предусмотрена команда cat >> .ssh/authorized_keys . Т.е. содержимое стандартного вывода построчно записывается в файл.ssh/authorized_keys, находящийся на удалённой машине.

Для следующего фокуса нужно два компьютера с системой Linux. К сожалению, даже Cygwin с этим трюком не справляется. Причём оба Linux"а должны быть с графическим пользовательским интерфейсом.

Туннелирование с SSH

Среди всего прочего, что происходит когда устанавливается соединение с удалённым хостом через SSH, это создание зашифрованного туннеля, который образуется между локальной и удалённой системами. Обычно, этот туннель используется для того, чтобы набранные на локальной машине команды безопасно были переданы удалённой машине, а результат, также безопасно, прислан обратно.

В добавок к этой базовой функции, протокол SSH позволяет переправлять большинство типов трафика по зашифрованному туннелю, создавая некого рода VPN (виртуальную частную сеть) между локальной и удалённой системами.

Пожалуй самая часто используемая из этих функций - это возможность транслировать трафик систем X Window. На системе с запущенным X сервером (это машины, которые имеют графический пользовательский интерфейс) возможно запустить программу X клиента (графическое приложение) на удалённой системе и видеть результаты её работы на локальной системе. Сделать это просто. Например, я хочу подключиться к удалённому хосту remote-sys и на нём я хочу запустить программу xload. При этом видеть графический вывод этой программы я смогу на локальном компьютере. Делается это так:

Ssh -X remote-sys xload

Реальный пример:

Ssh -X [email protected] gedit

Т.е. SSH запускается с ключом -X. А затем просто запускается программа. Посмотрите на скриншот.

Я нахожусь в Kali Linux. Я успешно логинюсь к удалённому компьютеру по SSH. После этого я запустил программу gedit. Этой программы, может быть, даже нет на Kali Linux, но она точно есть в Linux Mint, к которой я и подключился. Результат работы этой программы я могу видеть на экране так, будто бы программа запущена локально. Но, повторюсь, я хочу, чтобы вы это поняли, запущенной программы gedit на локальном компьютере нет. Если я захочу сохранить результат работы gedit (или любой другой программы, открытой таким образом), то окажется, что она работает в окружении удалённого компьютера, видит его файловую систему и т. д. Это удобно, когда вы хотите настроить удалённый компьютер используя графический интерфейс.

О том, как передать изображение со всего рабочего стола вы узнаете в этой же статье далее, в секции «Как настроить VNC через SSH».

На некоторых системах для этого «фокуса» нужно использовать опцию “ -Y ” вместо опции “ -X ”.

Копирование с/на удалённый компьютер (scp и sftp)

scp

Пакет OpenSSH также включает две программы, которые использует зашифрованный туннель SSH для копирования файлов по сети. Первая программа – scp («безопасное копирование») – используется чаще, как и схожая с ней программа cp для копирования файлов. Наиболее заметная разница в том, что источником файла может быть удалённый хост после которого следует двоеточие и расположение файла. Например, если мы хотим скопировать документ, названный document.txt из нашей домашней директории на удалённую систему remote-sys в текущей рабочей директории на нашей локальной системе мы можем сделать так:

Scp remote-sys:document.txt . document.txt 100% 177 0.2KB/s 00:00

Реальный пример:

# удалим файл на локальной машине, если он есть rm dirlist.txt # создадим файл на удалённой машине ssh [email protected] "ls * > dirlist.txt" # проверим его наличие ssh [email protected] "ls -l" # скопируем его на локальную машину scp [email protected]:dirlist.txt . # проверим его содержимое cat dirlist.txt

Для копирования файла с B на A когда залогинены в B:
scp /path/to/file username@a:/path/to/destination
Копирование файла с B на A когда залогинены в A:
scp username@b:/path/to/file /path/to/destination

Вторая программа для копирования файлов через SSH - это sftp . Как следует из её имени, она является безопасным заменителем ftp программ. sftp работает как и оригинальная ftp программа. Тем не менее, вместо отправки чистым текстом она использует зашифрованный туннель SSH. Важным преимуществом sftp перед ftp является то, что для неё не требуется запущенный FTP сервер на удалённом хосте. Для неё требуется только SSH сервер. Это означает, что любая удалённая машина, которая подключена через SSH клиент может также быть использована как FTP-подобный сервер. Вот пример сессии:

Alex@MiAl-PC ~ $ sftp [email protected] Connected to 192.168.1.36. sftp> ls dirlist.txt newfile.txt nfile.txt temp Видео Документы Загрузки Изображения Музыка Общедоступные Рабочий стол Шаблоны sftp> lls dirlist.txt nfile.txt sftp> ls temp temp/TakeMeHome sftp> cd temp/ sftp> get TakeMeHome Fetching /home/mial/temp/TakeMeHome to TakeMeHome sftp> bye

SFTP протокол поддерживается многими графическими файловыми менеджерами, которые можно найти в дистрибутивах Linux. Используя как Nautilus (GNOME), так и Konqueror (KDE), мы можем вводить URI (ссылки) начинающиеся на sftp:// в строку перехода и работать с файлами, расположенными на удалённой системе с запущенным SSH сервером.

Эта статья помечена как незаконченная. См. заметку в конце статьи.

Данная статья посвящена клиенту и серверу защищенного терминала (secure shell) в Ubuntu, их настройке и использованию. SSH - это специальный сетевой протокол, позволяющий получать удаленный доступ к компьютеру с большой степенью безопасности соединения. Более подробно про протокол ssh можно прочитать .

Описание принципов работы и используемых приложений

В основном, SSH реализован в виде двух приложений - SSH -сервера и SSH -клиента В Ubuntu используется свободная реализация клиента и сервера SSH - OpenSSH . При подключении клиент проходит процедуру авторизации у сервера и между ними устанавливается зашифрованное соединение. OpenSSH сервер может работать как с протоколом ssh1, так и с протоколом ssh2. В настоящее время протокол ssh1 считается небезопасным, поэтому его использование крайне не рекомендуется. Я намеренно опускаю различные технические подробности работы протокола, т. к. основной целью данного руководства является описание его настройки и использования. Про сам протокол, принципы его работы, алгоритмы шифрования и т. д. существует множество статей в интернете, например подробно про это можно почитать .

Установка

Установить OpenSSH можно из терминала командой:

В метапакете ssh содержится как клиент, так и сервер, но при этом, скорее всего, будет установлен только сервер, т. к. клиент уже есть в Ubuntu по умолчанию.

Настройка сервера

При установке SSH -сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:

Основной файл конфигурации 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 выполнять скрипты, то оставляем пустым. Передаём публичный ключ на сервер командой

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

Монтирование удаленного каталога в локальный каталог

Размонтирование

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-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) так и у другого пользователя, что позволит ему выполнять со своего компьютера вход как «под собой», так и под «другим»

Вы приобрели свой первый VPS, а может даже сразу сервер. Наверняка у вас есть веб панель для его администрирования. Но тру админы, всегда ходят через консоль 😉 Поэтому надо научиться это делать. В этом уроке мы установим программу PuTTY, подключимся к серверу по SSH протоколу, и научимся определять занятое и свободное пространство на сервере.

Программа Putty для соединения с сервером по SSH протоколу

Скачиваем Putty с сайта putty.org Для себя я скачиваю версию «For Windows on Intel x86 — PuTTY: putty.exe»

Распаковываем архив, запускаем программу.

Вот так выглядит окно программы после запуска. Я уже ввел IP адрес своего сервера в поле «Host Name (or IP address)»:

Вводим домен или IP адрес своего сервера и нажимаем кнопку «Open». Открывается окно командной строки. Оно запрашивает у нас логин и пароль пользователя. Вначале вводим логин, затем, пароль. Внимание, во время вода пароля — символы на экране не печатаются, не печатаются даже звездочки ***. Поэтому пароль вводим как бы вслепую. Вводим и нажимаем Enter. Если пароль ввели верно, то происходит вход в консоль управления сервером. Выводится строка с временем последнего входа, и информация о операционной системе.

Команды в консоли

pwd

df

Команда df показывает размер свободного и занятого пространства на сервере, во всех смонтированных файловых системах

du

Команда du показывает сколько места занимает папка или файл.
Пример команды:

Du -h /home/

Эта команда покажет сколько места занимает директория /home/

На этом все. Первое знакомство с подключением к серверу по SSH и программой putty закончено. Используя эту информацию можно зайти на сервер, и посмотреть сколько места занимают данные на нем.