Как пользоваться протоколом SSH в Ubuntu: установка и настройка. Использование SSH для подключения к удаленному серверу Ubuntu Установка и подключение ssh в терминале linux

В этой статье мы покажем вам, как установить, настроить и использовать OpenSSH на Ubuntu 16.04. SSH (Secure Shell) является протоколом, который позволяет получить надежный доступ к удаленной машине в то время как OpenSSH представляет собой набор инструментов на основе протокола SSH. Сегодня мы покажем вам, как установить и настроить OpenSSH на с помощью Ubuntu 16.04 в качестве операционной системы.

Установка OpenSSH на Ubuntu 16.04

Во-первых, давайте установим OpenSSH. Обновите индексы пакетов с помощью следующей команды:

Sudo apt-get update

Для установки приложения сервера OpenSSH, а также других связанных пакетов используют следующую команду:

Sudo apt-get install openssh-server

Обратите внимание, что пакет сервера OpenSSH может быть уже установлен в вашей системе, как часть процесса первоначальной установки сервера. Кроме того, вы можете установить клиентское приложение OpenSSH с помощью следующей команды:

Sudo apt-get install openssh-client

Настройка OpenSSH на Ubuntu 16.04

Перед внесением каких – либо изменений в конфигурации OpenSSH, хорошо знать, как управлять услугой OpenSSH на вашем . Для запуска службы вы можете использовать следующую команду:

Sudo systemctl start sshd.service

Чтобы остановить службу, вы можете использовать:

Sudo systemctl stop sshd.service

Чтобы перезапустить службу, вы можете использовать:

Sudo systemctl restart sshd.service

Чтобы проверить состояние службы вы можете использовать:

Sudo systemctl status sshd.service

Чтобы включить службу на время загрузки системы вы можете использовать:

Sudo systemctl enable sshd.service

Чтобы отключить службу на время загрузки системы вы можете использовать:

Sudo systemctl disable sshd.service

После внесения каких-либо изменений в конфигурации OpenSSH вам необходимо перезапустить службу, чтобы изменения вступили в силу.

Основной конфигурационный файл для приложения сервера OpenSSH это /etc/ssh/sshd_config . Убедитесь, что вы создали резервную копию исходной конфигурации перед внесением каких – либо изменений:

Sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

Вы можете редактировать этот файл с помощью текстового редактора по вашему выбору. Первое, что вы можете сделать, это . Откройте файл и найдите строку, которая определяет порт прослушивания:

Измените ее на что-то другое. Например 2022

Port 2022

Сохраните файл и закройте его. Затем перезапустите службу, чтобы изменения вступили в силу.

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

Безопасный OpenSSH на Ubuntu 16.04

#PermitRootLogin yes

и измените его на:

PermitRootLogin no

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

Чтобы защитить сервер, вы еще можете отключить проверку пароля и . Кроме того, вы можете .

Дополнительные опции конфигурации вы можете проверить с помощью страницы man:

Man sshd_config

или вы можете посетить страницы вручную OpenSSH на https://www.openssh.com/manual.html.

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

Что такое SSH?

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

Он позволяет создавать шифрованные туннели для безопасной передачи других сетевых протоколов через незащищенную сеть, например, Интернет. Часто его используют для перенаправления портов одного компьютера на порты другого.

Начало SSH было положено Тату Илёненом из Финляндии в 1995 году, который задействовал его как более конфиденциальный протокол. Эта версия была названа SSH-1. На данный момент практически нигде не используется.

В 1996 году была разработана усовершенствованная версия SSH-2. Она несовместима с SSH-1, более защищенная и имеет расширенный список алгоритмов шифрования. Сейчас под SSH понимается именно версия SSH-2. С 2006 года протокол признан интернет-стандартом ассоциацией IETF.

Существует две основных реализации SSH. Одна из них проприетарная, которая разрабатывается SSH Communications Security. Вторая - OpenSSH, созданная под руководством Тео де Раадта как свободная открытая альтернатива первой. Является самой распространенной и включена в поставку большинства Unix-подобных систем.

Что такое клиент SSH и сервер SSH

Подключение по протоколу SSH реализуется с помощью двух основных компонентов: клиента и сервера.

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

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

Безопасный доступ организуется с помощью процедуры аутентификации с использованием асимметричного шифрования с публичным ключом при первом подключении. При последующем применяется симметричное шифрование.

Стандарт SSH включает в себя три протокола:

  • Протокол транспортного уровня - гарантирует аутентификацию сервера, секретность и целостность. Обеспечивает сжатие данных. Работает поверх TCP/IP.
  • Протокол аутентификации — исполняет аутентификацию клиента для сервера. Действует поверх уровня транспортного протокола.
  • Протокол соединения — представляет зашифрованный канал в виде мультиплексированного канала из нескольких логических, используемых для разных служб. Работает поверх канала аутентификации.

Повышение безопасности гарантируется аутентификацией клиента для сервера, к которому обращается клиент ssh и аутентификацией сервера клиентом. Происходит аутентификация обеих сторон.

Клиент шлет запрос в первый раз, когда устанавливается безопасное соединение транспортного уровня. Второй запрос направляется после завершения аутентификации SSH-клиента.

Реализация OpenSSH

OpenSSH — это открытая реализация команды OpenBSD. Является самой распространенной версией благодаря свободному распространению.

Пакет OpenSSH включает набор таких инструментов:

  • SSHD — серверная часть.
  • SSH — клиентская часть.
  • SCP — утилита для защищенного копирования файлов.
  • SSH-keygen — генерирует открытые ключи (RSA, DSA и другие) для компьютеров и пользователей.
  • SSH-keyscan — собирает публичные ключи в сети.
  • SSH-agent — хранит личные RSA ключи для последующей авторизации с публичными ключами.
  • SSH-add — добавляет новые личные ключи агенту SSH-agent.
  • SFTP-server — SFTP сервер.
  • SFTP — утилита для безопасного копирования файлов по FTP.

OpenSSH включен в поставку из коробки для большинства Unix-подобных систем. Самые распространенными считаются Linux, Open (Free, Net) BSD, Solaris, HP-UX, Irix, MacOS X и другие.

Активная разработка ведется в реализации OpenSSH for Windows, которая доступна для скачивания насайте. Она позволяет создавать SSH-сервер в системах семейства Windows, имеет клиент SSH для подключения. OpenSSH for Windows включен в поставку CygWin.

Наиболее популярными среди пользователей являются дистрибутивы на базе ядра Linux. В дальнейшем все примеры использования SSH будут подразумеваться в настройке OpenSSH. Для наглядности работы в Linux будет настроен SSH-клиент для Ubuntu, Windows и Mac OS X.

Установка и настройка openssh-server

Существует множество вариантов конфигурации OpenSSH -server. Настройка клиента должна производиться исходя из конфига сервера. В этом разделе приведен пример сервера SSH, установленного на Ubuntu Server Edition. При последующих описаниях настройки клиентов будет использоваться конфигурация этого сервера.

1. Есть два способа установки OpenSSH -server:

1.1. Выбрать установку пакета OpenSSH -server сразу же в процессе разворачивания Ubuntu Server/

1.2. Скачать и установить из репозитория, выполнив команду:

2. Ознакомиться со значениями конфигурация сервера SSHD по умолчанию в файле /etc/ssh/sshd_config можно командой:

3. Перед изменением стандартных настроек обязательно нужно создать резервную копию файла и защитить его от записи. Это делается на тот случай, если потребуется откат до значения по умолчанию в случае ошибки.

4. В настройках по умолчанию установлен 22. Для безопасности рекомендуется заменять его нестандартным значением, например, 5754. Изменить директиву Port можно командой:

5. Сохраните файл/etc/ssh/sshd_config и перезапустите SSHD:

Сервер установлен и настроен. Теперь он прослушивает порт 5754. По умолчанию получить доступ может любой пользователь системы с правами на вход. Аутентификация производится с помощью пароля или ключей DSA, RSA, ed25519 и др.

Кросплатформенный OpenSSH-client для терминала. SSH клиент для Linux

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

В составе пакетов OpenSSH-клиент реализован в виде программы SSH, которая запускается одноименной командой. Настройка и управление клиентом производится через терминал, он не имеет графического интерфейса. Считается самой простой и удобной версией.

Установка и настройка OpenSSH-client на Ubuntu

На удаленной машине имеется установленный и сконфигурированный OpenSSH-server. Задача состоит в том, чтобы получить к нему доступ с локального компьютера, на котором установлена Ubuntu.

1. В Ubuntu по умолчанию не добавлен дистрибутив OpenSSH-client, поэтому установить его необходимо командой:

2. После она вызывается командой SSH из терминала без Root.

3. В случае если используется аутентификация пользователей по паролю:

1) подключение производится командой:

  • username — имя учетной записи на удаленной машине,
  • host — это IP-адрес удаленного сервера (или домен, если домен был делегирован на сервер);

2) после ввода команды необходимо нажать Enter - появится запрос на ввод пароля; требуется ввести пароль от учетной записи удаленной машины (следует быть внимательным, так как для безопасности ввод пароля никак не отображается);

3) после правильного ввода пароля появляется окно терминала удаленного сервера с приветствием; теперь можно выполнять необходимые команды.

1) при необходимости сгенерировать открытый и закрытый ключи SSH можно из OpenSSH-client:

2) по умолчанию публичный ключ сохраняется в файл /home/user/.ssh/id_dsa.pub, а закрытый в /home/user/.ssh/id_dsa;

3) сгенерированный публичный ключ необходимо скопировать на удаленную машину и добавить его к авторизации /home/user/.ssh/authorized_keys командой:

Теперь пользователь может идентифицироваться на SSH-сервере без ввода пароля.

Установка и настройка OpenSSH для Cygwin Terminal на Windows

Установка Cygwin производится запуском файла Cygwin.exe, который скачивается с официального сайта.

Cygwin — это сборка множества разных пакетов. Для работы с удаленным терминалом требуется только OpenSSH. Найти его можно с помощью поиска в самом Cygwin.

После установки пакета нужно запустить Cygwin Terminal и ввести команду:

После чего нажать Enter. Появится запрос на ввод пароля. После прохождения аутентификации появляется терминал удаленного сервера с приветствием пользователя.

Синтаксис точно такой же, как и в OpenSSH-client, реализованном для Linux.

Кроссплатформенный SSH-клиент с графическим интерфейсом PuTTY

Putty — графический клиент SSH для удаленного администрирования, включающий в себя поддержку протокола SSH. Программа распространяется с открытым кодом и абсолютно бесплатная.

Изначально выпускался только для OS Windows, но позже клиент был портирован для Linux, входит в репозитории практически всех популярных дистрибутивов.

Активно разрабатывается для работы в Mac OS X.

Окно настройки PuTTY выглядит одинаково во всех операционных системах. Разница существует только в способах установки. Поэтому сначала будут приведены способы установки для трех операционных систем, а затем - параметры настройки PuTTY.

Установка PuTTY Linux Ubuntu

1. Установить PuTTY можно командой:

2. Запуск выполняется командой putty из терминала или кликом мыши из меню:

3. Открывается окно настроек клиента, где необходимо прописать параметры соединения.

Установка PuTTY для Windows

Для установки потребуется скачать файл putty.exe, сохранить в удобное место, например, на рабочий стол. Программа запускается двумя кликами левой кнопки мыши.

PuTTY — SSH-клиент для Mac. Установка и запуск GUI-версии

На момент написания статьи PuTTY не был адекватно портирован для работы в Mac OS X. Проблемы возникали на компиляции той части, которая отвечает за графический интерфейс.

Для установки следует выполнить некоторые предварительные работы.

1. Установить Xcode.

Пакет утилит и программы от Apple для разработки и сборки приложений под Mac OS X.

С версии Mac OS Lion необходимо поставить «Command Line Tools for Xcode» с сайта Apple Developer.

После установки требуется принять соглашение о лицензии:

2. Установить Xquartz.

Это реализация сервера X.Org X Window System (X11) для Mac OS X. Требуется для GUI-версии PuTTY, написанного на GTK+. Установить можно с официального сайта. После установки потребуется релогин.

3. Установить Homebrew.

4. Установка Putty выполняется командой:

Процесс может занять больше получаса, так как будет установлено множество зависимостей вроде Glib/GTK+/Pango/Cairo.

5. Создание файла запуска Putty.app.

Необходимо запустить Automator.app. В типе документа выбрать «программа», в действиях нужно выбрать «запустить shell-скрипт», в поле ввода прописать путь до исполняемого файла «/user/local/bin/putty», сохранить как «putty.app», указав формат файла «программа», в директорию «программы». При желании стандартную иконку можно заменить.

Настройка SSH клиента PuTTY

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

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

Connection Type — тип соединения — устанавливается SSH.

Host Name (or IP-adress) — имя хоста, или IP-адрес — здесь указывается IP-адрес удаленного сервера, доменное имя или адрес в интернете. В приведенном примере указан IP-адрес 192.168.128.3

Port — прослушиваемый порт — на сервере, который был приведен в качестве примера, настроен порт 5754. Его и указываем.

При нажатии кнопки "Open" появится окно терминала, где потребуется ввести имя учетной записи удаленной машины и пароль.

В случае необходимости аутентификации клиента парой ключей потребуется утилита puttygen.exe, которая запускается в ОС Windows. PuTTY-Gen генерирует свою пару ключей public и private.

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

Приватный ключ генерируется формата.ppk и добавляется в клиент. Слева в дереве нужно найти SSH, развернуть список, найти Auth и в этом параметре в поле «Private key file for Authentication» выбрать ключ.

После этих манипуляций пользователь может проходить аутентификацию на сервере без ввода пароля.

На данный момент PuTTY считается универсальным клиентом SSH с графическим интерфейсом. Сторонние разработчики Gao-Feng создали SSH-клиент для Android, как мобильную версию PuTTY.

Лучший SSH-клиент

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

Как правило, пользователи *Unix-систем склоняются к использованию стандартного SSH из пакета OpenSSH. Он обладает понятным универсальным синтаксисом и доступен напрямую из терминала. Для работы с дополнительными инструментами вроде защищенного копирования файлов (SCP) не требуется устанавливать дополнительные программы. Все необходимое включено в OpenSSH.

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

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

Данная статья посвящена клиенту и серверу защищенного терминала (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 AliasName

ssh-agent

Диагностика проблем подключения

    Анализ лога подключения:

ssh -vvv user@ host

    Анализ конфигурационных файлов клиента и сервера.

Расположение конфигурационных файлов можно узнать из

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

Спасибо MadKox

Пример конфигурационного файла

# Условные обозначения: #
# Под "по умолчанию" подразумевается поведение sshd при #
# неуказанной явно директиве. Стоит заметить, что в Ubuntu #
# файл sshd_config уже содержит ряд настроек, которые #
# являются настройками по умолчанию для именно для Ubuntu. #
# Такие настройки указаны в этом файле. #
# #

################ Настройки адресов/портов и т.д. ###########
############################################################
# #
## Port ####################################################
# #
# Используемый порт. Можно указывать несколько, например: #
# Port 22 #
# Port 23 #
# Port 24 #
# Рекомендуется использовать нестандартный порт, т.к. #
# стандартный часто сканируется ботами на предмет #
# потенциальных "дырок". Может быть опущен, если задан #
# через адрес. См. также параметр ListenAddress. #
# #
Port 8022
# #
## 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. #

# #
############################################################
############# Настройки доступа пользователей ##############
############################################################
# #
# Пустить/не пустить пользователя определяется директивами #
# 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 #
# задан равным
5 и ClientAliveCountMax оставлен по #
# умолчанию, неотвечающие клиенты будут отключены примерно #
# через 45 секунд. Эта директива работает только для #
# протокола ssh2. #
# #
## ClientAliveInterval #####################################
# #
# Задает временной интервал в секундах. Если в течении #
# этого интервала не было обмена данными с клиентом, sshd #
# посылает сообщение по зашифрованному каналу, #
# запрашивающее ответ от клиента. По умолчанию 0, т.е. #
# не посылать таких сообщений. Эта директива работает #
# только для протокола ssh2. #
# #
############################################################
################ Общие опции аутентификации ################
############################################################
# #
## AuthorizedKeysFile ######################################
# #
# Указывает файл, в котором содержатся публичные ключи, #
# используемые для аутентификации пользователей. Директива #
# может содержать маркеры вида %М, которые подставляются в #
# процессе установки соединения. #
# Определены следующие маркеры: #




# Таким образом, файл с ключами может быть задан как #
# абсолютным путем (т.е. один общий файл с ключами), так и #
# динамически в зависимости от пользователя (т.е. по #
# файлу на каждого пользователя). #
# По умолчанию “.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 #
# в процессе аутентификации, основанной на проверке хоста. #

# Файлы /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 no
# #
## 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”. #
# #
PasswordAuthentication yes
#
## HostKey #################################################
# #
# Указывает файл, содержащий закрытый хост-ключ, #
# используемый SSH. По умолчанию /etc/ssh/ssh_host_key #
# для протокола ssh
и /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. #

# По умолчанию “no”. #
# #
RhostsRSAAuthentication no
# #
## RSAAuthentication #######################################
# #
# Указывает, разрешена ли "чистая" RSA-аутентификация. #
# Актуально только для протокола ssh1. #
# По умолчанию “yes”. #
# #
RSAAuthentication no
# #
## ServerKeyBits ###########################################
# #
# Определяет число бит во временном ключе сервера для #
# протокола ssh1. Минимальное значение 512. #
# Значение по умолчанию 1024. #
ServerKeyBits 1024
# #
############################################################
########### Опции протокола 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 доступ, т.к. они всегда смогут установить #
# свои собственные аналоги агента. #
# #
AllowAgentForwarding no
# #
## AllowTcpForwarding ######################################
# #
# Указывает, разрешить или запретить перенаправление TCP. #
# По умолчанию “yes”, т.е. разрешить. Стоит заметить, #
# что как и в случае с AllowAgentForwarding отключение #
# перенаправления не увеличит безопасности, пока у #
# пользователей будет консольный доступ, т.к. они смогут #
# установить свои аналоги. #
# #
# #
AllowTcpForwarding no
# #
## GatewayPorts ############################################
# #
# Указывает, разрешать ли удаленным хостам доступ к #
# перенаправленным портам. По умолчанию, sshd слушает #
# соединения к перенаправленным портам только на локальном #
# интерфейсе (loopback). Это не дает другим удаленным #
# хостам подсоединяться к перенаправленным портам. Можно #
# использовать GatewayPorts, чтобы разрешить sshd это #
# делать. Директива может принимать 3 значения: #
# "no" только loopback. #
# "yes"- любые адреса. #
# "clientspecified" адреса указанные клиентом. #
# #
GatewayPorts no
# #
## 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 и DEBUG
эквивалентны друг другу. #
# DEBUG2 и DEBUG3 задают самые высокие уровни отладочного #
# вывода. Запись логов с уровнем DEBUG угрожает #
# приватности пользователей и не рекомендована. #
# #
LogLevel INFO
# #
############################################################
################### Перенаправление X

####################
############################################################
# #
## X11Forwarding ###########################################
# #
# Указывает, разрешено ли перенаправление графической #
# подсистемы X11. Может принимать значения “yes” или “no”. #
# По умолчанию “no”. #
# Внимание включение простого перенаправления Х11 #
# большой риск как для сервера, так и для клиентов, т.к. в #
# случае такого перенаправления прокси-дисплей sshd #
# принимает соединения с любых адресов. Используйте #
# директиву X11UseLocalhost для ограничения доступа к #
# серверу перенаправления "иксов". Стоит отметить, что #
# отключение перенаправления не даст гарантии, что #
# пользователи не смогут перенаправлять Х11, т.к. имея #
# консольный доступ они всегда установить свой #
# перенаправлятель. Перенаправление Х11будет #
# автоматически отключено, если будет задействована #
# директива UseLogin. #
# #
X11Forwarding no
# #
## X11UseLocalhost #########################################
# #
# Указывает, должен ли sshd ограничить область #
# перенаправления Х11 локальным loopback адресом, или #
# должен разрешить любые адреса. По умолчанию sshd #
# "сажает" сервер перенаправления Х11на локальный адрес #
# и задает часть переменной окружения DISPLAY, отвечающую #
# за имя хоста как “localhost”. Стоит заметить, что #
# некоторые старые клиенты Х11могут не работать с такими #
# настройками. По умолчанию "yes", т.е. перенаправление #
# ограничено локалхостом, значение “no” отключает #
# ограничения. #
# #
## XAuthLocation ###########################################
# #
# Указывает полный путь к программе xauth. #
# По умолчанию /usr/bin/X11/xauth. #
# #
## X11DisplayOffset ########################################
# #
# Указывает номер первого дисплея, доступного sshd в #
# качестве перенаправления X11. Это сделано для того, #
# чтобы перенаправленные "иксы" не пересекались с #
# реальными. По умолчанию 10. #
# #
X11DisplayOffset10
# #
############################################################
################### Различные опции ########################
############################################################
# #
## LoginGraceTime ##########################################
# #
# Время, по прошествии которого сервер отключает #
# пользователя, если тот не смог удовлетворительно #
# залогиниться. Значение 0 разрешает пользователю #
# логиниться бесконечно. По умолчанию 120 (секунд). #
# #
LoginGraceTime 120
# #
## MaxAuthTries ############################################
# #
# Указывает максимальное число попыток аутентификации, #
# разрешенное для одного соединения. #
# Как только число неудачных попыток превысит половину #
# заданного значения, все последующие попытки будут #
# заноситься в журнал. Значение по умолчанию 6. #
# #
MaxAuthTries 4
# #
## MaxSessions #############################################
# #
# Указывает максимальное число одновременных подключений #
# для каждого сетевого соединения. По умолчанию 10. #
# #
MaxSessions1
# #
## 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 #

Сразу небольшая ремарка к конфигу в нем отключена возможность по ssh логинеться под пользователем root, поэтому если вы "любитель " поправьте настройку PermitRootLogin на yes

Для копирования выше указаного конфига на вашу unix машину
Перейдите в католог где хранится конфигурационный файл sshd_config

Sudo cd /etc/ssh

Поскольу мы сделали резервную копию файла sshd_config удалим его

Sudo rm sshd_config

Все еще находясь в директории /etc/ssh скопируем с сайта itautsors выше указаный файл конфигурации ssh,

Sudo wget http://сайт/sshd_config

Перезапустим демон

Sudo service ssh restart

Убедимся что демон SSH запущен

Ps -A | grep sshd

Увидим что то подобное

<какой то номер> ? 00:00:00 sshd

Если строки нет то SSH демон не запущен,

Проверим прослушиваются ли входящие соединения:

Sudo ss -lnp | grep sshd

В ответ получим

0 128:::22:::* users:(("sshd",16893,4)) 0 128 *:22 *:* users:(("sshd",16893,3))

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

Попробуем войти с локального компьютера (то есть заходим с того же ПК на котором настраиваем ssh server, так сказать первоначальная проверка), (помним что у нас порт не стандартный 8022):

Ssh -v localhost -p 8022

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

Настроим доступ к OpenSSH Server с OpenSSH Client с авторизацией по ключу

Дано: Хост OpenSSH Server на который в будущем хотим логинется по ssh под пользователем NameUserOnOpenSSHServer с хоста OpenSSH Client Сгенерируем пару ключей на Хосте с которого мы хотим подключится (OpenSSH Client). Проверьте может пара ключей уже сгенерирована.
Согласившись с местом сохранения ключа (/home/NameUserOnOpenSSHClient/.ssh/id_rsa), пароль можно оставить пустым тогда при аутентификации по сертификату не нежно будет вводить пароль что менее надежно но намного удобнее (в нашем примере вводить пароль не будем):

Ssh-keygen -t rsa -b 4096

В домашней папке ~/.ssh пользователя под которым запускали генерецию (в нашем примере NameUserOnOpenSSHClient ) на хосте OpenSSH Client появятся файлы:

~/.ssh/id_rsa.pub публичный
~/.ssh/id_rsa приватный

Выставим права на папку и файлы
Без разницы под каким пользователем мы будем запускать генерацию на OpenSSH Client, единственное логинется на удаленную машину OpenSSH Server нужно будет под этим пользователем так как права будут высталены следующие (такие права необходимо выставить что бы не был скомпроментирован приватный ключ) :

$ chmod 0700 ~/.ssh/ $ chmod 0600 ~/.ssh/id*

Передадим публичный ключ с клиента на сервер для пользователя под которым находимся, командой ssh-copy-id в файл ~/.ssh/authorized_keys, если порт на котором слушает сервер не стандарный, необходимо его прописать используя ключ -p и заключить в кавычки. Ключ можно передать любым способом потому что он публичный.

Ssh-copy-id "-p 8022 NameUserONOpenSSHServer@ipAdressOpenSSHServer"

NameUserOnOpenSSHServer - это тот пользователь под которым мы будем в будущем логинется на удаленной машине.
Далее необходимо ввести пароль пользователя NameUserONOpenSSHServer, и после удачной авторизации увидим подсказку:

Now try logging into the machine, with "ssh "NameUserONOpenSSHServer@ipAdressOpenSSHServer"", and check in: ~/.ssh/authorized_keys to make sure we haven"t added extra keys that you weren"t expecting.

Логинемся на Хост через ssh и проверяем содержания файла (в этом файле могут быть прописаны и другие ключи, ищем наш.) NameUserONOpenSSHServer/.ssh/authorized_keys :

Sudo ssh "NameUserONOpenSSHServer@ipAdressOpenSSHServer" sudo cat /home/NameUserONOpenSSHServer/.ssh/authorized_keys

Он должен совподать с содержимым файла NameUserONOpenSSHClient/.ssh/id_rsa.pub

Sudo cat /home/NameUserONOpenSSHClient/.ssh/id_rsa.pub

Sudo mcedit /etc/ssh/sshd_config

Жмем F7, ищем PubkeyAuthentication, RSAAuthentication, AuthorizedKeysFile
должно быть раскоментированы строчки/выставлены параметры (проверяем):

# разрешаем использование RSA ключей RSAAuthentication yes # если используете SSH1 не желательно # разрешаем авторизацию при помощи ключей PubkeyAuthentication yes # Путь где будут находиться ключи, с которыми можно соединяться для каждого пользователя свой файл в его директории. AuthorizedKeysFile %h/.ssh/authorized_keys

Перезапустим сервер SSH

Sudo service ssh restart

Выставляем права на файл /home/NameUserOnOpenSSHServer/.ssh/authorized_keys

Chmod 0600 ~/.ssh/authorized_keys

Выходим из консоли OpenSSHServer, пробуем залогинится с клиента на сервер использую сертификат, вводим строчку и должны попасть в консоль OpenSSHServer без ввода паролья (если при генерации ключей вы не вводили пароль)

Ssh NameUser@ipAdressOpenSSHServer

В этой статье вы узнаете как установить, включить и настроить SSH в Ubuntu Linux.

OpenSSH – это свободно доступная версия семейства протоколов Secure Shell (SSH) для удаленного управления или передачи файлов между компьютерами.

Традиционные инструменты, используемые для выполнения таких функций, как telnet или rcp, небезопасны и передают пароль пользователя в текстовом формате при его использовании. OpenSSH предоставляет серверный демон и клиентские инструменты для обеспечения безопасного, зашифрованного дистанционного управления и операций передачи файлов, эффективно заменяя устаревшие инструменты.

Серверный компонент OpenSSH, sshd, постоянно прослушивает клиентские соединения с любого из клиентских инструментов. Когда возникает запрос на соединение, sshd устанавливает правильное соединение в зависимости от типа подключения клиентского инструмента. Например, если удаленный компьютер подключается к клиентскому приложению ssh, сервер OpenSSH устанавливает сеанс удаленного управления после аутентификации. Если удаленный пользователь подключается к серверу OpenSSH с помощью scp, демон сервера OpenSSH инициирует безопасную копию файлов между сервером и клиентом после аутентификации. OpenSSH может использовать множество методов проверки подлинности, включая простой пароль и открытый ключ.

Как установить OpenSSH

Чтобы установить OpenSSH, откройте терминал и введите следующие команды

Sudo apt-get update sudo apt-get install openssh-server -y

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

Sudo systemctl status ssh

Вы должны увидеть что-то вроде Active: active (running): Это означает, что SSH установлен и запущен в вашей системе Ubuntu.

Конфигурация

Можно изменить конфигурацию поведения сервера OpenSSH по умолчанию, отредактировав файл /etc/ssh/sshd_config.

Но перед редактированием файла конфигурации вы должны сделать копию исходного файла и защитить его от записи, чтобы у вас были исходные настройки в качестве ссылки чтобы можно было повторно использовать этот файл при необходимости.

Скопируйте файл /etc/ssh/sshd_config и защитите его от записи с помощью следующих команд:

Sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original sudo chmod a-w /etc/ssh/sshd_config.original

А теперь откройте файл для редактирования

Sudo apt-get install nano -y sudo nano /etc/ssh/sshd_config

Для получения информации о директивах конфигурации, используемых в этом файле, вы можете просмотреть соответствующую страницу руководства с помощью следующей команды:

Man sshd_config

Ниже приведены примеры директив конфигурации, которые вы можете изменить:

Чтобы настроить OpenSSH на прослушивание например через порт 2222 вместо стандартного TCP-порта 22, измените директиву порт на: Port 2222

Чтобы sshd разрешал учетные данные для входа на основе открытого ключа, просто добавьте или измените строку: PubkeyAuthentication yes – Если строка уже присутствует, убедитесь, что она не закомментирована.

Чтобы ваш сервер OpenSSH отображал содержимое файла /etc/issue.net в качестве баннера перед входом в систему, просто добавьте или измените строку: Banner /etc/issue.net . В файле /etc/ssh/sshd_config.

После внесения изменений в файл /etc/ssh/sshd_config сохраните файл и перезапустите приложение-сервер sshd, чтобы выполнить изменения, используйте следующую команду в терминале:

Sudo systemctl restart sshd.service

Набор OpenSSH состоит из следующих инструментов:

  • Удаленные операции выполняются с использованием ssh, scp и sftp.
  • Управление ключами – ssh-add, ssh-keysign, ssh-keyscan и ssh-keygen.
  • Службы состоят из sshd, sftp-server и ssh-agent.

И например, чтобы подключится к удаленному серверу, используйте следующую команду:

Ssh user@serverip

Эта команда соединяет вас с вашим сервером, который имеет свой IP адрес serverip и имя пользователя user .

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