Что передаются на компьютер администратора по протоколу ssh предикации подключения
Несколько советов об эффективном использовании SSH. Поговорим о том как:
Как оставить терминал открытым на удаленном хосте
Есть два варианта, как сохранить сессию, когда вы переключаетесь между сетями или хотите на время отключиться:
- ИспользуйтеMoshилиEternal Terminal
Если вам действительно нужно соединение, которое не падает, даже если вы переключаетесь между сетями, используйте Mosh — mobile shell. Mosh — это защищенная оболочка, использующая SSH для инициализации сессии (handshake), после чего переключается на собственный зашифрованный канал. Этот канал очень стабилен. Он может обрабатывать различные ситуации, включая разрывы соединения с интернетом, изменение IP-адреса вашего ноутбука, большие задержки при передаче по сети, и другие. Спасибо магии UDP и протокола синхронизации, используемого Mosh.
Для использования Mosh его необходимо установить как на вашем сервере, так и на клиенте и открыть порты в диапазоне 60000–61000 для входящего UDP трафика на вашем удаленном хосте. После чего просто наберите mosh user@server для подключения.
Mosh работает на уровне экранов терминала и нажатий клавиш, и это дает ему множество преимуществ по сравнению с SSH, который передает бинарный поток стандартного ввода-вывода между клиентом и сервером. Если нам нужно синхронизировать только экран терминала и нажатия клавиш, то прерванное соединение можно потом восстановить значительно быстрее. SSH пришлось бы хранить в буфере и пересылать все, что произошло, а Mosh нужно только сохранить нажатия клавиш и синхронизировать последнее состояние терминального окна с клиентом. - Используйте tmux. Если вы хотите подключаться и отключаться, когда вздумается и сохранять ту же самую сессию на удаленном хосте, используйте мультиплексор терминала tmux. Если ваше SSH-соединение отваливается, просто подключитесь снова и наберите tmux attach , чтобы вернуться в сессию tmux . В нем есть несколько отличных дополнительных возможностей — встроенные табы и панели, такие же как в терминале macOS и возможность расшарить терминал с другим пользователем.
Некоторые улучшают tmux с помощью Byobu — пакета, который добавляет множество удобных функций и сочетания клавиш. Byobu поставляется вместе с Ubuntu и его легко установить на macOS через менеджер пакетов Homebrew.
Заключение
SSH (Secure SHell - защищенная оболочка) - сетевой протокол прикладного уровня, предназначеный для безопасного удаленного доступа к UNIX-системам.
Пользователи Windows могут воспользоваться SSH-клиентом вроде PuTTy. Пользователи Linux или MacOS могут использовать SSH напрямую из окна терминала.
Существует три различных технологий шифрования, используемых SSH:
Использование SSH подключения имеет ряд преимуществ:
Безопасная работа на удаленном сервере с использованием командной оболочки;
Использование разных алгоритмов шифрования (симметричного, асимметричного и хеширования);
Возможность безопасного использования любого сетевого протокола, что позволяет передавать по защищенному каналу файлы любого размера.
Использование SSH подключения имеет свой недостаток:
Протокол SSH не имеет средств защиты от действий злоумышленника, получившего root-доступ. Одной из мер предосторожности является ограничение использования режима root без острой необходимости.
Периодически читая статьи, посвящённые SSH, обратил внимание, что их авторы порой не имеют понятия, как работает этот протокол. В большинстве случаев они ограничиваются рассмотрением темы генерации ключей и описанием опций основных команд. Даже опытные системные администраторы часто несут полную ахинею при обсуждении вопросов работы SSH, выдавая опусы в стиле: передаваемые данные шифруются открытым SSH-ключом клиента, а расшифровываются закрытым, или: для шифрования данных при передаче используется алгоритм RSA.
Попытаюсь внести немного ясности в работу протокола SSH, а заодно рассмотреть роль алгоритма RSA и ключей авторизации пользователя…
Алгоритм протокола SSH можно разделить на три уровня, каждый из которых располагается над предыдущим: транспорт (открытие защищённого канала), аутентификация, подключение. Для целостности картины я также добавлю уровень установки сетевого соединения, хотя официально этот уровень находится ниже SSH.
1. Установка TCP-соединения
Не буду подробно останавливаться на принципе работы стека TCP/IP, так как эта тема достаточно хорошо задокументирована в Рунете. При необходимости вы легко найдёте информацию.
На этом этапе происходит сетевое подключение клиента к серверу на TCP-порт, указанный в опции Port (по умолчанию: 22) в файле конфигурации сервера /etc/ssh/sshd_config.
2. Открытие защищенного канала
2.1 Обмен идентификационными данными
После установки TCP-соединения, клиент и сервер (далее по тексту – стороны) обмениваются версиями SSH-протокола и другими вспомогательными данными, необходимыми для выяснения совместимости протоколов и для выбора алгоритмов работы.
2.2 Выбор алгоритмов: обмена ключами, шифрования, сжатия и т.п.
При работе SSH используется довольно много алгоритмов, одни из них используются для шифрования, вторые для обмена ключами, третьи для сжатия передаваемых данных и т.п. На этом шаге стороны отсылают друг другу списки поддерживаемых алгоритмов, наибольший приоритет имеют алгоритмы в начале каждого списка. Затем сравнивают алгоритмы в полученных списках с алгоритмами, имеющимися в системе, и выбирают первый совпавший в каждом списке.
Список доступных алгоритмов обмена ключами на стороне клиента (используются для получения сессионного ключа) можно посмотреть командой:
Список доступных в системе симметричных алгоритмов (используются для шифрования канала):
Список типов ключей для авторизации у клиента:
Дополнено по замечанию onix74:
Все используемые в публикации команды актуальны для версии OpenSSH 7.6 из Ubuntu 18.04 LTS.
2.3 Получение сессионного ключа шифрования
Процесс получения сессионного ключа может отличаться в зависимости от версии алгоритма, но в общих чертах сводится к следующему:
- Сервер отсылает клиенту свой ключ (DSA, RSA или т.п. согласно договорённости между сторонами, произведёнными в п.2.2).
- Если клиент производит соединение с данным сервером впервые (о чем говорит отсутствие записи в файле /home/username/.ssh/known_hosts у клиента), то пользователю будет задан вопрос о доверии ключу сервера. Если же соединение с данным сервером уже устанавливалось ранее, то клиент сравнивает присланный ключ с ключом, записанным в /home/username/.ssh/known_hosts. Если ключи не совпадают, то пользователь получит предупреждение о возможной попытке взлома. Впрочем, эту проверку можно пропустить, если вызвать ssh с опцией StrictHostKeyChecking:
Также, если пользователю нужно удалить старый ключ сервера (например, когда есть точная уверенность, что ключ был изменён на сервере), то используется команда:
3. Аутентификация клиента
И только теперь, когда клиент и сервер установили канал для зашифрованной передачи данных, они могут произвести аутентификацию по паролю или ключам.
В общих чертах, аутентификация посредством ключей происходит следующим образом:
4. Уровень подключения
После проведения всех вышеперечисленных процедур, пользователь получает возможность передавать команды серверу или копировать файлы.
На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.
Новые ключи
Перед тем, как начать массовое шифрование данных, остался последний нюанс. Обе стороны должны создать шесть ключей: два для шифрования, два вектора инициализации (IV) и два для целостности. Вы можете спросить, зачем так много дополнительных ключей? Разве не достаточно общего секрета K? Нет, не достаточно.
Во-первых, почему нужны отдельные ключи для шифрования, целостности и IV. Одна из причин связана с историческим развитием протоколов, таких как TLS и SSH, а именно с согласованием криптографических примитивов. В некоторых выбранных криптографических примитивах повторное использование ключа не представляет проблемы. Но, как верно объясняет Хенрик Хеллстрём, при неправильном выборе примитивов (например, AES-256-CBC для шифрования и и AES-256-CBC-MAC для аутентификации) последствия могут быть катастрофическими. Следует отметить, что разработчики протоколов постепенно отказываются от такой гибкости, чтобы сделать протоколы более простыми и безопасными.
Далее, зачем используются ключи каждого типа.
Слева направо. (1) Открытый текст в виде изображения. (2) Криптограмма, полученная шифрованием в режиме ECB. (3) Криптограмма, полученная шифрованием в режиме, отличном от ECB. Изображение представляет собой псевдослучайную последовательность пикселей
Использование (и взлом) векторов IV — интересная тема сама по себе, о которой написал Филиппо Вальсорда.
Наконец, почему ключи идут в парах? Как отметил Томас Порнин, если используется только один ключ целостности, злоумышленник может воспроизвести клиенту отправленную ему запись, и он будет считать её действительной. Со спаренными ключами целостности (у сервера и клиента), клиент выполнит проверку целостности шифротекста и такой трюк не сработает.
Теперь с пониманием того, зачем нужны эти ключи, давайте посмотрим, как они генерируются, согласно RFC:
- Начальный вектор IV от клиента к серверу: HASH(K || H || «A» || session_id)
- Начальный вектор IV от сервера к клиенту: HASH(K || H || «B» || session_id)
- Ключ шифрования от клиента к серверу: HASH(K || H || «C» || session_id)
- Ключ шифрования от сервера к клиенту: HASH(K || H || «D» || session_id)
- Ключ контроля целостности от клиента к серверу: HASH(K || H || «E» || session_id)
- Ключ контроля целостности от сервера к клиенту: HASH(K || H || «F» || session_id)
Здесь используется алгоритм хэширования SHA в зависимости от алгоритма обмена ключами, а символ || подразумевает конкатенацию, то есть сцепление.
Как только вычислены эти значения, обе стороны посылают SSH_MSG_NEWKEYS , чтобы сообщить другой стороне, что обмен ключами завершён, а все будущие коммуникации должны происходить с использованием новых ключей, созданных выше.
Рис. 4:. Генерация начального вектора IV. Генерация для других ключей происходит по той же схеме, если заменить A и B на C, D, E и F, соответственно
Как устанавливается сессия SSH?
Есть несколько шагов, которые нужно пройти, чтобы начать SSH-сеанс между компьютерами.
После этих трёх шагов мы можем безопасно общаться с удалённым компьютером, делиться секретными данными, а также проверить, есть ли у клиента разрешение на доступ к хосту. Каждый из разделов ниже будет более подробно описывать эти действия.
Обмен ключами
В процессе обмена ключами (иногда называемого KEX) стороны обмениваются общедоступной информацией и выводят секрет, совместно используемый клиентом и сервером. Этот секрет невозможно обнаружить или получить из общедоступной информации.
Инициализация обмена ключами
Криптографические примитивы должны установить строительные блоки, которые будут использоваться для обмена ключами, а затем полного шифрования данных. В таблице ниже перечислены криптографические примитивы, которые поддерживает Teleport.
Криптографические примитивы Teleport по умолчанию
Инициализация протокола Диффи — Хеллмана на эллиптических кривых
Стоит подчеркнуть, что эта ключевая пара эфемерна: она используется только для обмена ключами, а затем будет удалена. Это чрезвычайно затрудняет проведение класса атак, где злоумышленник пассивно записывает зашифрованный трафик с надеждой украсть закрытый ключ когда-нибудь в будущем (как предусматривает закон Яровой — прим. пер.). Очень трудно украсть то, чего больше не существует. Это свойство называется прямой секретностью (forward secrecy).
Ответ по протоколу Диффи — Хеллмана на эллиптических кривых
Затем сервер генерирует нечто, называемое хэшем обмена H, и подписывает его, генерируя подписанный хэш HS (подробнее на рис. 3). Хэш обмена и его подпись служат нескольким целям:
- Поскольку хэш обмена включает общий секрет, он доказывает, что другая сторона смогла создать общий секрет.
- Цикл подписи/проверки хэша и подписи обмена позволяет клиенту проверить, что сервер владеет закрытым ключом хоста, и поэтому клиент подключен к правильному серверу (если клиент может доверять соответствующему открытому ключу, подробнее об этом позже).
- За счёт подписи хэша вместо подписи входных данных, размер подписываемых данных существенно уменьшается и приводит к более быстрому рукопожатию.
Рис. 2. Генерация хэша обмена H
Как только клиент получил от сервера SSH_MSG_KEX_ECDH_REPLY , у него есть всё необходимое для вычисления секрета K и хэша обмена H .
В последней части обмена ключами клиент извлекает открытый ключ хоста (или сертификат) из SSH_MSG_KEX_ECDH_REPLY и проверяет подпись хэша обмена HS , подтверждающую право собственности на закрытый ключ хоста. Чтобы предотвратить атаки типа «человек в середине» (MitM), после проверки подписи открытый ключ хоста (или сертификат) проверяется по локальной базе известных хостов; если этот ключ (или сертификат) не является доверенным, соединение разрывается.
SSH-клиент предлагает добавить ключ хоста в локальную базу известных хостов. Для OpenSSH это обычно ~/.ssh/known_hosts
Рис. 3. Генерация ответа при обмене ключами ECDH
Выход из зависшей SSH-сессии
SSH-сессии часто зависают из-за разрывов сети, потери контроля выполняемой программой или одной из управляющих последовательностей терминала, которые блокируют ввод с клавиатуры.
Вот несколько способов, как выйти из зависшей сессии:
-
Автоматический выход при разрыве сети. В вашей SSH-конфигурации .ssh/config нужно добавить:
Почему сессии зависают? Когда был изобретен Интернет, компьютеры были не особо мобильными. Когда вы работаете на ноутбуке и переключаетесь между IPv4 WiFi сетями, ваш IP-адрес меняется. Так как SSH базируется на TCP-соединении, а TCP-соединения зависят от точек подключения с неизменными IP-адресами, то каждый раз, когда вы подключаетесь к другой сети, ваше SSH-соединение теряется. Когда ваш IP-адрес меняется, проходит некоторое время, прежде чем сетевой стек обнаружит, что соединение потеряно. TCP-соединение не предполагает быстрое закрытие соединения одной из сторон в случае проблем в сети, поэтому оно будет пытаться повторять отправку данных еще какое-то время. В вашем же терминале сессия будет выглядеть зависшей. IPv6 добавляет функциональность, позволяющую устройствам сохранять свой IP-адрес при переключении между сетями. Так что когда-нибудь это перестанет быть проблемой.
Хеширование
Одностороннее хеширование — это еще одна форма криптографии, которая используется в SSH. Такого рода хеширование отличается от двух упомянутых выше тем, что оно не предназначено для дешифровки. Оно создает уникальное значение фиксированной длины для каждого ввода, которое не показывает никакого общего поведения для его раскрытия. Это делает его практически невозможным для обратного преобразования.
Что такое SSH?
SSH — сокращение от «secure shell» (безопасная оболочка). Это протокол, который чаще всего используют для управления удалёнными компьютерами по сети.
Симметричное шифрование
Базовые SSH команды
ls - Показать содержимое каталога (список названий файлов);
cd - Сменить каталог (перейти в другой);
mkdir - Создать новую папку (каталог);
touch - Создать новый файл;
rm - Удалить файл;
cat - Показать содержимое файла;
pwd - Показать текущий каталог (полный путь к этому каталогу);
cp - Копировать файл/папку;
mv - Переместить файл/папку;
grep - Поиск конкретной фразы в файле;
find - Поиск файлов и папок;
vi \ nano - Текстовые редакторы;
history - Показать 50 последних использованных команд;
clear - Очистить окно терминала.
Как видишь, это просто базовые команды терминала.
Преимущества
Использование SSH подключения имеет ряд преимуществ:
Безопасная работа на удаленном сервере с использованием командной оболочки;
Использование разных алгоритмов шифрования (симметричного, асимметричного и хеширования);
Возможность безопасного использования любого сетевого протокола, что позволяет передавать по защищенному каналу файлы любого размера.
Главным преимуществом SSH является использование шифрования для защиты передачи данных между хостом и клиентом. Хост — это удаленный сервер к которому ты хочешь получить доступ, тогда как клиент — это компьютер с которого ты пытаешься получить доступ к хосту.
Настройка зашифрованного канала
Вся информация, отправляемая с использованием SSH, зашифрована. Обе стороны должны знать и понимать способ шифрования.
Для шифрования передаваемых данных используется симметричное шифрование. Суть данного подхода заключается в том, что оба компьютера имеют одинаковый ключ шифрования, который называется «симметричный ключ». Симметричное шифрование работает очень хорошо, но только до тех пор, пока сторонние не имеют доступа к ключу.
Решение этой проблемы состоит в использовании протокола обмена ключами Диффи-Хеллмана. Оба компьютера создают свой закрытый и открытый ключ. Вместе они образуют пару ключей. Компьютеры делятся своими открытыми ключами друг с другом через интернет. Используя свой закрытый и чужой открытый ключ, стороны могут независимо сгенерировать одинаковый симметричный ключ.
Заключение
Верификация
Следующий этап процесса установки сеанса SSH заключается в проверке того, что данные не были подделаны во время их передачи и что другой компьютер действительно является тем, за кого себя выдаёт.
Для верификации используют хеш-функцию. Это математическая функция, которая принимает входные данные и создаёт строку фиксированного размера.
Важной особенностью этой функции является то, что практически невозможно определить входные данные, зная лишь результат её работы.
Функция хеширования использует:
Когда хост получает HMAC, он может использовать ту же самую хеш-функцию с этими тремя компонентами:
Если сформированный хеш совпадает с HMAC, полученным от клиента, то мы можем быть уверены, что подключаемый компьютер — это компьютер с симметричным ключом, потому что только хост и клиент знают симметричный ключ, а другие компьютеры — нет.
Прелесть этого подхода в том, что мы не просто проверили личность клиента и убедились, что данные не были подделаны, но мы сделали это без передачи какой-либо секретной информации.
Заключение
На этом этапе обе стороны согласовали криптографические примитивы, обменялись секретами и сгенерировали материал ключей для выбранных примитивов. Теперь между клиентом и сервером может быть установлен безопасный канал, который обеспечит конфиденциальность и целостность.
Вот как рукопожатие SSH устанавливает безопасное соединение между клиентами и серверами.
В этой статье мы рассмотрим, как работает SSH, как он используется для безопасной связи с удалёнными компьютерами и как компьютеры устанавливают и настраивают сеанс.
Аутентификация
Даже если мы используем симметричные ключи для безопасного общения, мы не знаем, имеет ли подключающийся компьютер разрешение на доступ к содержимому хоста. Для того чтобы проверить это, необходимо произвести аутентификацию.
Более безопасной является аутентификация по сертификату. Сформировав сертификат, клиент единожды вводит пароль для доступа к серверу и отправляет ему открытую часть сертификата. В дальнейшем ввод пароля не требуется. Этот подход считается более безопасным, чем просто использование пароля, поскольку не подразумевает хранение секрета пользователя на хосте.
Безопасное использование проброса ключа (agent forwarding)
Проброс ключа в SSH дает доступ удаленному хосту к вашему локальному SSH-агенту. Когда ваш SSH-клиент использует проброс ключа (обычно активируется опцией ssh -A ), в соединении присутствуют 2 канала — ваша интерактивная сессия и канал проброса ключа. Локальный SSH-агент создает IPC-сокет, который подключается к удаленному хосту через этот канал. Это опасно, т.к. пользователь с правами уровня root на удаленном хосте имеет доступ к вашему локальному SSH-агенту и потенциально может использовать его для доступа к ресурсам сети от вашего имени. Со стандартным SSH-агентом, который поставляется в составе OpenSSH, вы ни за что не узнаете, что такое произошло. Но если вы используете U2F ключ (или Sekey), вы сможете пресекать любые попытки использования вашего SSH-агента.
Даже с таким ограничением, периодическое использование проброса ключа вполне допустимо. Не используйте этот метод для всех своих подключений. Применяйте, если только вы уверены в его необходимости в конкретных ситуациях.
Недостатки
Использование SSH подключения имеет свой недостаток:
Протокол SSH не имеет средств защиты от действий злоумышленника, получившего root-доступ. Одной из мер предосторожности является ограничение использования режима root без острой необходимости
Многофакторная аутентификация в SSH
Существует пять способов, как добавить второй фактор для аутентификации в SSH:
- Обновите OpenSSH и используйте аппаратные токены (ключевые носители). В феврале 2020 года в OpenSSH добавили поддержку токенов FIDO U2F (Universal Second Factor). Это отличная новая функция, но есть нюанс.
Так как это обновление добавляет новые типы ключей для поддержки токенов, его можно использовать только, если обновить и клиента и сервер до версии 8.2 или более поздней. Текущую версию клиента можно проверить командой ssh -V , для удаленного сервера можно использовать nc [servername] 22 .
Также были добавлены два новых типа ключей — ecdsa-sk и ed25519-sk (с соответствующими типами сертификатов). Для создания ключевых файлов вставьте ваш токен в компьютер и выполните команду $ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk . Эта команда создаст открытый и закрытый ключи, привязанные к вашему U2F токену. Закрытый ключ на U2F устройстве используется для расшифровки файла закрытого ключа, хранящегося на диске.
Также в качестве второго фактора можно задать пароль для ключевых файлов. OpenSSH поддерживает еще один вариант генерации ключей типа -sk -«резидентные» ключи. В этом случае ключевые файлы хранятся на U2F токене. Таким образом, ключи будут всегда у вас с собой. Создать резидентный ключ можно командой $ ssh-keygen -t ecdsa-sk -O resident -f ~/.ssh/id_ecdsa_sk . Чтобы перенести ключевой файл на новую машину, необходимо вставить ключевой носитель и выполнить команду $ ssh-add -K . Необходимо будет активировать ваш токен при подключении. - Используйте PIV+PKCS11 и Yubikey. Если вы хотите подключаться к машинам, где установлены более ранние версии SSH-сервера, вы можете использовать токен другим способом. Проект Yubikey публикует инструкцию U2F+SSH with PIV/PKCS11. Это не тоже самое, что в случае с FIDO U2F. Нужно немного напрячься, чтобы разобраться.
- Используйте ssh-агент yubikey-agent .Filippo Valsorda сделал SSH-агента для Yubikeys. Он совсем новый и пока имеет минимальный набор функций.
- Используйте Touch ID и sekey .Sekey — это SSH-агент с открытым исходным кодом, который сохраняет закрытые ключи в системе secure enclave для MacOS и позволяет использовать функцию подписания через Touch ID.
- ИспользуйтеSingle Sign On SSH. Здесь можно найти инструкцию по настройке. Преимущество Single Sign On SSH заключается в том, что вы можете использовать политику безопасности вашего поставщика учетных записей, включая поддержку многофакторной аутентификации.
Асимметричное шифрование
В отличии от симметричного шифрования, асимметричное использует два отдельных ключа для шифрования и дешифровки. Эти два ключа также известны как приватный и публичный ключи. Вместе они формируют пару публичных-приватных ключей.
Как использовать
Пользователи Windows могут воспользоваться SSH-клиентом вроде PuTTy.
Пользователи Linux или MacOS могут использовать SSH напрямую из окна терминала.
SSH команда состоит из 3 отдельных частей:
Обмен версиями
Рукопожатие начинается с того, что обе стороны посылают друг другу строку с номером версии. В этой части рукопожатия не происходит ничего чрезвычайно захватывающего, но следует отметить, что большинство относительно современных клиентов и серверов поддерживают только SSH 2.0 из-за недостатков в дизайне версии 1.0.
Технологий шифрования
Существует три различных технологий шифрования, используемых SSH:
Как расшарить удаленный терминал с другом
Когда решаешь сложную проблему с серверами, хотелось бы расшарить SSH-сессию с кем-то еще, кто находится в другом месте. tmux — это лучший инструмент для шаринга терминала. Итак, нужно сделать следующее:
- Убедитесь, что tmux установлен на вашем сервере в DMZ (или куда вы хотите подключиться).
- Вам обоим необходимо подключиться к серверу через SSH, используя один и тот же аккаунт.
- Один из вас должен запустить tmux , чтобы создалась tmux -сессия.
- Другой должен выполнить команду tmux attach .
- Вуаля! Вы расшарили терминал.
Если вам нужна более тонкая настройка мульти-пользовательских сессий, используйте tmate, это форк tmux , который позволяет делать расшаренные сессии еще проще.
SSH (Secure SHell - защищенная оболочка) — сетевой протокол прикладного уровня, предназначеный для безопасного удаленного доступа к UNIX-системам. Данный протокол эффективен тем, что шифрует всю передаваемую информацию по сети. По умолчанию, используется 22-й порт. В основном он нужен для удаленного управления данными пользователя на сервере, запуска служебных команд, работы в консольном режиме с базами данных.
От теории к практике
Ну а теперь, думаю, у читателей назрел вполне закономерный вопрос: а зачем нужно знать все эти тонкости работы SSH-протокола, если для повседневной работы достаточно знаний команд создания ключей (ssh-keygen), открытия терминальной сессии (ssh), передачи файлов (scp)?
В качестве ответа, можно вспомнить тему о смене стандартного порта SSH на какой-то другой, которая постоянно становится причиной холивара на Хабре…
В собственной практике я не припомню ни одного смотрящего во внешнюю сеть сервера, который бы ежедневно не подвергался долбёжке на 22-й порт. В ситуации, если SSH у вас работает на стандартном порту (и ничем дополнительно не защищён), даже если аутентификация исключительно по ключам и никакие подборы паролей не пугают, то по причине постоянно валящихся запросов от недобросовестных клиентов сервер всё равно вынужден совершать массу бесполезной работы: устанавливать TCP-соединение, выбирать алгоритмы, генерировать сессионный ключ, отправлять запросы аутентификации, писать лог-файл.
В ситуации же, когда на 22-м порту ничего нет, или порт защищён с помощью iptables (либо надстройками над ним типа fail2ban), то злоумышленник будет дропнут ещё на этапе установки TCP-соединения.
Secure Shell (SSH) — широко используемый протокол транспортного уровня для защиты соединений между клиентами и серверами. Это базовый протокол в нашей программе Teleport для защищённого доступа к инфраструктуре. Ниже относительно краткое описание рукопожатия, которое происходит перед установлением безопасного канала между клиентом и сервером и перед началом полного шифрования трафика.
Читайте также: