Ssh sshd чем отличаются
Что такое SSH и чем он отличается от FTP
Различные способы общения используются в разных случаях. Есть различные возможности использования и различные подводные камни. Но как именно связаные друг с другом протоколы SSH и FTP, неясно большинству.
«Оболочка» и учётная запись «оболочки»
Давайте попробуем разобраться с некоторой базовой терминологией. Что бы понять назначение SSH, необходимо знать некоторые базовые элементы.
Shell (оболочка) компьютера, является частью программного обеспечения, которое позволяет пользователю напрямую взаимодействовать с ядром различных операционных систем. «Оболочка» может иметь графический интерфейс и/или интерфейс командной строки (т.н. консоль).
Учётная запись в оболочке, является личной учётной записью, которая предоставляет пользователю доступ к оболочке на другом компьютере. Раньше они были обычным явлением и поставлялись провайдерами Интернет-услуг, которые использовались для хранения файлов, учетных записей электронной почты, групп новостей и многого другого. Общим знаменателем является то, что учетная запись оболочки используется для ввода команд на удаленном компьютере.
SSH использует шифрование с открытым ключом и был разработан в качестве замены Telnet и других небезопасных протоколов. Две основные версии, SSH-1 и SSH-2, в настоящее время являются доминирующими протоколами для доступа к учетным записям оболочки.
В наши дни SSH используется для входа и выполнения кода на удаленных хостах, просмотра веб-страниц с использованием зашифрованных прокси-клиентов и передачи файлов.
Протокол безопасной передачи файлов (SFTP) и FTP
Хоть это и не указано в документации для конечного пользователя, SFTP можно рассматривать как надежного родственника FTP. Последний передает все данные в виде простого текста. Таким образом, перехват пакетов может раскрыть важные и личные данные, включая ваше имя пользователя и пароль! SFTP, являясь расширением SSH-2, использует защиту с помощью открытого ключа. Это означает, что данные зашифрованы, когда они передаются, и потенциальные перехваты относительно бесполезны.
Я надеюсь, что вы узнали что-то из этой статьи. Если у вас есть какие-либо вопросы или предложения, отправляйтесь в раздел комментариев ниже!
Что такое SSH и sFTP?
С помощью защищенного протокола SSH администраторы подключаются к своим серверам для безопасной работы. Рассмотрим особенности этого протокола подробнее:
Что такое SSH-протокол
SSH-протокол (от англ. Secure Shell) — криптографический сетевой протокол, предназначенный для удаленного доступа к операционной системе и осуществления безопасного удаленного управления в рамках незащищенной сети (например, через интернет).
SSH обеспечивает защищённый канал связи между клиентом и сервером, через который можно передавать данные (почтовые, видео, файлы), работать в командной строке, удаленно запускать программы, в том числе графические. SSH-сервер должен быть установлен на удаленной операционной системе. SSH-клиент должен быть запущен на машине, с которой будет осуществляться удаленное подключение.
Основные функции, доступные при использовании SSH-протокола:
Безопасность SSH-соединения обеспечивается:
Аутентификация сервера дает защиту от:
На сегодняшний день существуют две версии протокола SSH (SSH-1 и SSH-2), причем вторая версия усовершенствована и расширена по сравнению с первой. Например, вторая версия устойчива к атакам вида MITM («человек посередине», атака посредника). Также существуют две редакции данного протокола: открытая версия (бесплатная) и коммерческая (платная). Бесплатная версия — OpenSSH — встроена во все UNIX-подобные операционные системы в виде стандартных утилит SSH-клиента и SSH-сервера.
Коммерческая реализация SSH-протокола — SSH Communications Security — разработана одноименной организацией. Имеет небольшие отличия от бесплатной версии, такие как доступность коммерческой технической поддержки, наличие инструментов веб-управления и др. Основной набор команд и возможностей практически одинаковый у обоих продуктов.
Передача данных по SSH-протоколу через небезопасную сеть
Что такое SFTP-протокол
SFTP-протокол (от англ. SSH File Transfer Protocol) – сетевой протокол прикладного уровня, предназначенный для передачи файлов и других действий с ними через имеющееся надежное соединение. Протокол был разработан как расширение SSH-2, предназначенное для операций с файлами по защищенному каналу, однако может работать и с другими протоколами, обеспечивающими безопасное соединение сервера с клиентом. Иными словами, для надежной работы через SFTP-протокол необходимо иметь установленное защищенное соединение (например, SSH), которое проводит аутентификацию клиента и сервера и устанавливает факт их надежности, поскольку сам SFTP-протокол не проводит аутентификацию и не обеспечивает безопасность.
SFTP имеет ряд преимуществ перед своими предшественниками — FTP и SCP — таких, как прерывание передачи файла, удаление, возобновление передачи, связь переданных файлов с основными атрибутами, например, меткой даты/времени, а также более высокая платформонезависимость.
SFTP-протокол реализуется через SFTP-сервер и SFTP-клиент, которые являются подсистемами OpenSSH.
Для чего используются SSH и SFTP протоколы
Чаще всего протоколы SSH и SFTP используются для удаленной работы с операционной системой или переноса большого количества файлов.
Например, клиент берет в аренду сервер или какую-то часть серверного пространства. Возникает необходимость переносить туда уже имеющиеся данные клиента, например, сайт или почтовые файлы. Провайдер должен обеспечить надежность и быстроту обмена данными с его сервером, особенно если речь идет о больших объемах информации и ее высокой конфиденциальности. В этом случае на удаленной машине (в данном случае — виртуальном сервере) устанавливается SSH-сервер (со встроенным SFTP-протоколом), а на клиентском компьютере — SSH-клиент. Создается SSH-туннель, и обмен данными между клиентом и удаленным сервером осуществляется через надежное соединение со всеми преимуществами протокола, описанными выше.
Также SSH может использоваться для удаленной работы по защищенному соединению с различными сервисами провайдера, такими как программное обеспечение, операционные системы и т.д.
Как работает SSH
По протоколу SSH работает набор программ, служащих для выполнения различных действий на удаленной операционной системе. Например, программа sshd обеспечивает серверную функциональность SSH, она должна быть запущена на SSH-сервере. Программа ssh запускается на SSH-клиенте и позволяет устанавливать соединение с удаленным хостом, регистрироваться на нем, работать с удаленной машиной через SSH-соединение.
Для запуска тех или иных программ SSH-протокола существуют специальные команды с набором различных опций. Эти команды могут отличаться в зависимости от используемой клиентской операционной системы и оболочки SSH-клиента. Команды запускаются либо из командной строки, если речь идет о UNIX-подобных системах, либо посредством графического интерфейса в соответствующих SSH-оболочках.
Магия SSH
С SSH многие знакомы давно, но, как и я, не все подозревают о том, какие возможности таятся за этими магическими тремя буквами. Хотел бы поделиться своим небольшим опытом использования SSH для решения различных административных задач.
1) Local TCP forwarding
Начнем с простого — local TCP forwarding:
Имеем удаленный сервер «host2» с неким приложением, допустим, PostgreSQL server, которое принимает TCP-соединения на порту 5432. При этом вполне логично, что на этом сервере стоит файрвол, который прямых соединений извне на порт 5432 не разрешает, но при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить). Требуется подключиться с нашего рабочего места «host1» клиентским приложением к серверу PostgreSQL на «host2».
Для этого на «host1» в консоли набираем:
Теперь на «host1» мы можем соединяться с PostgreSQL сервером через локальный порт 9999:
Мы также можем соединяться с приложением не на самом «host2», а на любой доступной ему машине:
Для этого при пробросе портов вместо «localhost» указываем имя хоста, например «host3»:
Тут важно заметить, что «host3» должен быть известен (если это имя, а не IP-адрес) и доступен для машины «host2».
Также можно через «host1» предоставить доступ любому другому узлу (назовем его «host1A») к сервису на «host3»:
Для этого нужно вставить в команду соединения ssh IP-адрес интерфейса, на котором будет поднят локальный порт 9999:
В данном примере порт 9999 будет открыт на всех доступных на «host1» IPv4 интерфейсах.
2) Remote TCP forwarding
Но что делать, если, например, «host2» не имеет белого IP-адреса, находится за NAT или вообще все входящие соединения к нему закрыты? Или, например, на «host2» стоит Windows и нет возможности поставить SSH-сервер?
Для этого случая есть Remote TCP forwarding:
Теперь нужно устанавливать ssh-соединение в обратном направлении — от «host2» к «host1». Т.е. наша административная рабочая станция будет SSH-сервером и будет доступна по SSH с «host2», а на «host2» нужно будет выполнить подключение SSH-клиентом:
Например, в PuTTy это делается так:
Идем по дереву настроек: Connection → SSH → Tunnels.
Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, а ниже выбираем «Remote», и нажимаем Add.
Не забываем после этого сохранить настройки сессии, если требуется.
Также у вас возникнут дополнительные сложности с обеспечением безопасности на «host1», если вы не доверяете узлу «host2». Однако это выходит за рамки данной статьи.
И, конечно, вы каким-то образом (сами или с посторонней помощью) должны инициировать ssh-соединение со стороны «host2» вводом приведенной выше команды, а «host1» должен иметь белый IP-адрес и открытый порт SSH.
После установки ssh-соединения все работает аналогично предыдущей главе.
3) TCP forwarding chain через несколько узлов
В закрытых сетях часто бывает, что нужный нам узел напрямую недоступен. Т.е. мы можем зайти на нужный хост только по цепочке, например host1 → host2 → host3 → host4:
host1# ssh host2
host2# ssh host3
host3# ssh host4
host4# echo hello host4
Это может происходить например если эти узлы являются шлюзами, либо если на них доступны шлюзы только в соседние подсети.
В таком случае мы также можем делать TCP forwarding по цепочке:
Здесь порты 9991, 9992, 9993 выбраны для наглядности, на практике можно использовать один и тот же порт (например, 9999), если он свободен на всех узлах.
Итого нужно выполнить следующую цепочку команд:
После успешного выполнения перечисленных выше команд, на узлах выполняется следующее:
ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).
4) TCP forwarding ssh-соединения
Иногда бывает нужно соединиться по ssh с сервером, который напрямую недоступен, а доступ возможен только по цепочке ssh-серверов (см. предыдущую главу). Теперь мы обладаем нужными знаниями чтобы сделать следующее:
Таким образом, на порту 2222 на «host1» у нас теперь есть форвардинг на порт SSH (22) на «host4». Можем соединиться:
Казалось бы, зачем это нужно? Например, вот зачем:
Ну и вообще, здорово что теперь «host4» так близко 🙂
Вывод: можно делать TCP forwarding большого уровня вложенности.
Если пользуетесь одним и тем же портом (2222) для доступа к разным удаленным серверам, то будут ошибки RSA fingerprint, который остался от предыдущего сервера. Его нужно будет удалить из
5) SSH VPN Tunnel
TCP port forwarding — это отличная возможность. Но что если нам нужно больше? Доступ по UDP, доступ к множеству портов и хостов, доступ к динамическим портам? Ответ очевиден — VPN. И всемогущий SSH начиная с версии 4.3 и здесь придет нам на помощь.
Забегая вперед скажу: этот функционал SSH хорошо работает если вам нужно временное решение для каких-то административных задач. Для построения постоянных VPN этот вариант далеко не самый подходящий, т. к. он предполагает TCP-over-TCP, что плохо скажется на скорости соединения.
Настройка SSH-сервера:
PermitTunnel в настройках sshd по-умолчанию выключен, его нужно включить в /etc/ssh/sshd_config:
PermitTunnel yes
или
PermitTunnel point-to-point
ВАЖНО: для поднятия нового сетевого интерфейса туннеля и на ssh-клиенте, и на ssh-сервере необходимы права суперпользователя. Можно долго спорить о том, насколько это небезопасно, но в большинстве случаев на ssh-сервере достаточно настройки:
Таким образом вы запрещаете вход root по паролю, а разрешаете только другими средствами, например, по ключу RSA, что гораздо безопаснее.
Перезапускаем sshd:
sudo service sshd restart # centos
или
/etc/init.d/ssh restart # (debian/ubuntu)
host1# ifconfig tun5
tun5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Назначаем интерфейсам IP-адреса и поднимаем их:
host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102
host2# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101
Если есть файрвол, не забываем разрешить соединения с интерфейса tun5:
На host1 это делать необязательно, здесь это сделано лишь для того чтобы ping работал в обе стороны.
host1# ping 192.168.150.102
host2# ping 192.168.150.101
Если рассмотреть более ранний пример с PostgreSQL, то теперь схема будет такая:
А команда для подключения к серверу PostgreSQL будет выглядеть так:
Ну а далее можно делать какой-либо из этих узлов шлюзом, если нужно обеспечить доступ не к одному узлу, а к сети. Например:
host1# # Предположим, у host2 есть доступ к сети 192.168.2.x, куда нам нужно попасть с host1
host1# # Прописываем host2 как шлюз в сеть 192.168.2.x
host1# sudo ip route add 192.168.2.0/24 via 192.168.150.2
host1# # Наслаждаемся доступом в сеть с host1
host1# ping 192.168.2.1
После окончания работы не забываем вернуть net.ipv4.ip_forward и файрвол в исходное состояние.
host1# sudo iptables-restore
Допустим, нужно настроить сервер в закрытой сети, где доступ в Интернет запрещен, но тем не менее у вас туда есть лазейка — доступ через один ssh-сервер или цепочку ssh-серверов. Предположим, для настройки сервера вам нужен на нем доступ в Интернет. Тогда проще самостоятельно настроить временный доступ в Интернет на требующем настройки сервере, чем просить это сделать обслуживающий персонал.
Допустим, есть доступ по ssh с вашей рабочей машины host1 на сервер host2, с него — на host3, а уже оттуда — на нужный вам host4. Тогда делаем TCP forwarding для ssh (если с host1 вы сразу можете соединиться с host4, пропустите этот шаг):
Далее, соединяемся с host4 и поднимаем интерфейс tun5:
Смотрим таблицу маршрутизации на host4, допустим видим следующее:
ВАЖНО! Далее нам скорее всего захочется сделать маршрутом по-умолчанию интерфейс tun5 со шлюзом 192.168.150.101, через который будет доступен Интернет. Поэтому на данном этапе важно точно знать, какие маршруты нужно дописать, чтобы заменить маршрут по-умолчанию. Это важно, поскольку довольно часто маршруты на отдельные сети не прописывают отдельно, а просто задают маршрут по-умолчанию (0.0.0.0/0) со шлюзом, через который и идет весь межсетевой трафик. Более того, вполне вероятно что ваше ssh-соединение с сервером также использует исходный шлюз по-умолчанию.
Для простоты в данном примере предположим, что никаких маршрутов кроме 192.168.56.0/24 серверу для нормального функционирования не нужно и что предыдущий ssh-хост host3 имеет IP-адрес из этой же сети.
Настраиваем наш host1 для работы в качестве шлюза в Интернет для host4:
Изменяем маршрут по-умолчанию на host4 (ОСТОРОЖНО, см. предупреждение выше!):
Если весь Интернет нам не нужен, а только конкретные IP-адреса/маски, то можно маршрут по-умолчанию не менять, а дописать только нужные нам адреса через шлюз на tun5.
Проверяем, что есть Интернет:
Отлично. Осталось настроить DNS. Есть множество способов это сделать, проще всего отредактировать файл /etc/resolv.conf и добавить туда строчки:
nameserver 8.8.8.8
nameserver 8.8.4.4
После этого Интернет должен быть полностью доступен:
После окончания работы не забываем вернуть все в исходное состояние:
host1# # восстанавливаем правила файрвола на host1
host1# sudo iptables-restore
host2# # восстановите маршрут по-умолчанию на host4:
host2# sudo ip route replace default via 192.168.56.254
host2# # и уберите добавленные ранее DNS-сервера из /etc/resolv.conf
6) Коротко о беспарольном доступе
Думаю, все уже знают что авторизация по паролю это не про нас. Но на всякий случай впихну сюда краткую инструкцию по настройке аутентификации по ключу RSA:
1. На клиентских машинах генерируем пользователю свой ключ RSA:
По-умолчанию приватный ключ сохраняется в
/.ssh/id_rsa, а открытый — в
/.ssh/id_rsa.pub. Приватный ключ храните как зеницу ока и никому не давайте, никуда не копируйте.
При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.
2. Клиентские открытые ключи нужно сохранить на ssh-сервере в файле
это домашняя директория того пользователя, которым будете логиниться), каждый на отдельной строке. Для того чтобы это не делать вручную, на каждом клиенте можно воспользоваться командой:
Где user — имя пользователя на сервере, sshserver — имя или IP-адрес ssh-сервера.
/.ssh/authorized_keys на ssh-сервере необходимо задать следующие права:
chmod 0700
3. Проверьте, что можете зайти на сервер по ключу, без ввода пароля (не путать с passphrase):
ssh user@sshserver
Рекомендую не закрывать хотя бы одну активную ssh-сессию с сервером до тех пор, пока окончательно не закончите настройку и не убедитесь что все работает.
4. Отключите на SSH-сервере возможность входа по паролю в файле /etc/ssh/sshd_config:
Возможность входа по открытому ключу обычно уже включена по-умолчанию:
Я обычно также отключаю две следующие опции:
GSSAPIAuthentication no
UseDNS no
В некоторых случаях это позволяет ускорить процесс соединения (например, когда на сервере нет доступа в Интернет).
5. Перезапустите sshd:
service sshd restart
или
/etc/init.d/ssh restart
Алгоритм установления соединения в протоколе SSH
(Начальное название статьи «Алгоритм работы протокола SSH» было изменено по рекомендациям Vindicar, Karroplan и других участников хабросообщества)
Периодически читая статьи, посвящённые 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 Получение сессионного ключа шифрования
Процесс получения сессионного ключа может отличаться в зависимости от версии алгоритма, но в общих чертах сводится к следующему:
3. Аутентификация клиента
И только теперь, когда клиент и сервер установили канал для зашифрованной передачи данных, они могут произвести аутентификацию по паролю или ключам.
В общих чертах, аутентификация посредством ключей происходит следующим образом:
4. Уровень подключения
После проведения всех вышеперечисленных процедур, пользователь получает возможность передавать команды серверу или копировать файлы.
На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.
От теории к практике
Ну а теперь, думаю, у читателей назрел вполне закономерный вопрос: а зачем нужно знать все эти тонкости работы SSH-протокола, если для повседневной работы достаточно знаний команд создания ключей (ssh-keygen), открытия терминальной сессии (ssh), передачи файлов (scp)?
В качестве ответа, можно вспомнить тему о смене стандартного порта SSH на какой-то другой, которая постоянно становится причиной холивара на Хабре…
В собственной практике я не припомню ни одного смотрящего во внешнюю сеть сервера, который бы ежедневно не подвергался долбёжке на 22-й порт. В ситуации, если SSH у вас работает на стандартном порту (и ничем дополнительно не защищён), даже если аутентификация исключительно по ключам и никакие подборы паролей не пугают, то по причине постоянно валящихся запросов от недобросовестных клиентов сервер всё равно вынужден совершать массу бесполезной работы: устанавливать TCP-соединение, выбирать алгоритмы, генерировать сессионный ключ, отправлять запросы аутентификации, писать лог-файл.
В ситуации же, когда на 22-м порту ничего нет, или порт защищён с помощью iptables (либо надстройками над ним типа fail2ban), то злоумышленник будет дропнут ещё на этапе установки TCP-соединения.
Лучшие SSH-клиенты для Windows, Linux и macOS
Краткий обзор SSH-клиентов для всех актуальных операционных систем. Посмотрим, чем они отличаются друг от друга, какие у новых клиентов преимущества и есть ли хорошие бесплатные варианты.
Что такое SSH?
SSH или Secure Shell (что в переводе значит «безопасная оболочка») — это сетевой протокол, используемый для подключения к удаленным компьютерам и управлениями ими с помощью технологии туннелирования.
Если у вас, к примеру, есть сервер в Timeweb под управлением Linux, то вы наверняка подключаетесь к нему через OpenSSH (серверная реализация Secure Shell с открытым исходным кодом). То есть вводите сначала команду в духе ssh root@192.168.60.55 и потом выполняете команды, связанные непосредственно с ОС. Подобные возможности дают технологии Telnet и rlogin, но они не особо прижились.
Ключевое преимущество SSH, в сравнении с конкурентами, заключается в повышенной безопасности. Этот протокол шифрует передаваемые команды и защищает соединение между администратором и сервером от третьих лиц.
А что такое SSH-клиент?
Это приложение на стороне клиента, которое используется для передачи команд на удаленный компьютер. В примере выше мы говорили о подключении к серверу через терминал в macOS и Linux. Чтобы провернуть подобное в Windows, нужна специальная программа. Например, PuTTY.
Зачастую SSH-клиенты выполняют те же задачи, что и терминал, но обладают расширенной функциональностью. У них схожие принципы работы, и все различия можно оценить только в специфичных сценариях использования Secure Shell.
Выбираем SSH-клиент
Мы уже выяснили, что обособленно пользователи получить какую-то пользу от протокола не могут. Для управления нужна дополнительная утилита. Вопрос в том, какая именно. Secure Shell настолько востребован, что разработчики создали уже несколько десятков SSH-клиентов под различные платформы. В этом материале рассмотрим лучшие из них, разработанные для Windows, macOS и Linux.
Некоторые из них кроссплатформенные (то есть работают сразу на нескольких ОС) или запускаются в браузерах (это тоже делает их универсальными).
SSH-клиенты для Windows
Начнем с популярнейшей платформы. Несмотря на на отсутствие встроенных инструментов и общую неадаптированность под разработку и работу с серверами, для Windows создали как минимум десяток функциональных и быстрых SSH-клиентов.
PuTTY
Самый известный SSH-клиент для Windows. Пожалуй, единственный, что на слуху у всех вебмастеров. PuTTY отличается от конкурентов логичным интерфейсом вкупе с богатым арсеналом возможностей, включая настройку прокси-серверов и сохранение параметров подключения.
PuTTY распространяется бесплатно и имеет открытый исходный код. При этом является одним из немногих SSH-клиентов, до сих пор активно развивающихся и получающих новые версии.
Утилита поддерживает протоколы SCP, SSH, rlogin и Telnet, а также работает со всеми методами шифрования данных.
Оригинальная программа доступна только для Windows, но есть порты от сообщества под другие платформы
KiTTY
За свою жизнь PuTTY обзавелся несколькими десятками форков (копий) от сторонних разработчиков. Каждый пытался внести в знаменитый SSH-клиент что-то свое. В итоге некоторые выросли в полноценные альтернативы, во много затмившие оригинал.
KiTTY базируется на PuTTY, но обладает массой преимуществ. Можно:
MobaXterm
Многофункциональный SSH-клиент, полюбившийся пользователям за высокую скорость работы, комфортный интерфейс и кучу дополнительных функций, отсутствующих у конкурентов. В нем есть браузер файлов, встроенный XServer для управления графическим интерфейсом на удаленном компьютере, масса плагинов, расширяющих возможности клиента, и portable-версия, работающая без установки.
Проект условно-бесплатный, поэтому большая часть функций недоступна до оплаты. Если не покупать платную версию, то функциональность MobaXterm будет мало чем отличаться от таковой в PuTTY. За профессиональную версию придется отдать 69 долларов.
Solar-PUTTY (бывший SolarWinds)
Один из немногих SSH-клиентов с современным интерфейсом. Это платная программа, что несомненно является ее недостатком. Но, в отличие от популярнейшего PuTTY, Solar умеет гораздо больше интересных вещей и лишен недостатков оригинала.
Приложение обойдется в 99 долларов (
SmarTTY
Еще одна попытка упростить жизнь веб-разработчикам, полагающимся на SSH. Создатели SmarTTY уделил много внимания ускорению работы пользователей и повышению удобства выполнения элементарных задач.
Например, появился режим отображения терминалов в отдельных вкладках. Сам терминал научился автоматически завершать команды и быстро искать файлы. В него добавили графический интерфейс для загрузки файлов на сервер без необходимости использовать командную строку.
Также в SmarTTY встроен многофункциональный текстовый редактор с возможностями Nano и hex-терминал для отслеживания COM-портов. А еще есть portable-версия, для работы с которой даже не нужно выполнять установку.
Xshell
Полнофункциональный SSH-клиент для Windows. Отличается от PuTTY и схожих продуктов возможностью задавать разные параметры для каждой терминальной сессии, создавать общие скрипты на несколько сессий.
Он поддерживает командную строку Windows и протокол SCP. Также в него встроен файловый менеджер для управления документами в графической среде.
Можно записывать выполняемые команды и превращать «записанный» материал в один скрипт, который после можно перезапустить в любой момент.
Tera Term
Популярный эмулятор терминалов для Windows с открытым исходным кодом. Может имитировать DEV VT100, DEC VT382 и другие модели. Написан на языках С и С++. Поддерживает технологии Telnet, SSH 1 и SSH 2.
Tera Term можно интегрировать с другими приложениями с помощью встроенного веб-сервера. В нем можно настроить повторяющиеся команды, поддерживающие терминал в рабочем состоянии, создавать скрипты на собственном языке Tera Term Language.
Из недостатков можно выделить устаревший дизайн и не совсем интуитивный интерфейс в сравнении с другими подобными приложениями.
Распространяется бесплатно, как и другие Open-Source-продукты.
SSH-клиенты для Linux
Пользователи Linux редко используют графические утилиты или какие-то усовершенствованные варианты SSH. Обычно все работают во встроенном терминале, но есть несколько неплохих решений для тех, кому нужно больше.
Terminal
В UNIX-подобных операционных системах есть встроенная поддержка OpenSSH. Можно использовать базовый терминал для подключения к удаленному серверу и управлению им. Интерфейс аналогичный тому, что вы можете встретить в большинстве SSH-клиентов. Только не придется скачивать сторонние программы и плагины.
Чтобы подключиться через терминал к серверу, надо ввести команду:
В моем случае это выглядит так:
После этого терминал запросит разрешение на установку соединения с удаленным сервером. Нужно согласиться, введя команду Yes и пароль администратора, чтобы авторизоваться и получить контроль над удаленным ПК.
Asbru Connection Manager (Linux)
Бесплатный интерфейс для удаленного подключения к серверу и автоматизации повторяющихся на нем задач. У Asbru простой механизм настройки соединения с VDS и есть свой язык для создания скриптов, как в SecureCRT.
Из дополнительных возможностей можно отметить функцию подключения к удаленному ПК через прокси-сервер, интеграцию с сервисом KeePassX, поддержку отдельных вкладок и окон под разные сессии, запущенные единовременно.
А еще он грамотно вписывается в интерфейс GTK и в окружение GNOME как визуально, так и в техническом плане.
Asbru можно запустить на Windows, используя компоненты Xming и включив WSL, но это весьма специфичный сценарий.
Бывший Snowflake. Графический клиент для подключения к серверу по протоколам SFTP и SSH. Включает в себя текстовый редактор, анализатор пространства на жестком диске, утилиту для считывания логов и прочие полезные инструменты.
Из прочих преимуществ отмечу:
Muon создавался с прицелом на веб-разработчиков, работающих над бэкэнд-составляющей сайтов.
SSH-клиенты для macOS
Компьютеры Apple поддерживает подключение по протоколу SSH прямо из встроенного терминала. Для этого используется та же команда, что и в Linux:
Также с последующем подтверждением подключения и авторизацией. Поэтому в macOS (как и в Linux) обычно не используются сторонние SSH-клиенты. Но они есть, и многие из них довольно качественные.
iTerm 2
Одна из главных альтернатив встроенному в macOS терминалу. Попытка расширить возможности стандартной командной строки необходимыми функциями, которые Apple упорно игнорирует годы напролет. Например, поддержку режима сплит-скрин, когда в одном окне отображается сразу два терминала с разными сессиями, или возможность добавлять комментарии к запущенным командам.
Отдельно отметим функцию Instant Playback. С помощью нее можно воспроизвести одну или несколько команд, которые были выполнены ранее, не вводя их заново. Ну а еще тут можно выделять, копировать и вставлять текст, не используя мышь (пользователи macOS поймут).
Shuttle
Технически это не полноценный SSH-клиент, как другие описываемые в статье. Это кнопка в панели инструментов, открывающая быстрый доступ к некоторым функциям для управления сервером. Прелесть утилиты заключается в ее универсальности и расширенных возможностях для ручной настройки.
Все параметры хранятся в файле
/.shuttle.json, который идет в комплекте с базовой утилитой. Туда можно прописать любой скрипт, используемый вами в терминале, а потом запускать его прямо с панели инструментов через компактный графический интерфейс Shuttle. Это может заметно ускорить выполнение кучи рутинных процедур.
Core Shell
SSH-клиент для macOS, поддерживающий работы сразу с несколькими хостами. Можно быстро между ними переключаться в одном окне с помощью вкладок или выделить каждый из них в отдельное окно. Каждому хосту назначается своя цветовая гамма. Чтобы было еще проще их разбивать по категориям, Core Shell поддерживает систему тегов.
Используя Core Shell, можно подключиться к VDS через прокси-сервер и выполнять переадресацию агента SSH.
Core Shell поддается скрупулезной настройке и «подгонке под себя». Причем клиент способен запоминать глобальные параметры для всех хостов и отдельные параметры для каждого из хостов. А еще в него интегрирована поддержка iCloud Keychain (хранилище паролей Apple).
Кроссплатформенные клиенты
Эмуляторы терминала, написанные на языках, поддерживающих сразу несколько операционных систем.
Hyper
Один из самых красивых терминалов в подборке. В отличие от других SSH-клиентов, этот не отличается какой-то специфичной функциональностью. Напротив, он практически полностью повторяет функциональность базовой командной строки. Поэтому пользователям он нравится не за обилие возможностей, а за простоту и симпатичный внешний облик.
По словам разработчиков, это попытка создать максимально быстрый и надежный терминал. Это был их приоритет при разработке. При этом он построен на базе фреймворка Electron, что делает его универсальным и расширяемым.
Если вы перфекционист и привыкли к изысканным интерфейсам macOS, то Hyper станет правильным выбором. Он здорово впишется в дизайн ОС Apple благодаря своим плавным линиям и приятными анимациям.
Доступен на Windows, macOS и Linux. Распространяется бесплатно.
Terminus
Терминал нового поколения (как его называют разработчики). Кроссплатформенный эмулятор терминала с поддержкой WSL, PowerShell, Cygwin, Clink, cmder, git-bash и десятка других технологий.
Есть полезные опции, такие как восстановление закрытых вкладок из предыдущей сессии и кликабельные пути к директориям.
Интерфейс Terminus можно настроить под себя с помощью разметки CSS. То же касается и функциональной составляющей. Ее можно «прокачать» за счет сторонних плагинов, число которых постепенно растет.
Доступен на Windows, macOS и Linux. Распространяется бесплатно.
Tectia
Продвинутый SSH-клиент, используемый крупнейшими банками мира, страховыми компаниями, технологическими корпорациями и государственными органами. Он обеспечивает безопасную передачу файлов за счет использования множества методов шифрования данных.
Tectia поддерживает стандарт аутентификации X.509 PKI, задействует сертифицированные криптографические методы FIPS 140-2 и может работать со смарткартами. Услугами Tectia пользуются такие внушительные структуры, как NASA и Армия США. Они доверяют Tectia, потому что это стабильный SSH-клиент с круглосуточной отзывчивой поддержкой. Как любой дорогой коммерческий продукт.
Доступен на Windows, Linux и других UNIX-подобных ОС. Обойдется в 133 доллара за клиент-версию и 650 долларов за сервер-версию.
Termius
Кроссплатформенный SSH-клиент с приложением-компаньоном для iOS и Android. Наличие мобильной версии — ключевое преимущество программы. С помощью нее можно на ходу вносить изменения на сервер, управлять базой данных и выполнять прочие действия, обычно требующие доступа к полноценному ПК.
Он адаптирован под сенсорные экраны и синхронизируется между всеми вашими устройствами, используя стандарт шифрования AES-256.
Доступен сразу на пяти платформах, включая мобильные. Распространяется по подписке за 9 долларов (
Poderosa
Профессиональный SSH-клиент, перешедший из стана opensource-проектов в разряд платных. Разработчики проекта видят своей задачей создание понятного интерфейса для управления серверами. Так, чтобы привыкшие вебмастера не путались, но обладали более широким набором инструментов.
Из функций создатели Poderosa выделяют удобный мультисессионный режим, когда экран делится на несколько частей и показывает сразу несколько терминалов. Можно также создать несколько вкладок, в каждый из которых будет по 4 терминала.
Есть ассистент, помогающий быстрее вводить часто используемые команды, и масса опций для изменения интерфейса (включая шрифты, цвета отдельных типов данных и т.п.).
SecureCRT
Коммерческий SSH-клиент с расширенным набором функций. Отличается от большинства конкурентов усиленными механизмами защиты данных. Поддерживает сразу несколько протоколов, включая SSH2 и Telnet. Эмулирует различные Linux-консоли и предлагает массу настроек внешнего вида.
Из отличительных функций можно отметить возможность создавать свои горячие клавиши, менять цвет отображаемого контента, искать по ключевым словам, запускать несколько окон с разными или одним сервером, открывать несколько сессий в разных вкладках. Также функциональность SecureCRT можно расширить за счет скриптов на языках VBScript, PerlScript и Python.
Доступен сразу на трех ОС. Распространяется по подписке за 99 долларов (
SSH-плагины для браузеров
Портативные SSH-клиенты, запускающиеся внутри браузеров и не требующие специфической ОС.
Chrome Secure Shell App
Google Chrome уже давно метит в полноценную платформу с функциональностью операционной системы. Поэтому разработчики из команды Google Secure Shell поспешили создать для него полнофункциональный эмулятор терминала.
С помощью Chrome Secure Shell App можно подключиться к серверу по протоколу SSH и выполнять стандартные команды, к которым вы привыкли, во встроенном терминале или в условном PuTTY. Разница отсутствует.
Получалась неплохая бесплатная альтернатива для тех, кто не хочет ставить сторонние приложения.
FireSSH
Еще один плагин, имитирующий терминал в браузере. Ранее он функционировал внутри Firefox, но компания Mozilla ограничила поддержку расширения. Поэтому сейчас FireSSH работает только в Waterfox. Это инди-форк от Firefox.
Он написан на JavaScript, распространяется бесплатно и помещает в браузерную среду все возможности стандартного SSH-клиента (на уровне терминала).
Выводы
Что касается выбора, то все зависит от личных предпочтений. Кому-то важна визуальная составляющая, кому-то функциональность, а кому-то хочется управлять сервером через SSH как можно проще. В любом случае можно попробовать все бесплатные варианты и принять решение уже после.