Ssh настройка ubuntu подключения с паролем. SSH — настройка доступа к серверу, команды и подключение без паролей

В этой статье расскажем вам как установить SSH в Linux, Windows и Mac, как настроить и как пользоваться! Все до мелочей! Будет интересно!

SSH — это популярный протокол для удаленного управления (администрирования) операционных систем на ядре Linux, Unix. Для новичков Linux не совсем понятно установка данного протокола, настройка и использование, чтобы это исправить было решено написать данную статью!

Одной из самых популярных операционных систем работающих на ядре Linux является Ubuntu, поэтому объяснять о ssh будем именно на ней.

Сначала все действия мы объясним на примере с Linux, а после и в Mac и Windows!

Установка SSH в ОС Linux

В 99,99% случаях в Linux уже установлен ssh клиент, с помощью которого можно подключиться к удаленной машине. Но если вы хотите чтобы подключились к компьютеру за которым вы сейчас находитесь или на любой другой, необходимо «скачать ssh сервер».

Сделать это очень просто, все необходимое уже есть в репозиториях (а-ля магазин программ), откройте терминал и введите команду:

Sudo apt install openssh-server

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

Подключение по SSH (с паролем)

Откройте терминал и введите команду для подключения к удаленной машине:

Ssh ИмяПользователя @IPадрес

Вначале пишем ssh , потом имя пользователя который есть на удаленной машине, далее знак @ (собачка) и IP адрес. Вот например:

Ssh sasha@ 100.08.30.48

Как правило, ssh подключение происходит к порту 22, если вы его принудительно изменили, то нужно его указать. Для этого в конце пишем -p номер. Вот пример:

Ssh sasha@ 100.08.30.48 -p 3040

После того как вы подключились и если это было первое подключение к машине, вам необходимо будет, добавить машину в доверенные — напишите yes и нажмите Enter. Выполняется это один раз.

Создание SSH-ключа и подключение без пароля!

Для того чтобы не запоминать пароль и каждый раз его не вводить, особенно если у вас множество Linux серверов можно создать специальный SSH-ключ. Этот ключ позволит подключаться с уже «известной» машины с «известным» сервером, без использования пароля.

Как создать ключ SSH?

На компьютере за которым вы сейчас находитесь создаем ключ, а после, его необходимо будет скопировать на наш сервер!

Создаем ключ за текущим компьютером:

Ssh-keygen -t rsa

Ключ создан, теперь его необходимо добавить на удаленную машину или сервер.

Как добавить SSH-ключ на сервер?

Для этого вводим команду:

Ssh-copy-id sasha@ 100.08.30.48

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

Клиент SSH Windows

Одной из самых популярных программ для работы c Linux серверами по SSH в Windows является программа Putty. Скачать данный SSH клиент Windows можно по данному адресу — putty.org .

Подключение по SSH по паролю в Windows

Подключение в Putty по SSH очень простое! Вводим IP адрес, если меняли порт, то указываем другой порт и нажимаем Open:
и после подключения логин и пароль!

Подключение по SSH по ключу в Windows

Если вам не хочется вводить каждый раз пароль, а использовать ключ ssh в Putty, то, как и в Linux, сначала необходимо создать ключ, а после перенести его на сервер.

Создаем ключ

Программу пока не закрываем и запускаем Putty для подключения

Перенос ключа

Mac SSH Client

Так как macOS основана на UNIX системе, то подключатся по ssh можно прямо из терминала!

Если есть желание не использовать пароль, то необходимо вначале установить Homebrew:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Есть также удобный mac ssh client — Termius .

SSH клиент android и iOS

Наиболее удобным клиентом SSH для iOS и Android является приложение Termius!

Передача и скачивание файлов по SSH (SCP)

Для того чтобы закачать файл с локальной машины на сервер по ssh в Linux и macOS:

Scp file1.tar root@ip_adress:/home/dir

Копирование файла с сервера на локальный компьютер Linux или macOS:

Scp userName@ip_adress:/home/file1.tar /var/www/

C сервера, на сервер:

Scp user@server_ip1:/home/file.txt user@server_ip2:/home/

Для Windows

Для перемещения файлов по SSH в Windows используется pscp .

pscp.exe file.zip root@ip_server: /var/www/

Настройка SSH

Если необходимо добавить вход в SSH сразу по root:

Смена порта SSH

Так как по умолчанию работа ssh настроена на порту 22, то пользоваться сервером становится не безопасно. Поэтому стоит сменить порт!

и поменяйте значения Port на необходимые:

# What ports, IPs and protocols we listen for Port 22

Вход только по ключу SSH:

С помощью nano отредактируйте документ sshd_config, введите команду:

Sudo nano /etc/ssh/sshd_config

Поменяйте значения PasswordAuthentication с yes на no:

RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no

У вас еще остались вопросы? Пишите их в комментариях, рассказывайте, что у вас получилось или наоборот!

Вот и все! Больше полезных статей и инструкций читайте в разделе . Оставайтесь вместе с сайтом , дальше будет еще интересней!

" Вы начинающий админ и хотите, например, поднять свой веб сервер. Идете в интернет, находите подходящую Вам статью и вперед! Давайте обратим внимание на один Важный момент, практически во всех этих статьях дается минимум команд для запуска необходимых служб и сервисов. Хорошо - заработало! А все ли Вы сделали для того, чтобы работать не перестало? Используете SSH через интернет? Почему никто в своих статьях не освещает проблем, которые могут получить новоиспеченные админы с таким подходом к настройке сервера, ведь именно для новичков и написаны статьи. Для того, чтобы Вы вовремя обратили внимание на вопрос безопасности, я обязательно буду делать пометки и ссылки в своих статьях на данный материал. Предупрежден – вооружен! "

Итак, SSH (secure shell) – безопасный сервер терминалов, предоставляет удаленный доступ к системе. Безопасный, т.к. весь трафик между клиентом и сервером шифруется. А так ли он безопасен с настройками по умолчанию? Если Вы имеете сервер с возможностью подключения по SSH через интернет, обязательно найдутся желающие подобрать пароль для входа. Думаю, не стоит объяснять, что возможный злоумышленник сможет получить практически неограниченный доступ к системе.

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

Установка SSH сервера в Ubuntu.

Установка SSH сервера в Ubuntu выполняется следующей командой:

Sudo apt-get install ssh openssh-server

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

Sudo service ssh stop | start | restart

Основной файл конфигурации SSH - сервера - файл /etc/ssh/sshd_config , доступный для чтения или редактирования только супер пользователю (root). Для применения изменений необходимо перезапустить ssh-сервер.

Настройки безопасности SSH сервера.

Протокол по умолчанию.

Опять же в современных дистрибутивах по умолчанию реализуется протокол SSH2. Если в Вашем случае указано нечто вроде:

Protocol 2,1

Необходимо оставить только 2:

Protocol 2

Использование небезопасного протокола SSH1 не рекомендуется.

По умолчанию в последних релизах Ubuntu, доступ пользователя root через SSH ограничен.

PermitRootLogin without-password

PermitRootLogin no

С такими настройками пользователь root не сможет авторизоваться по SSH.

Также данный параметр будет удобен, если с сервером работает несколько администраторов под учетной записью супер пользователя. Администраторы будут заходить под своей учетной записью и только после этого получать привилегии root, это намного облегчит аудит сервера и действий, которые выполняют администраторы.

Еще немного о root в Ubuntu, созданный по умолчанию пользователь (при установке системы) может решать все административные задачи через sudo. Активировать пользователя root для доступа к системе мне кажется не обоснованным решением.

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

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

AllowUsers user1 user2

Также Вы можете указать необходимую группу, например administrators:

AllowGroups administrators

Запретите доступ с "пустыми" паролями.

Вы должны явно запретить удаленный доступ с использованием пустых паролей:

PermitEmptyPasswords no

Изменение стандартного порта.

SSH по умолчанию работает на 22 порту. Соответственно основная масса атак будет направлена именно на этот порт, далее используя подбор имени пользователя и пароля, будут происходить попытки получить доступ к серверу. Мы уже исключили самое известное имя пользователя из базы возможного злоумышленника (root) и разрешили доступ только определенным пользователям, теперь сократим количество возможных атак (боты, ищущие уязвимости на стандартных портах), изменив порт, используемый по умолчанию (новый порт должен быть свободен!).

Изменим, к примеру, на:

Port 2220

Стоит понимать, что изменение порта никак не поможет Вам при целенаправленной атаке brute-force (подбор пароля). Злоумышленник может, например, пройтись сканером портов по IP адресу, на котором распложен Ваш сервер, в результате он получит список всех открытых портов.

Также помните, что теперь для подключения к серверу помимо IP адреса Вам нужно указать и номер порта.

Действительно рабочим вариантом защиты от перебора является использование для аутентификации SSH2 RSA-ключей. При таком способе пользователь генерирует пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ находится на сервере и служит для проверки идентичности пользователя. Плюс ко всему связку ключ – публичный ключ можно обезопасить парольной фразой, повысив криптостойкость авторизации. Логика проста, не используете для авторизации пароль – подбирать нечего!

Заходим в систему под тем пользователем, которому будем настраивать доступ по SSH к серверу.

Сгенерируем RSA ключ длинной 4096, Вам будет предложено указать место хранения, оставим по умолчанию (/home/UserName/.ssh/id_rsa), также будет предложено задать пароль на создаваемый ключ. Если пароль не указывать, то во время аутентификации на сервере по сертификату вводить его не придется, это менее надежно. Рекомендую Вам указать пароль:

Ssh-keygen -t rsa -b 4096

В указанной директории будет создана пара ключей:

id_rsa.pub - публичный

id_rsa – приватный

Проверим, созданы ли файлы:

Cd ~/.ssh ls -al

Установим права на папку и файлы:

Sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/id*

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

Ключ id_rsa передается клиенту:

/home/UserName/.ssh/id_rsa

После чего удаляется с сервера:

Sudo rm /home/UserName/.ssh/id_rsa

Создадим файл authorized_keys (находимся в системе под тем же пользователем “UserName”, для которого создавался сертификат) и скопируем в него содержимое файла id_rsa.pub , определим владельца и выставим права на директорию и файл.

Cd ~/.ssh sudo touch authorized_keys sudo chown UserName:UserName authorized_keys sudo cat id_rsa.pub >> authorized_keys sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/authorized_keys

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

Sudo cat /home/UserName/.ssh/authorized_keys

Если текст успешно скопирован, можно удалить публичный ключ:

Sudo rm /home/UserName/.ssh/id_rsa.pub

Sudo nano /etc/ssh/sshd_config

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

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

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

Sudo service ssh restart

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

Внимание перед отключением аутентификации по паролю убедитесь в возможности доступа по ключу

PasswordAuthentication no Подключение к SSH серверу через PuTTY, используя сертификат.

Для начала необходимо выполнить конвертацию приватного ключа (ключ пользователя UserName), который ранее мы забрали с сервера.

Для этого нам потребуется программа PuTTYgen .

Загружаем файл приватного ключа "Conversions - Import Key ".

Если Вы установили, пароль вводим его.

Выбираем "Save private key " и сохраняем полученный ppk файл. Хранить его стоит в месте, где он не сможет быть скомпрометирован.

Открываем программу PuTTY и настраиваем соединение:

Session - Host Name (or IP Address) IP адрес хоста, на котором настраивался SSH Сервер;

Session - Port Порт, указанный в настройках SSH сервера;

Session - Saved Session Название сессии (соединения);

Connection - Data - Autologin username Имя пользователя;

Connection - SSH - Auth - Private key file for authentication Путь к ppk файлу;

Session - Save Сохраняем сессию;

Session - Saved Session (выбираем нашу сессию) - Load - Open - Сессия должна запуститься;

Вводим пароль и нажимаем Enter, после этого попадаем в систему.

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

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

Cd ~/.ssh

Удалим файл его публичного сертификат authorized_key с сервера OpenSSH, если же вы неосмотрительно не удаляли файлы id_rsa.pub и id_rsa , удалите их. Просматриваем содержимое каталога коммандой "ls".

Удаляем необходимые файлы:

Sudo rm authorized_key id_rsa.pub id_rsa

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

В примере ниже это время ограничено до 30 секунд:

LoginGraceTime 30

Таймаут при отсутствии активности соединения.

Автоматическое отключение соединения после определенного времени, в течение которого зафиксировано бездействие в консоли.

ClientAliveCountMax – Параметр указывает на полное количество сообщений, отсылаемых ssh-сервером для распознавания активности ssh-клиента. По умолчанию это 3.

ClientAliveInterval – Параметр указывает на время ожидания в секундах. По истечению ssh-сервер отошлет сообщение-запрос клиенту. По умолчанию значение этого параметра – 0. Сервер не отсылает сообщение для проверки.

Отключение ssh-клиента автоматически после 5 минут (300 секунд):

ClientAliveInterval 300 ClientAliveCountMax 0

Представляем вашему вниманию новый курс от команды The Codeby - "Тестирование Веб-Приложений на проникновение с нуля". Общая теория, подготовка рабочего окружения, пассивный фаззинг и фингерпринт, Активный фаззинг, Уязвимости, Пост-эксплуатация, Инструментальные средства, Social Engeneering и многое другое.

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

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

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

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

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

Установка сервера и клиента OpenSSH на Linux

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

Debian, Ubuntu или Linux Mint

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

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

$ sudo update-rc.d ssh defaults

Fedora или CentOS/RHEL 7

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

CentOS/RHEL 6

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

Arch Linux

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

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

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

Есть пара опций OpenSSH, которые могут заинтересовать:

По умолчанию, sshd прослушивает порт 22 и ожидает входящие соединения ssh. Изменив порт по умолчанию для ssh, вы можете предотвратить различные автоматизированные атаки хакеров.

ListenAddress 192.168.1.1

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

HostKey /etc/ssh/ssh_host_key

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

PermitRootLogin no

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

AllowUsers alice bob

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

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

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

$ sudo /etc/init.d/ssh restart

Для перезапуска OpenSSH на Fedora, CentOS/RHEL 7 или Arch Linux:

$ sudo systemctl restart sshd.service

Для перезапуска OpenSSH на CentOS/RHEL 6:

$ sudo service sshd restart

Как подключиться к SSH

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

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

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

Для Windows многие рекомендуют и успешно пользуются PuTTY. Я ничего не имею против этой программы, но сам предпочитаю и рекомендую Cygwin .

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

Установка Cygwin проста. Переходим на официальный сайт и скачиваем 32-битную или 64-битную версию.

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

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

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

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

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

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

Два из этих параметров SSH может предположить: имя пользователя и номер порта. Если порт не указан, то предполагается порт по умолчанию. Если не указан пользователь, то используется то же имя, что и в системе, из которой происходит подключение. Например, адрес хоста для подключения 192.168.1.36. Если я наберу

Ssh 192.168.1.36

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

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

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

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

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

Ssh [email protected]

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

Ssh [email protected] -p 10456

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

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

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

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

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

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

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

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

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

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

Ssh-keygen -t rsa

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

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

Ssh [email protected] mkdir .ssh

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

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

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

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

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

ssh remote-sys tree

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

Ssh [email protected] tree

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

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

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

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

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

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

Передача стандартного вывода с локальной машины на удалённую по ssh

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

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

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

Открытие графической программы, расположенной на удалённом компьютере

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

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

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

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

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

ssh -X remote-sys

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

Ssh -X [email protected] gedit

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

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

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

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

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

scp

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

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

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

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

Для копирования файла с локальной машины на удалённую:

scp локальный_файл remote-sys:.

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

# создаём новый файл touch nfile.txt # отправляем файл scp nfile.txt [email protected]:. nfile.txt 100% 0 0.0KB/s 00:00 # проверяем наличие файла на удалённой машине ssh [email protected] "ls -l"

В команде отправки:

• nfile.txt — имя файла,
• [email protected] — имя пользователя и удалённый хост,
• . (точка) означает, что файл нужно скопировать в текущую рабочую директорию на удалённом сервере, при этом имя файла останется прежним, т. е. nfile.txt

Памятка:

Для копирования файла с B на A когда залогинены в B:

scp /path/to/file username@a:/path/to/destination

Копирование файла с B на A когда залогинены в A:

scp username@b:/path/to/file /path/to/destination

sftp

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

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

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

Гарант является доверенным посредником между Участниками при проведении сделки.

SSH (Secure Shell) — это сетевой протокол, предназначенный для удалённого управления сервером и передачи данных по зашифрованным TCP соединениям. Большинство хостингов , даже виртуальных, сегодня предоставляет доступ как по FTP, так и по SSH. На мой взгляд, это здорово, SSH намного удобнее и безопаснее в использовании.

Настройка SSH

Настройка будет происходить под выделенный сервер, VDS, VPS на Debian, Ubuntu. Конфигурационный файл располагается тут: /etc/ssh/sshd_config .
Если у вас обычный хостинг, всё и так должно быть настроено как надо, переходите к разделу .

По умолчанию, демон SSHD (именно в него мы вносим изменения) не нуждается в каких-либо настройках и работает нормально. Мы внесём лишь пару небольших изменений с целью ограничить доступ нежелательных лиц к серверу.

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

Как ограничить доступ по SSH

Все изменения вносятся в /etc/ssh/sshd_config
Чтобы изменения вступили в силу, необходимо

Сменить порт

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

Запретить связь по старому протоколу

Здесь мы определяем, что связь возможна только по протоколу v2

Если вы авторизованы не под root , перед всеми консольными командами нужно добавлять sudo — расшифровывается как Substitute User and DO — подмени юзера и делай (под ним). Например, позволяет исполнять команды от имени суперпользователя root .

Уменьшить число попыток авторизации

Количество попыток ввода пароля. По умолчанию 6. При неудачном переборе сеанс связи обрывается.

Уменьшить время ожидания авторизации

По умолчанию, 120 секунд может длиться сеанс авторизации. По истечению этого времени он обрывается. 2 минуты на авторизацию — это перебор, всё это время сервер держит связь открытой, что очень нерационально. Полминуты за глаза хватит.

Закрыть доступ по IP

Если доступ нужен только вам, самым простым и надёжным будет закрыть доступ отовсюду, кроме вашего IP или, если он динамический, то диапазона IP.

1. Открываем /etc/hosts.allow и добавляем туда SSHD: 192.168.1.1

   где 192.168.1.1 — ваш IP. Если у вас динамический IP, определите IP с маской подсети и запишите Вашу подсеть вместо IP, например:

   SSHD: 192.168.0.0/16

2. Открываем /etc/hosts.deny и добавляем туда: SSHD: ALL

Ещё один способ ограничения доступа по IP

Можно воспользоваться следующей директивой:

AllowUsers = *@1.2.3.4

Здесь мы разрешаем доступ только для IP 1.2.3.4

Авторизация SSH по ключам

Намного безопаснее, удобнее и правильнее будет настроить ssh авторизацию без пароля. Для этого будет использоваться авторизация по ключу.

Итак, вот инструкция:

Подключение настроено. Если что-то сделали не так, при авторизации появится ошибка Server refused our key , то есть Сервер не принял наш ключ . В этом случае пройдитесь по всем пунктам последовательно и поищите ошибку

Спасибо 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