Установка и настройка подключения по SSH
Я подключаюсь с Windows машины или из под Ubuntu к серверу с Debian или Ubuntu. Чтобы установить SSH используем в debian-based дистрибутивах.
После завершения установки будет запущен SSH-сервер в режиме демона. Это можно проверить командой:
Теперь сервер работает с базовыми настройками по-умолчанию. К серверу уже можно подключиться по SSH, и это нормально работает в частных сетях, однако лучше бы исправить некоторые параметры для работы в публичных сетях. Настройки хранятся в файле по адресу /etc/ssh/sshd_config. Посмотреть его можно командой
Для редактирования вы можете использовать любой редактоор, я использую nano.
Обратим внимание на параметры Port, AddressFamily, ListenAddress Port задает номер порта, через который будет работать соединение, стандартный порт 22, часто подвергается сканированию ботами. Чтобы задать параметр убираем символ # в начале строки и указываем нужное значение, например 58292. Главное, чтобы порт не конфликтовал с другими портами в системе, mysqld использует порт 3306, httpd — 80, ftpd — 21, поэтому выбирайте пятизначное значение, но не больше 65535.
AddressFamily задает семейство используемых адресов, IPv4 и IPv6, если используются только IPv4 адреса, то IPv6 можно отключить. AddressFamily inet — для IPv4 адресов и AddressFamily inet6 для IPv6 адресов. По-умолчанию значение any.
PubkeyAuthentication позволяет проводить авторизацию и шифрование трафика с помощью SSH-ключей.
Также серверу можно явно указать, где хранятся открытые ключи пользователей. Это может быть как один общий файл для хранения ключей всех пользователей (обычно это файл etc/.ssh/authorized_keys), так и отдельные для каждого пользователя ключи. Второй вариант предпочтительнее в силу удобства администрирования и повышения безопасности. Для общего файла:
Для каждого пользователя. Благодаря шаблону автоподстановки с маской «%h» будет использоваться домашний каталог пользователя.
Обратите внимание, что вариант по-умолчанию
Также безопасности ради можно отключить парольный доступ. Но прежде чем его отключать, настрой подключение по SSH-ключам, об этом ниже.
И обязательно отключить идентификацию по пустому паролю:
Следует также отключать root-доступ:
Значение по-умолчанию PermitRootLogin prohibit-password т.е. удалённый вход под пользователем root с парольной и интерактивной аутентификацией теперь запрещён. При указании значений without-password или prohibit-password допускается только аутентификация по ключам.
Для применения сделанных настроек необходим перезапуск SSH-сервера:
Для подключения к серверу используется команда:
Где user_name — имя пользователя. А host_name имя или ip адрес узла к которому производится подключение. Например:
При этом утилита ssh запросит (в зависимости от настроек сервера) логин, пароль или парольную фразу для разблокировки приватного ключа пользователя.
Создание и настройка SSH ключей
Чтобы сгенерировать SSH-ключи на клиентской машине (то есть на той, на которой ты работаешь, не на сервере), выполни:
Введи путь к файлу, в который будут помещены ключи, каталог по-умолчанию указан в скобках, если не знаешь зачем, не меняй его. Если хочешь оставить расположение по умолчанию: нажми Enter. Пароль (passphrase) используется для огранчения доступа к закрытому ключу, пароль усложнит использование ключа третьми лицами в случае утраты. Если не хочешь использовать пароль: нажми Enter без заполнения строки.
При успешной генерации ключей ты увидишь что-то вот такое: 
Открытый ключ хранится в файле /домашний_каталог/.ssh/id_rsa.pub, закрытый — /домашний_каталог/.ssh/id_rsa.
Можем посмотреть на них при помощи cat : 
Осталось скопировать открытый ключ на сервер в файл /домашний_каталог/.ssh/authorized_keys.
Внимание! Если на сервере еще нет папки .ssh в домашнем каталоге. Позаботься о его создании. Подключись к серверу, как ты подключаешься сейча, вероятно по паролю, и создай каталог:
Команда chmod устанавливает права доступа к папке: “Владелец может читать, записывать и запускать на выполнение; никто другой не имеет права выполнять никакие действия”.
Итак, если папка уже есть, или мы ее создали. Отключаемся от сервера, переходим в папку с нашими ключами на клиенте. Т копируем ключ на сервер:
Также можно открыть файл authorized_keys на сервер редактором, например, nano и вставить строку с открытым ключом после ssh-rca 
Еще один способ скопировать ключ в authorized_keys: команда echo , которая помещает строку в конец файла:
Другой способ перенести открытый ключ на сервер предлагает beget.com Копируем открытый ключ на удаленную систему при помощи scp
Авторизуемся на удаленном сервере:
Заносим открытый ключ нашей локальный системы в авторизованные ключи удаленной системы, устанавливаем правильные права и “убираем за собой мусор”:
Теперь можно перейти к настройкам и отключить аутентификацию по паролю. Подключаемся к серверу, открываем sshd_config:
Раскомментируем строку PasswordAuthentication и вместо yes укажем no:
Перезапускаем службу sshd:
Теперь можно подключаться к серверу:
Или если вы меняли и порт, то
Понятно, что вместо 58292 должен быть наш номер порта. Также можно указать логин при помощи -l
Если тебе нужно подключаться к серверу с нескольких машин есть два решения, одно хорошее, другое простое.
-
Первое. Нужно сгенерировать на каждой машине новую пару ключей, и скопировать публичные ключи вручную на сервер, в файл
Как подключиться по SSH
SSH — это основной протокол для удаленного управления серверами на базе операционной системы Linux. Все действия при подключении к SSH выполняются в командной строке, но при достаточном уровне знаний и привилегий в системе там можно сделать практически все что угодно, в отличие от того же FTP где можно только передавать и редактировать файлы.
Если вы покупаете VPS сервер или продвинутый хостинг, обычно в письме вместе с другими данными авторизации есть данные доступа по SSH. В этой статье мы рассмотрим как подключиться по SSH к серверу из Linux или Windows.
Что такое SSH?
Поскольку эта статья рассчитана именно на новичков, то перед тем, как перейти дальше давайте подробнее разберемся что из себя представляет SSH. Исторически так сложилось что на большинстве серверов используется операционная система Linux, во многом этому посодействовала ее бесплатность. Графический интерфейс на серверах Linux не используется для экономии ресурсов, поэтому единственным способом администрирования сервера остается командная строка.
Но это не является недостатком, потому что в командной строке Linux можно сделать больше чем графическом интерфейсе. Протокол SSH позволяет вам выполнять команды в удаленной системе так, как будто вы это делаете в своей системе. Вам доступен буфер обмена, вы вводите команды и можете использовать их вывод. Недоступны разве что файлы из вашей файловой системы. Например, когда вы подключитесь к серверу по SSH из Ubuntu, то все будет выглядеть так, как будто вы открыли терминал в своей системе.
Как подключиться по SSH
Для подключения по SSH нам необходимо знать такие данные:
- ip адрес сервера, к которому мы собираемся подключится;
- порт, на котором ожидает подключения SSH сервер, по умолчанию используется 22, но в целях безопасности порт подключения ssh часто изменяют;
- имя и пароль пользователя на удаленном сервере.
Больше ничего не нужно, обычно эти данные присылают в письме вместе с описанием VPS. Теперь перейдем к практике.
1. Подключение через SSH в Linux
В Linux подключение по SSH выполняется с помощью утилиты ssh. Мы более подробно рассматривали работу с ней в статье как пользоваться ssh. Для подключения к удаленному компьютеру ее синтаксис будет выглядеть следующим образом:
$ ssh имя_пользователя @ айпи_адрес
Это самый простой вариант, если вам также нужно задать порт, используйте опцию -p:
$ ssh имя_пользователя @ айпи_адрес -p порт
Чтобы выполнить подключение по SSH Linux нажмите Ctrl+Alt+T для открытия терминала и наберите команду, заменив нужные значения:
Или, с нестандартным портом:
ssh sergiy@192.168.1.2 -p 2223
Если ip_адрес и порт правильные, то на следующем шаге программа попросит у вас ввести пароль:
Если пытаетесь подключится через SSH к этому серверу первый раз, то утилита также попросит подтвердить добавление нового устройства в свой список известных устройств, здесь нужно набрать yes и нажать Enter:
Теперь вы подключены, и все вводимые далее команды будут выполнены на удаленном сервере:
Если же произошла ошибка и IP адрес или порт введены неверно, то вы получите ошибку Connection Refused:
Просто убедитесь что порт введен верно. Если это ваш сервер, то, возможно на нем еще нужно разрешить подключение SSH в брандмауэре. В Ubuntu/Debian для этого на удаленном сервере выполните:
sudo ufw allow 22/tcp
А в CentOS/Fedora:
firewall-cmd —permanent —zone=public —add-port=22/tcp
Если вы используете другой порт для SSH, то замените 22 на свой порт. Для удобства подключения по SSH в дальнейшем можно настроить авторизацию по ключу ssh, чтобы не вводить каждый раз пароль.
Теперь вы знаете как подключиться по ssh linux и решить проблемы с подключением. А теперь перейдем к Windows.
2. Подключение через SSH в Windows
Раньше подключение по SSH из Windows выполнялось только с помощью сторонних утилит, например PuTTY. Но в Windows 10 был добавлен встроенный OpenSSH клиент и работает он точно так же, как и в Linux. По умолчанию этот компонент не активирован. Для его установки откройте Параметры -> Приложения:
Затем выберите Управление дополнительными компонентами:
Здесь нажмите добавить новый компонент и в открывлемся меню выберите OpenSSH Client и нажмите Устанвоить:
Дальше вернитесь назад и дождитесь завершения установки. После того, как SSH клиент будет установлен нужно обязательно перезагрузить компьютер.
После перезагрузки нажмите Win+R чтобы открыть окно запуска команд и наберите в нем cmd:
Далее нажмите Enter. Перед вами откроется командная строка Windows. Здесь можно использовать утилиту ssh. Синтаксис у нее абсолютно такой же, как и для Linux:
ssh имя_пользователя @ айпи_адрес -p порт
Например, такой командой можно подключится по SSH к Raspberry Pi, который находится в вашей локальной сети по адресу 192.168.1.5:
Утилита предложит добавить устройство в список известных:
Затем предложит ввести пароль:
Все следующие команды будут выполняться уже на Raspberry Pi или другой удаленной машине, к которой вы подключились.
Теперь подключиться к серверу по ssh из этой операционной системы также просто как и из Linux.
Выводы
В этой статье мы рассмотрели как выполняется подключение к серверу по SSH из Linux или Windows. Как видите, это очень просто. А дальше, для работы с удаленным сервером вам понадобятся команды терминала Linux.
Использование SSH для подключения к удаленному серверу
Одним из важнейших инструментов в работе системного администратора является SSH.
SSH, или Secure Shell, — это протокол, используемый для безопасного входа на удаленные системы. Это самый распространенный способ получения доступа к удаленным серверам Linux.
В этом руководстве мы обсудим, как использовать SSH для подключения к удаленной системе.
Базовый синтаксис
Чтобы подключиться к удаленной системе с помощью SSH, мы будем использовать команду ssh . В самом базовом виде команда имеет следующую форму:
remote_host в этом примере является IP-адресом или доменным именем узла, к которому вы пытаетесь подключиться.
Эта команда предполагает, что ваше имя пользователя на удаленной системе совпадает с именем пользователя в локальной системе.
Если ваше локальное имя пользователя отличается от имени пользователя в удаленной системе, вы можете задать его, используя следующий синтаксис:
После подключения к серверу вам, возможно, потребуется подтвердить вашу личность с помощью пароля. Позже мы рассмотрим, как сгенерировать ключи, которые можно использовать вместо паролей.
Чтобы завершить сеанс ssh и вернуться в сеанс локальной оболочки, введите следующую команду:
Как работает SSH?
SSH выполняет подключение клиентской программы к серверу ssh с именем sshd .
В предыдущем разделе команда ssh использовалась для вызова клиентской программы. Сервер ssh уже запущен на удаленном хосте remote_host , который мы указали.
На вашем сервере должен быть запущен сервер sshd . Если это не так, вам может потребоваться подключение к серверу через веб-консоль или локальную последовательную консоль.
Процесс запуска сервера ssh зависит от дистрибутива Linux, который вы используете.
В Ubuntu вы можете запустить сервер ssh с помощью следующей команды:
Эта команда должна запускать сервер sshd, после чего вы сможете выполнять удаленный вход.
Настройка SSH
При изменении конфигурации SSH вы меняете настройки сервера sshd.
В Ubuntu основной файл конфигурации sshd находится в каталоге /etc/ssh/sshd_config .
Выполните резервное копирование текущей версии этого файла перед началом редактирования:
Откройте файл в текстовом редакторе:
Скорее всего, вы захотите оставить большинство опций в этом файле без изменений. Однако существует несколько настроек, на которые вам стоит обратить особое внимание:
Объявление порта указывает, подключения к какому порту будет отслеживать сервер sshd. По умолчанию используется порт 22 . Вам, скорее всего, не придется изменять данную настройку, если только у вас нет конкретных причин для иного решения. Если вы решите изменить порт, позже мы покажем, как подключиться к новому порту.
В объявлениях ключей хоста указывается, где нужно искать глобальные ключи хоста. Мы обсудим, что такое ключ хоста, позже.
Эти две строки указывают на уровень логирования, который необходимо использовать.
Если вы сталкиваетесь с проблемами при работе с SSH, увеличение объема логируемых данных может быть хорошим решением, которое поможет понять, в чем заключается проблема.
Эти параметры определяют некоторые данные для входа в систему.
Опция LoginGraceTime определяет количество секунд, в течение которых следует сохранять подключение при отсутствии успешных попыток входа в систему.
Возможно, вам может быть полезным задать для этого параметра чуть большее количество времени, чем то, которое вам обычно требуется для входа.
PermitRootLogin определяет, разрешен ли вход с помощью пользователя с правами root.
В большинстве случаев необходимо изменить значение на no , если вы создали учетную запись пользователя, которая имеет доступ к высокому уровню привилегий (через su или sudo ) и может использоваться для входа в систему через ssh.
strictModes — это защитник, который будет препятствовать попыткам входа, если файлы аутентификации доступны для чтения всем.
Он позволяет предотвратить попытки входа в систему, когда файлы конфигурации не находятся в безопасном состоянии.
Эти параметры используются для настройки такой возможности, как X11 Forwarding. X11 Forwarding позволяет просматривать графический пользовательский интерфейс (GUI) удаленной системы на локальной системе.
Эта функция должна быть активирована на сервере и передана клиенту SSH во время подключения с помощью опции -X .
После внесения изменений сохраните и закройте файл, введя CTRL+X , Y , а затем нажмите ENTER .
Если вы внесли изменения в какие-либо настройки в файле /etc/ssh/sshd_config , необходимо перезапустить ваш сервер sshd, чтобы изменения вступили в силу:
Вы должны тщательно протестировать ваши изменения, чтобы убедиться, что все работает так, как вы ожидаете.
Вы можете использовать несколько активных сеансов во время внесения изменений. Это позволит вам вернуться к первоначальной конфигурации, если это потребуется.
Выполнение входа через SSH с использованием ключей
Хотя возможность входа в удаленную систему с помощью паролей может быть полезна, гораздо лучшей идеей будет настройка аутентификации с помощью ключей.
Как работает аутентификация с помощью ключей?
Аутентификация с помощью ключей реализуется путем создания пары ключей: приватного ключа и публичного ключа.
Приватный ключ располагается на клиентском компьютере, этот ключ защищен и хранится в секрете.
Публичный ключ может передаваться любому лицу или размещаться на сервере, доступ к которому вы хотите получить.
При попытке подключения с использованием пары ключей сервер будет использовать публичный ключ для создания сообщения для клиентского компьютера, которое может быть прочитано только с помощью приватного ключа.
Затем клиентский компьютер отправляет соответствующий ответ обратно серверу, после чего сервер будет знать, что клиент не является поддельным.
Весь этот процесс выполняется в автоматическом режиме после того, как вы настроите ключи.
Создание ключей SSH
Ключи SSH необходимо генерировать на компьютере, откуда вы хотите войти в систему. Как правило, это ваш локальный компьютер.
Введите следующую команду в командной строке:
Нажмите ENTER, чтобы принять используемые по умолчанию значения. Ваши ключи будут сгенерированы в файлах
Перейдите в каталог .ssh с помощью следующей команды:
Просмотрите данные о разрешениях для файлов:
Как вы можете видеть, файл id_rsa доступен для чтения и записи только владельцу. Именно такие разрешения позволяют сохранить его в секрете.
В то же время файл id_rsa.pub может использоваться совместно и имеет соответствующие разрешения для данной деятельности.
Как передать ваш публичный ключ на сервер
Если в настоящее время вы используете доступ к серверу с помощью пароля, вы можете скопировать ваш публичный ключ на сервер, воспользовавшись данной командой:
В результате будет создан сеанс SSH. Когда вы введете пароль, ваш публичный ключ будет скопирован в файл авторизованных ключей сервера, что позволит не использовать пароль при входе в следующий раз.
Опции для клиентской стороны
Существует ряд опциональных флагов, которые вы можете использовать при подключении через SSH.
Некоторые из них могут быть необходимы при наличии определенных настроек конфигурации sshd на удаленном хосте.
Например, если вы изменили номер порта в конфигурации sshd , вам потребуется указать этот порт на клиентской стороне с помощью следующей команды:
Если вы хотите выполнить отдельную команду на удаленной системе, вы можете указать ее после имени хоста следующим образом:
В результате будет установлено подключение к удаленному компьютеру, а после успешной аутентификации команда будет выполнена.
Как уже отмечалось ранее, если функция X11 forwarding активирована на обоих компьютерах, вы можете получить доступ к данному функционалу, воспользовавшись следующей командой:
При наличии соответствующих инструментов на вашем компьютере программы GUI, которые вы используете на удаленной системе, теперь будут открываться в отдельном окне на локальной системе.
Отключение аутентификации по паролю
Если вы создали ключи SSH, вы можете повысить уровень безопасности вашего сервера, отключив аутентификацию только по паролю. Помимо консоли единственным способом входа на ваш сервер будет использование приватного ключа, который используется в паре с публичным ключом, установленным на сервере.
Предупреждение: перед выполнением этих действий необходимо убедиться, что публичный ключ установлен на сервере. В противном случае вы заблокируете доступ к серверу!
Откройте файл конфигурации sshd , воспользовавшись пользователем root или пользователем с привилегиями sudo:
Найдите строку Password Authentication и раскомментируйте ее, удалив символ # в начале строки. Теперь вы можете указать значение no :
Вы должны также изменить значения двух других настроек (если вы не вносили изменения в этот файл ранее) — PubkeyAuthentication и ChallengeResponseAuthentication . Значения устанавливаются по умолчанию и выглядят следующим образом:
После внесения изменений сохраните и закройте файл.
Теперь нужно перезапустить демон SSH:
Теперь аутентификация по паролю должна быть отключена, а ваш сервер должен быть доступен только с помощью аутентификации по ключу SSH.
Заключение
Обучение работе с SSH точно будет полезным, хотя бы потому, что это очень распространенный инструмент.
По мере знакомства с разными опциями вы будете открывать для себя более продвинутый функционал, который поможет сделать вашу жизнь проще. SSH остается популярным благодаря своей безопасности, легковесности и пользе в самых разных ситуациях.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
SSH в Linux
The authenticity of host '192.168.56.101 (192.168.56.101)' can't be established. ECDSA key fingerprint is SHA256:db8az/qbrWOJWvNRv2d9UHaDBnnUHanJ9Svca9vFx7c. Are you sure you want to continue connecting (yes/no/[fingerprint])?
Если выбрать yes то в файл
|1| abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567
Если у вас на хосте не было директории .ssh после первого подключения она должна появится.
Сгенерировать пару ключей
Первый шаг — это генерация пары ключей. Обычно это делается на клиентской машине. Например, на вашем ноутбуке.
Основная команда ssh-keygen создаст 2048-битную пару RSA ключей. Для большей надёжности можно добавить флаг -b 4096
ssh-keygen -b 4096
Чтобы сгенерировать ключ в /home/$(whoami)/.ssh
sudo ssh-keygen -b 4096
Чтобы сгенерировать ключ в /home/root/.ssh
Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa):
Нужно придумать имя ключа.
Я назову ключ andrei-key101 а сохранять буду в текущую директорию.
Enter file in which to save the key (/root/.ssh/id_rsa): andrei-key101 Enter passphrase (empty for no passphrase): Enter same passphrase again:
Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.
Your identification has been saved in andrei-key101 Your public key has been saved in andrei-key101.pub The key fingerprint is: SHA256:abcd/abcdefghijklmnopqrstuvwxyz1234567890ab root@urn-su The key's randomart image is: +—[RSA 4096]—-+ |=o oo++ | |= oo o. = o | |+ | |Oo=o . . | |B+.o S . | |+o.o | |+.0. . | |o+= . E | |+=oo. . . | +—-[SHA256]——+
Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls
Важно помнить, что если вы генерируете ключ для другого пользователя нужно позаботиться о правильных правах доступа к этому ключу.
Какой ключ куда?
.pub ключ отправляйте на удалённую машину
приватный ключ храните на своём клиенте
Передать ключ на удалённый хост
После того, как ключи созданы нужно передать .pub ключ на удалённый хост.
Сделать это можно несколькими способами начнём с утилиты ssh-copy-id
ssh-copy-id
Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа
sudo ssh-copy-id -i
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: «/home/andrei/.ssh/andrei-key.pub» The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established. ECDSA key fingerprint is SHA256:abcdefgh1234567890abcdefgh1234567890abc+def. Are you sure you want to continue connecting (yes/no/[fingerprint])?
Введите yes
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys andrei@192.168.0.2's password:
Number of key(s) added: 1 Now try logging into the machine, with: «ssh 'andrei@192.168.0.2'» and check to make sure that only the key(s) you wanted were added.
Теперь на хосте 192.168.0.2 в файле /home/andrei/.ssh/authorized_keys появилась новая запись вида
ssh-rsa AAAAB3NzaC1y … lseP/jXcq … Uydr/2CwQ &hellip ++TpY19pHqD/AnhL … Az62T/Ipyx … 8U2T andrei@host.andrei.com
Знак … заменяет длинные последовательности случайных символов для экономии места.
Проверить ключ можно командой
Если вы не задавали пароль для ключа, то попадёте на удалённый хост без лишних движений
Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1
Добавить ключ вручную
Добиться подключения по ключу можно и без ssh-copy-id
Те же манипуляции можно проделать вручную.
Узнать версию OpenSSH в Linux
Чтобы узнать версию OpenSSH в вашем дистрибутиве Linux выполните
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
Существующие версии OpenSSH можете изучить здесь
Выполнить команду из скрипта на удалённом компьютере
Если подключение по ssh происходим из bash-скрипта , и при этом нужно ещё выполнить ряд команд после подключения — достаточно перечислить эти команды через точку с запятой
#!/bin/bash ssh andrei@192.168.0.2 «ls;cd /home/andrei/bash_scripts;ls;ip a;cal»
Если нужно выполнить команду, требующую sudo попробуйте флаг -t
#!/bin/bash ssh -t andrei@192.168.0.2 «sudo apt upgrade»
known_hosts
Список известных хостов находится в файле known_hosts
Обычно файл known_hosts имеет следующий формат (записи идут через пробел) ( подробнее )
Примеры алгоритмов: ssh-rsa, ssh-dss, ssh-ed25519, ecdsa-sha2-nistp256 …
|1| abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567
Здесь через пробел записаны три элемента: хэш от имени сервера, название используемого ассиметричного алгоритма и публичный ключ сервера. Разберём их по очереди.
Это хэш от имени сервера.
Это алгоритм шифрования
Это публичный ключ хоста
Для freerdp соединений может существовать отдельный файл со списком хостов, например /home/andrei/.config/freerdp/known_hosts2
Чтобы удалить устаревшую запись по номеру строки (например 155) нужно выполнить
sed -i 155d /home/$(whoami)/.ssh/known_hosts
Чтобы очистить файл от записей о каком-то определённом хосте (например 192.168.56.109) нужно выполнить
ssh-keygen -R 192.168.56.109
Создать SSH туннель
ssh -L 9119: 192.168.0.2 : 9200 username@192.168.0.2
Подробнее про туннели можно прочитать в статье «SSH туннели»
Запустить SSH в фоновом режиме
Существует несколько способов запустить ssh соединение в фоновом режиме — то есть освободим текущий терминал.
-L, screen, tmux, nohup
Мне запустить ssh фоном из скрипта помог nohup, поэтому начнём с него
nohup ssh user@host «cd scripts;python3 my_script.py $ARG1 $ARG2; exit» &
Для чего это было нужно: Python скрипт сначала открывал одно ssh соединение из subprocess там выполнялась команда для запуска мониторинга потребления памяти и больше от этого соединения ничего было не нужно, зато необходимо было выполнять новые соединения с нагрузкой из другого скрипта.
Чтобы уйдя из первого подключения не оборвать мониторинг потребления памяти перед ssh нужно было добавить nohup, а в самом конце поставить &
SSH_CONNECTION
После того, как соединение установилось можно изучть его с помощью переменной $SSH_CONNECTION
192.168.56.1 51284 192.168.56.103 22
SSH_MSG_USERAUTH_BANNER
Клиенту, подключившемуся к ssh серверу можно показать баннер SSH_MSG_USERAUTH_BANNER
sudo vi /etc/issue.net
И отредактируйте файл добавив свой баннер
Откройте sshd_config и укажите путь до баннера
sudo vi /etc/ssh/sshd_config
/banner
# no default banner path #Banner none
Этот баннер будет показан ДО авторизации, то есть во время ввода пароля
Чтобы создать баннер, который будет показан после успешного входа выполните
sudo vi /etc/motd
После редактирования файлов перезапустите sshd
sudo systemctl restart sshd.service
Конвертация сертификатов
Рассмотрим простой пример: вы достали из базы данных сертификат MIIC4jCCAc … A7A6Rpt8V9Q== , но он не отформатирован и не проходит валидацию
Сертификат, конечно, длиннее, я поставил троеточие для экономии места и вашего времени.
echo 'MIIC4jC … 7A6Rpt8V9Q==' | base64 -d | openssl x509 -inform der
Либо, если вам нужно работать с файлами — сохраните исходный сертифика в фай raw_cert
echo MIIC4jC … 7A6Rpt8V9Q== > raw_cert
cat raw_cert | base64 -d | openssl x509 -inform der > cert
cat cert
——BEGIN CERTIFICATE——
MIIC4jC … 7A6Rpt8V9Q==
——END CERTIFICATE——
Такого же результата можно было добиться аккуратно добавив ——BEGIN CERTIFICATE—— в начало и ——END CERTIFICATE—— в конец файла, но не всегда всё так просто.
Если нужно переделать существующий публичный ключ в pem
ssh-keygen -f andrei.pub -e -m pem
——BEGIN RSA PUBLIC KEY—— MIIBigKCAYEAxW5sOxlrBGmXfn5Lqpvv+VZDxmet/Eg/EGaRk6d583L3Ro8HNtLz Gt0w6jEgoQ5cfxLMGFa4RaVvq5VR/bWC2Nc9q+5dQ51Y4UBkB9kOixtf3oas0mNE ieRbLwpuXKXx7tP3BEB63C0SZFDUiLYYIC1kjD/mVHXAQhQN4Az4TEa2rQIj3NMo xHtgXCSZdw9mJLyxLQITQy2AvHyj8xaYbK4GslxxYTp7lha6jJuy4jSGYfclhpgr K1c9ssF/CXxUN2Gg5YZlQ2Wm4HWquIL8QQ1Z/K0gVkfwcb0twpjDTkhumNE02O5j AoK3NONPCp3zoItbCMIzR0q8yzBraMeeDotjSZ2SHuJG7+f/khOY3TVch35JFOGD Oml38rCkX5/wiUUs7tNlLE7ChAnwN1kAQoN+tl+0ZdcBRBmstX1V3KrHnJCUULIc iYzfYnU8cBOH0eBdktrsXAFl1xglzSVkL3NcUGVQWE7wngIlpb3BMhaasr0op0Wd 2xY0Q9dExAVbAgMBAAE= ——END RSA PUBLIC KEY——
Как видно из RSA KEY — это не совсем то что нужно
Сгенерировать .pem ключ и сертификат можно командой
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
cat cert.pem
——BEGIN CERTIFICATE—— MIIDazCCAlOgAwIBAgIUS1R7HHEKnBYHi4msHb6crOdT/HQwDQYJKoZIhvcNAQEL BQAwRTELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoM GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDAeFw0yMjA2MDMxMTAyMDRaFw0zMjA1 MzExMTAyMDRaMEUxCzAJBgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEw HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQD3qbFpBrpzHa9eu9DcGIbo3lCm+3uqVocOpifY29q7 jz8rAZB/5mCZ4hP6W2mIZRCAi6oUwRNdAruHeO9oCB4hzJjbkVtW0MPkJ60Xa9Tc kX+9xuX7WL3hkHq/NLwgdMuqxWQ60i5H9uAV4KEjOeBS9KAhOUXkfMcmZXAShSP0 RSeuq3nqBOi87jcST5hBxMYDzTRh8mv+82wCOVaDdBALfSmDVjFRl6ltaEsuYdH7 gGaUYhwgHpQ5l61mnYYyx88Sen80DUsSBJQgoysFXqklMCYnRIChR+nQDyq+WB5/ B96Bjk+MhcYvRpCjG5gnbo3SlUzXrgIWXA7EK/F1cvW/AgMBAAGjUzBRMB0GA1Ud DgQWBBSYV6h+l5pIHCK+e32x5tPn28aBWTAfBgNVHSMEGDAWgBSYV6h+l5pIHCK+ e32x5tPn28aBWTAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQDB BZEhAHX7G5UvlU87uQI8lFXthZwljwdH+3fhfRRJniHx6wYvDDF4DaUextvTUWwf ly2piZCh/oqjeSFM2Pqzn8xSU5N9tyIWbCD3A2BbJZB+xa+7zVOgk2jpnq+9aTnj vGCYZ3jUCeLoAn/Qa0CoOIJt4RfNHiSMPKmxv0Kjlk3N+t0f5AJ9wFgpeARnBCpj GFZFNEOm9ss+8vFhca3mTR9vHoLslV+/zLHGDnHmOmC4erX/jyaOjLUniAC0ePO7 OfD67MOZQcnypuTG7ElFsRItUNXP6wOZSEV52IhBJnW99M8j68qq81Fzjh6Hz+8c ewux8YXqbUGhpW54vJh5 ——END CERTIFICATE——
——BEGIN PRIVATE KEY—— MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQD3qbFpBrpzHa9e u9DcGIbo3lCm+3uqVocOpifY29q7jz8rAZB/5mCZ4hP6W2mIZRCAi6oUwRNdAruH eO9oCB4hzJjbkVtW0MPkJ60Xa9TckX+9xuX7WL3hkHq/NLwgdMuqxWQ60i5H9uAV 4KEjOeBS9KAhOUXkfMcmZXAShSP0RSeuq3nqBOi87jcST5hBxMYDzTRh8mv+82wC OVaDdBALfSmDVjFRl6ltaEsuYdH7gGaUYhwgHpQ5l61mnYYyx88Sen80DUsSBJQg oysFXqklMCYnRIChR+nQDyq+WB5/B96Bjk+MhcYvRpCjG5gnbo3SlUzXrgIWXA7E K/F1cvW/AgMBAAECggEAGBNsBry7tWMmYDw74pmTy+GIz6LU88szl+35I7DDw8X6 KxEc3gIkU/FRZd4rFTJV91kccKYQXtNcLaBJDcD0RO7h0T6BNaBX2r8sqYE3ETYn x+glBVksJFhqRlo3C6SvA+vqgXlbPG24fQf4QjdnIklbo78wlzS2G3py+antw9og OpYllYJ3ySQQHKBFVtcTampwDBGDTonp2Hnw1X7nevAfdgKqCBhw55AhVR1ystyR NV0u2zcIFIdFgwmBgliczmze+aGCR2xfgSFQ+AUz7tmTNrTVdIkAcTdOSPejnLzJ a03k26jI6ngF3c1jj4oVz90yCjsO5dy9SrcSte0zsQKBgQD/FFiRHPbVchkmDJSa xXULla6NLU2+zdaQI7P4+YgJY0ZBDeXa0DfwDgfmX99uYwZTbwft5WBoEE9VgSwB XGWUEWTWW3BZD3MiCEnXuUt/QKRBzq+wtK5be6ewZ6ngWYCTh6Iscl4oLzCq/Qu+ nZezg5ufrA7FsQ2CqH9gKMgSVwKBgQD4jn7IBrbUBXGlWM/EBVDNiX1X/IbOYVKG 1ArB5WML2M+A53hz9+6m2TUKoNTFEJxOnj6RD7ZdhcSBHFTY3TWz3tJ/zNH9Q4Qw QbQXu9q/+H8cjKfFitvRLxXOylPj4e0bo1uONJGYKerjhqthRr/awKZsTKXSE8B1 EMUkU2Gm2QKBgC/0gkYd3OX6AnJd0R5b2wpnhJ50Eva5Ogp1O+Ol/gZNzKp0U29U z/9ok+Giyp21Lj5HVIVMJ1jJIDEiDMTguxQgRQXrwO5tcibGyiMtad0tqPPaSLt+ 7Hy0fa0zgAN2sC6MRFf41GzXml27HxciB6AvMPXO4iQWikSzKudII30XAoGAU4lA nuVyyOtTeKjSmyTWNV4CHHIotHANFndpbiU0FqU1iDNDTmaDdNwHcZ0AJYMhpWKV 0JchSWlN07673W7rP5qh0IX8BUyNvtI2PsvKBz7zKZs0P7Ydjr5ua+OgMjSaRfGv MaoFTMi5wuJd8wGeNV0OEdPo3yP4SN/sAftsFHECgYBwdPou3rPEvYs1v0T136Ux r0t0ertFQSxAmzTgqZBcNZ6K9z0lveaeEAKTPvCb8gPNnZvFRlMMsjYasmSC0NH8 N57C3IZpoGn5uPy805nb4l7DxXV3if0cuskO8gcy3FdBbfHkFba1dUfDHanXRkrt 3RvX3DZEhV6Y0JHZT/KHAA== ——END PRIVATE KEY——
Разрешить доступ по SSH в iptables
Чтобы явно разрешить доступ по ssh через iptables выполните
iptables -A INPUT -p tcp —dport 22 -j ACCEPT
Проверить результат можно выполнив команду iptables -L и проверив появилось ли нужное правило.
…
ACCEPT tcp — anywhere anywhere tcp dpt:ssh
…
Список подключений по SSH
Получить список установленных подключений можно с помощью команд netstat и grep указав порт (стандартный — 22) и
netstat -tnpa | grep 22 | grep ESTABLISHED
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 10.15.252.125:22 10.1.55.58:56722 ESTABLISHED — tcp 0 0 10.15.252.125:22 10.15.253.192:47614 ESTABLISHED —
Существующие версии OpenSSH
OpenSSH 8.9/8.9p1 (2022-02-23) New features ———— * ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default («sntrup761x25519-sha512@openssh.com»). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo. We are making this change now (i.e. ahead of cryptographically- relevant quantum computers) to prevent «capture now, decrypt later» attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available. * sftp-server(8): support the «copy-data» extension to allow server- side copying of files/data, following the design in draft-ietf-secsh-filexfer-extensions-00. bz2948 * sftp(1): add a «cp» command to allow the sftp client to perform server-side file copies. OpenSSH 8.8/8.8p1 (2021-09-26) New features ———— * ssh(1): allow the ssh_config(5) CanonicalizePermittedCNAMEs directive to accept a «none» argument to specify the default behaviour. OpenSSH 8.7/8.7p1 (2021-08-20) New features ———— — scp(1): experimental support for transfers using the SFTP protocol as a replacement for the venerable SCP/RCP protocol that it has traditionally used. SFTP offers more predictable filename handling and does not require expansion of glob(3) patterns via the shell on the remote side. SFTP support may be enabled via a temporary scp -s flag. It is intended for SFTP to become the default transfer mode in the near future, at which time the -s flag will be removed. The -O flag exists to force use of the original SCP/RCP protocol for cases where SFTP may be unavailable or incompatible. — sftp-server(8): add a protocol extension to support expansion of
user/ prefixed paths. This was added to support these paths when used by scp(1) while in SFTP mode. — ssh(1): add a ForkAfterAuthentication ssh_config(5) counterpart to the ssh(1) -f flag. GHPR231 — ssh(1): add a StdinNull directive to ssh_config(5) that allows the config file to do the same thing as -n does on the ssh(1) command- line. GHPR231 — ssh(1): add a SessionType directive to ssh_config, allowing the configuration file to offer equivalent control to the -N (no session) and -s (subsystem) command-line flags. GHPR231 — ssh-keygen(1): allowed signers files used by ssh-keygen(1) signatures now support listing key validity intervals alongside they key, and ssh-keygen(1) can optionally check during signature verification whether a specified time falls inside this interval. This feature is intended for use by git to support signing and verifying objects using ssh keys. — ssh-keygen(8): support printing of the full public key in a sshsig signature via a -Oprint-pubkey flag. OpenSSH 8.6/8.6p1 (2021-04-19) New features ———— * sftp-server(8): add a new limits@openssh.com protocol extension that allows a client to discover various server limits, including maximum packet size and maximum read/write length. * sftp(1): use the new limits@openssh.com extension (when available) to select better transfer lengths in the client. * sshd(8): Add ModuliFile keyword to sshd_config to specify the location of the «moduli» file containing the groups for DH-GEX. * unit tests: Add a TEST_SSH_ELAPSED_TIMES environment variable to enable printing of the elapsed time in seconds of each test. OpenSSH 8.5/8.5p1 (2021-03-03) New features ———— * ssh(1): this release enables UpdateHostkeys by default subject to some conservative preconditions: — The key was matched in the UserKnownHostsFile (and not in the GlobalKnownHostsFile). — The same key does not exist under another name. — A certificate host key is not in use. — known_hosts contains no matching wildcard hostname pattern. — VerifyHostKeyDNS is not enabled. — The default UserKnownHostsFile is in use. We expect some of these conditions will be modified or relaxed in future. * ssh(1), sshd(8): add a new LogVerbose configuration directive for that allows forcing maximum debug logging by file/function/line pattern-lists. * ssh(1): when prompting the user to accept a new hostkey, display any other host names/addresses already associated with the key. * ssh(1): allow UserKnownHostsFile=none to indicate that no known_hosts file should be used to identify host keys. * ssh(1): add a ssh_config KnownHostsCommand option that allows the client to obtain known_hosts data from a command in addition to the usual files. * ssh(1): add a ssh_config PermitRemoteOpen option that allows the client to restrict the destination when RemoteForward is used with SOCKS. * ssh(1): for FIDO keys, if a signature operation fails with a «incorrect PIN» reason and no PIN was initially requested from the user, then request a PIN and retry the operation. This supports some biometric devices that fall back to requiring PIN when reading of the biometric failed, and devices that require PINs for all hosted credentials. * sshd(8): implement client address-based rate-limiting via new sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize directives that provide more fine-grained control on a per-origin address basis than the global MaxStartups limit. OpenSSH 8.4/8.4p1 (2020-09-27) New features ———— * ssh(1), ssh-keygen(1): support for FIDO keys that require a PIN for each use. These keys may be generated using ssh-keygen using a new «verify-required» option. When a PIN-required key is used, the user will be prompted for a PIN to complete the signature operation. * sshd(8): authorized_keys now supports a new «verify-required» option to require FIDO signatures assert that the token verified that the user was present before making the signature. The FIDO protocol supports multiple methods for user-verification, but currently OpenSSH only supports PIN verification. * sshd(8), ssh-keygen(1): add support for verifying FIDO webauthn signatures. Webauthn is a standard for using FIDO keys in web browsers. These signatures are a slightly different format to plain FIDO signatures and thus require explicit support. * ssh(1): allow some keywords to expand shell-style $
/.ssh/known_hosts.d/%k». bz#1654 * ssh(1): add %-TOKEN, environment variable and tilde expansion to the UserKnownHostsFile directive, allowing the path to be completed by the configuration (e.g. bz#1654) * ssh-keygen(1): allow «ssh-add -d -» to read keys to be deleted from stdin. bz#3180 * sshd(8): improve logging for MaxStartups connection throttling. sshd will now log when it starts and stops throttling and periodically while in this state. bz#3055 OpenSSH 8.3/8.3p1 (2020-05-27) New Features ———— * sshd(8): make IgnoreRhosts a tri-state option: «yes» to ignore rhosts/shosts, «no» allow rhosts/shosts or (new) «shosts-only» to allow .shosts files but not .rhosts. * sshd(8): allow the IgnoreRhosts directive to appear anywhere in a sshd_config, not just before any Match blocks; bz3148 * ssh(1): add %TOKEN percent expansion for the LocalFoward and RemoteForward keywords when used for Unix domain socket forwarding. bz#3014 * all: allow loading public keys from the unencrypted envelope of a private key file if no corresponding public key file is present. * ssh(1), sshd(8): prefer to use chacha20 from libcrypto where possible instead of the (slower) portable C implementation included in OpenSSH. * ssh-keygen(1): add ability to dump the contents of a binary key revocation list via «ssh-keygen -lQf /path» bz#3132 OpenSSH 8.2 FEATURE: Add FIDO/U2F Support OpenSSH 8.1, released in October 2019 ssh, sshd, ssh-agent: add protection for private keys at rest in RAM against speculation and memory side-channel attacks like Spectre, Meltdown and Rambleed. OpenSSH 8.0, released in April 2019 SECURITY: CVE-2019-6111 related to scp tool and protocol allowing to overwrite arbitrary files in the scp client target directory OpenSSH 7.9, released in October 2018 allow key revocation lists (KRLs) to revoke keys specified by SHA256 hash OpenSSH 7.8, released in August 2018 Incompatible changes: ssh-keygen write OpenSSH format private keys by default instead of using OpenSSL's PEM format. OpenSSH 7.7, released in February 2018 FEATURE: Add «expiry-time» option in sshd for authorized_keys files to allow for expiring keys. OpenSSH 7.6, released in October 2017 FEATURE: Add RemoteCommand option FEATURE: Add SyslogFacility option to ssh matching the equivalent option in sshd FEATURE: ssh client reverse dynamic forwarding -R OpenSSH 7.5, released in March 2017 BUGFIX: This is a mainly a bugfix release. OpenSSH 7.4, released Template:Release date and age sshd(8): Add a sshd_config DisableForwarding option — Centos 7.9 (7.9.2009) OpenSSH 7.3, released August 01, 2016 FEATURE: Adds ProxyJump option (-J) FEATURE: Add an Include directive for ssh_config(5) files OpenSSH 7.1: August 20, 2015 This is a bugfix release. OpenSSH 7.0: August 11, 2015 The focus of this release is primarily to deprecate weak, legacy and unsafe cryptography. OpenSSH 6.9: July 1, 2015 BUGFIX: This is primarily a bugfix release. OpenSSH 6.8: March 18, 2015 Added new hostkeys@openssh.com extension to facilitate public key discovery and rotation for trusted hosts (for transition from DSA to Ed25519 public host keys) AuthenticationMethods=publickey,publickey to require that users authenticate using two different public keys OpenSSH 6.7: October 6, 2014 The default set of ciphers and MACs has been altered to remove unsafe algorithms. In particular, CBC ciphers and arcfour* are disabled by default. Compile-time option to not depend on OpenSSL Add support for Unix domain socket forwarding OpenSSH 6.6: March 16, 2014 This is primarily a bugfix release. OpenSSH 6.5: January 30, 2014 Added new ssh-ed25519 and ssh-ed25519-cert-v01@openssh.com public key types (available since 2005 but more popular since some suspicious that NSA had chosen values that gave them an advantage in factoring public-keys) Added new chacha20-poly1305@openssh.com transport cipher Added curve25519-sha256@libssh.org key exchange FEATURE: ssh, added Match keyword for ssh_config that allows conditional configuration to be applied FEATURE: client-side hostname canonicalisation: CanonicalDomains, CanonicalizeFallbackLocal, CanonicalizeHostname, CanonicalizeMaxDots and CanonicalizePermittedCNAMEs. Add a new private key format that uses a bcrypt KDF OpenSSH 6.4: November 8, 2013 This release fixes a security bug with AES-GCM OpenSSH 6.3: September 13, 2013 This release is predominantly a bugfix release OpenSSH 6.2: March 22, 2013 Add a GCM-mode for the AES cipher, similar to RFC 5647 Added support for encrypt-then-mac MAC modes Added support for multiple required authentication methods Added support for Key Revocation Lists (KRL) OpenSSH 6.1: August 29, 2012 This is primarily a bugfix release. Enables pre-auth sandboxing by default Finds ECDSA keys in ssh-keyscan and SSHFP DNS records by default now OpenSSH 6.0: April 22, 2012 This is primarily a bugfix release. OpenSSH 5.9: September 6, 2011 Introduce sandboxing of the pre-auth privilege separated child OpenSSH 5.8: February 4, 2011 OpenSSH 5.7: January 24, 2011 Added support for elliptic curve cryptography for key exchange as well as host/user keys, per RFC 5656 OpenSSH 5.6: August 23, 2010 Added a ControlPersistoption to ssh_config OpenSSH 5.5: April 16, 2010 OpenSSH 5.4: March 8, 2010 Disabled SSH protocol 1 default support. Clients and servers must now explicitly enable it. Added PKCS11 authentication support for ssh(1) (-I pkcs11) Added Certificate based authentication Added «Netcat mode» for ssh(1) (-W host:port). Similar to «-L tunnel», but forwards instead stdin and stdout. This allows, for example, using ssh(1) itself as a ssh(1) ProxyCommand to route connections via intermediate servers, without the need for nc(1) on the server machine. Added the ability to revoke public keys in sshd(8) and ssh(1). While it was already possible to remove the keys from authorised lists, revoked keys will now trigger a warning if used. OpenSSH 5.3: October 1, 2009 OpenSSH 5.2: February 23, 2009 OpenSSH 5.1: July 21, 2008 Added a MaxSessions option to sshd_config OpenSSH 5.0: April 3, 2008 OpenSSH 4.9: March 30, 2008 Added chroot support for sshd(8) Create an internal SFTP server for easier use of the chroot functionality OpenSSH 4.7: September 4, 2007 — Ubuntu 8.04 OpenSSH 4.6: March 9, 2007 OpenSSH 4.5: November 7, 2006 OpenSSH 4.4: September 27, 2006 OpenSSH 4.3: February 1, 2006 Added OSI layer 2/3 tun-based VPN (-w option on ssh(1)) OpenSSH 4.2: September 1, 2005 OpenSSH 4.1: May 26, 2005 OpenSSH 4.0: March 9, 2005 OpenSSH 3.9: August 18, 2004 Implement session multiplexing. ControlMaster option Added a MaxAuthTries option to sshd, allowing control over the maximum number of authentication attempts permitted per connection Added IdentitiesOnly option to ssh which specifies that it should use keys specified in ssh_config, rather than any keys in ssh-agent Re-introduce support for PAM password authentication OpenSSH 3.8: February 24, 2004 OpenSSH 3.7.1: September 16, 2003 OpenSSH 3.7: September 16, 2003 rhosts authentication has been removed in ssh(1) and sshd(8). OpenSSH 3.6.1: April 1, 2003 OpenSSH 3.6: March 31, 2003 OpenSSH 3.5: October 14, 2002 OpenSSH 3.4: June 26, 2002 OpenSSH 3.0: Improved Kerberos support in protocol v1 (KerbIV and KerbV) OpenSSH 2.9.9: OpenSSH 2.5.1p1: February 19, 2001 SkeyAuthentication absoleted, use ChallengeResponseAuthentication instead. OpenSSH 1.2.2p1: March 5, 2000
Подпишитесь на Telegram канал @aofeed чтобы следить за выходом новых статей и обновлением старых