Меню Рубрики

Установка arch linux ssh

OpenSSH (Русский)

OpenSSH (OpenBSD Secure Shell) — набор программ, предоставляющих шифрование сеансов связи в компьютерных сетях по протоколу SSH (Secure Shell). OpenSSH разработан в рамках возглавляемого Тео де Раадтом (Theo de Raadt) проекта OpenBSD как открытая альтернатива проприетарному Secure Shell компании SSH Communications Security.

OpenSSH иногда путают с OpenSSL; они разрабатываются разными командами и имеют различное назначение. Определённая схожесть в названиях возникла из-за приверженности обоих проектов принципам открытого программного обеспечения (open software).

Contents

Установка

Клиент

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

Если на сервере разрешена аутентификация только по открытому ключу, см. Ключи SSH.

Настройка

Настройки клиента делятся на две категории: общие для всех исходящих соединений и относящиеся к соединениям только с определёнными хостами. Например:

С такими настройками следующие команды будут иметь одинаковый эффект:

Некоторые настройки не имеют флагов-аналогов для командной строки, но можно указать необходимые опции с помощью флага -o . Например, -oKexAlgorithms=+diffie-hellman-group1-sha1 .

Сервер

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

Настройка

Чтобы изменить настройки, нужно отредактировать/добавить нужные строки в файле настроек, например:

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

Предоставить доступ группам пользователей:

Параметр Banner позволяет настроить приветственное сообщение (например, сохранённое в файле /etc/issue ):

Пары открытых и закрытых ключей генерируются демоном sshd при первом запуске и сохраняются в каталог /etc/ssh . Создаётся четыре пары ключей на основе алгоритмов dsa, rsa, ecdsa и ed25519. Чтобы sshd использовал какой-то определённый ключ, укажите следующую опцию:

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

Демон

Запустите/включите службу sshd.service . Демон SSH будет работать в фоновом режиме и выполнять форк (fork) для каждого входящего соединения [1].

Безопасность

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

Следующие статьи и инструменты могут также быть полезными:

Отключение ненадёжных алгоритмов и шифров

The factual accuracy of this article or section is disputed.

Настройки по умолчанию позволяют использовать алгоритмы и шифры, которые на данный момент известны как ненадёжные. Это сделано для обеспечения обратной совместимости с legacy-клиентами. Если поддержка старых версий клиента в ваши планы не входит, то ненадёжные настройки лучше отключить. Ниже представлен пример файла настроек /etc/ssh/sshd_config .

Алгоритмы представлены в виде списка. При установлении соединения клиент сравнит свой список поддерживаемых методов шифрования с алгоритмами сервера и выберет первый подходящий. Списки составлены в порядке убывания надёжности в соответствии с рекомендациями разработчиков OpenSSH на момент выхода версии 8.1 в октябре 2019 года. Ненужные пункты в конце каждого списка при желании можно удалить.

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Вход только по открытому ключу

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

Двухфакторная аутентификация и открытые ключи

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

В статье Google Authenticator описана настройка Google Authenticator.

Для использования PAM с OpenSSH, отредактируйте следующий файл:

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

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

При входе по ключу и PAM аутентификацию по паролю можно отключить:

Защита от атак полным перебором

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

Используя ufw
Используя iptables

Если вы используете межсетевой экран iptables, то можно создать правила для защиты SSH от атаки перебором.

Создаём новую цепочку для обнаружения чрезмерного количества попыток входа и занесения их в лог:

Первое правило будет обрабатывать пакеты, которые указывают на создание нового соединения на порте 42660:

Затем iptables будет отслеживать пакеты, которые совпадают с предыдущим правилом либо пришли от хоста, уже находящегося в списке наблюдения:

Правило для TCP-трафика на порте 42660, не отфильтрованного предыдущим:

Присоединяем правило к таблице LOG_AND_DROP и используем оператор -j (jump) для передачи информации подсистеме логирования:

После занесения информации в логи пакеты будут уничтожены:

Утилиты для защиты

Автоматизированные программы вроде fail2ban или sshguard помогают защититься от атак перебором, блокируя попытки подобрать пароли.

  • Разрешайте входящие SSH-соединения только для доверенных адресов
  • Используйте fail2ban или sshguard для автоматической блокировки IP-адресов, которые провалили попытку аутентификации слишком много раз.
  • Используйте pam_shield для блокировки IP-адресов, которые выполняют слишком большое количество попыток входа за определённый период времени. В отличие от fail2ban и sshguard, pam_shield не различает успешными и неудачными попытками входа.

Ограничение входа от имени суперпользователя

This article or section is out of date.

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

Отключение

Утилита sudo выборочно предоставляет права суперпользователя для действий, которым они необходимы, без входа в учётную запись root. Благодаря этому можно заблокировать аккаунт root, чтобы отключить возможность входа в него через SSH. Это потенциально является средством защиты от атак перебором, поскольку атакующему придётся подбирать ещё и имя учётной записи в дополнение к паролю.

Чтобы отключить вход от имени суперпользователя через SSH, получите его права и отредактируйте секцию «Authentication» файла /etc/ssh/sshd_config . Просто измените значение #PermitRootLogin yes на no и раскомментируйте строку:

Теперь вы не сможете войти в систему через SSH от имени суперпользователя, но по-прежнему будете иметь возможность входить от имени обычного пользователя и использовать команды su и sudo для администрирования.

Ограничение

Некоторые автоматические задачи, вроде удалённого резервного копирования системы, требуют полного root-доступа. Чтобы иметь возможность безопасно его использовать, вместо отключения укажите конкретные команды. Для этого отредактируйте файл

root/.ssh/authorized_keys , создав префиксы для соответствующих ключей, например:

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

При этом остаётся возможность входа в систему с использованием имени суперпользователя. Это можно исправить, добавив следующую строку в файл sshd_config :

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

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

Защита файла authorized_keys

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

Задайте файлу authorized_keys права только на чтение для владельца и отключите остальные:

Чтобы не позволить пользователям вернуть разрешения, установите бит неизменяемости на файл authorized_keys . После этого пользователь может попытаться перемеименовать каталог

/.ssh и создать новый каталог с таким же именем и файлом authorized_keys . Чтобы не дать ему это сделать, установите бит неизменяемости и на каталог

Советы и рекомендации

Шифрованный туннель SOCKS

Эта возможность будет полезна для обладателей ноутбуков, которые часто подключаются к небезопасным беспроводным сетям в общественных местах. Для создания туннеля необходимо предварительно запустить сервер SSH в каком-нибудь безопасном месте, например, дома или на работе. Также будет весьма кстати какая-нибудь служба динамического DNS вроде DynDNS, которая избавит вас от необходимости запоминать IP-адрес.

Читайте также:  Установка витража из пластика

Шаг 1: установить соединение

Для установления соединения необходимо лишь выполнить команду:

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

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

Шаг 2 (вариант А): настроить браузер (или другие программы)

Чтобы установленное соединение (см. выше) было хоть как-то полезно, нужно настроить браузер и другие программы на использование туннеля SOCKS. В настоящее время SSH поддерживает как SOCKSv4, так и SOCKSv5, вы можете выбрать любой из них.

  • Для Firefox: Preferences > General > Settings. . В открывшемся окне выберите пункт Manual proxy configuration, введите localhost в поле SOCKS host и номер порта в поле Port ( 4711 для примера выше).

DNS-запросы Firefox автоматически посылаться через туннель не будут, что представляет собой некоторую уязвимость с точки зрения приватности. Чтобы это исправить, также выберите пункт Proxy DNS when using SOCKS v5. Очевидно, что это будет работать, только если вы выбрали пятую версию протокола SOCKS, а не четвёртую. Перезапустите Firefox, чтобы настройки заработали.

  • Для Chromium: SOCKS можно настроить через переменные окружения или опции командной строки. Например, выберите одну из следующих функций и добавьте её в файл .bashrc :

Теперь откройте терминал, выполните

и наслаждайтесь защищённым туннелем!

Шаг 2 (вариант Б): настроить TUN-интерфейс

Этот вариант выглядит несколько более запутанным по сравнению с предыдущим, но зато вам не придётся настраивать работу через SOCKS-прокси для каждого приложения по отдельности. Данное решение подразумевает настройку локального TUN-интерфейса и перенаправление всего трафика на него.

Проброс X11

Проброс Х11 — механизм, который позволяет графическим интерфейсам программ удаленной машины-сервера отображаться на локальной машине-клиенте. При этом нет необходимости устанавливать на удаленном узле всю систему Х11, но надо установить хотя бы xauth. xauth — утилита, которая поддерживает конфигурации Xauthority , используемые сервером и клиентом для аутентификации сессии X11 [4].

Настройка

  • Установите пакеты xorg-xauth и xorg-xhost ;
  • В файле /etc/ssh/sshd_config :
    • Задайте для опции X11Forwarding значение yes ;
    • Убедитесь, что заданы значения AllowTcpForwarding yes , X11UseLocalhost yes и X11DisplayOffset 10 (значения по умолчанию, если ничего не менялось, см. sshd_config(5) );
  • Перезапустите#Демонsshd.
  • Установите пакет xorg-xauth ;
  • включите опцию ForwardX11 либо добавив флаг -X в командной строке, либо задав в файле настроек клиента параметр ForwardX11 yes .

Использование

The factual accuracy of this article or section is disputed.

Выполните удалённый вход как обычно, добавив флаг -X , если опция ForwardX11 не включена в конфигурационном файле клиента:

Если вы получаете ошибки при запуске графических приложений, попробуйте опцию ForwardX11Trusted:

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

Если вы получите ошибки «Cannot open display», попробуйте выполнить следующую команду от имени обычного пользователя:

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

где имя-хоста — это имя конкретного хоста. Подробнее см. xhost(1) .

Будьте осторожны с некоторыми приложениями, так как они могут проверять локальную машину на предмет уже работающего приложения. Один из примеров — Firefox: либо закройте работающий Firefox, либо используйте следующий параметр запуска:

Если вы получите ошибку X11 forwarding request failed on channel 0 при подключении (и лог-файл сервера /var/log/errors.log будет содержать строку Failed to allocate internet-domain X11 display socket ), удостоверьтесь, что пакет xorg-xauth установлен. Если его установка не поможет, попробуйте сделать одно из двух:

  • Включить опцию AddressFamily any в файле sshd_config на сервере;
  • Задать опции AddressFamily в sshd_config на сервере значение inet. Присвоение значения inet может исправить проблемы с клиентами Ubuntu при использовании IPv4.

Для запуска приложений X от имени других пользователей на сервере SSH вам необходимо добавить (команда xauth add ) строку аутентификации, взятую из вывода команды xauth list пользователя, вошедшего в систему.

Проброс других портов

В дополнение к встроенной поддержке SSH X11 также можно установить безопасный туннель для любого соединения TCP с использованием локального или удаленного проброса.

Локальный проброс открывает на локальной машине порт, подключения к которому будут перенаправлены на удаленный хост, а оттуда — по заданному направлению. Очень часто этим направлением будет сам удаленный хост, предоставляющий secure shell и, например, безопасное соединение VNC для этой же машины. Локальный проброс осуществляется при помощи ключа -L и задания спецификации проброса в следующей форме: : : .

будет использовать SSH для входа в систему и открытия шелла на 192.168.0.100 , а также создаст туннель от порта 1000 локальной машины на порт 25 mail.google.com. В результате подключения к localhost:1000 будут перенаправлены на порт Gmail SMTP. Для Google всё будет выглядеть так, будто соединение (но вовсе не обязательно — передаваемые по нему данные) исходит от 192.168.0.100 ; данные будут в безопасности между локальной машиной и 192.168.0.100 , но не между 192.168.0.100 и Google, если не предпринять дополнительных мер.

будет принимать подключения к localhost:2000 , которые будут перенаправлены на порт 6001 удаленного хоста. Этот пример хорош для VNC-соединений с помощью утилиты vncserver. Утилита входит в пакет TigerVNC, и, несмотря на очевидную полезность, имеет некоторые проблемы с безопасностью.

Удаленный проброс позволяет удаленному хосту подключаться к произвольному хосту через туннель SSH и локальную машину, предоставляя функционал, обратный локальному пробросу. Это полезно в ситуациях, когда, например, удаленный хост ограничен фаерволлом. Он включается ключом -R и заданием спецификаций проброса в следующей форме: : : .

поднимет шелл на 192.168.0.200 , и соединения из 192.168.0.200 к своему же порту 3000 (т.е. localhost:3000 удалённого хоста) будут посланы через туннель на локальную машину, а затем на irc.freenode.net, порт 6667, что в данном примере позволит использовать программы IRC на удаленном хосте, даже если обычно порт 6667 будет для них заблокирован.

Оба вида проброса могут быть использованы для предоставления безопасного «шлюза», позволяющего другим компьютерам получить преимущества туннеля SSH без непосредственно работающего SSH или демона SSH, при использовании bind-адреса в начале туннеля как части спецификации проброса, например, : : : . может быть любым адресом на машине, localhost , * (или blank), который, соответственно, пропускает соединения через заданный адрес, интерфейс loopback или любой интерфейс. По умолчанию проброс ограничен соединениями от машины в начале туннеля, установлен в localhost . Локальный проброс не требует дополнительной настройки, в то время как удаленный проброс ограничен конфигурацией демона SSH удаленного сервера. Смотрите описание опции GatewayPorts на справочной странице sshd_config(5) и опции -L address в руководстве ssh(1) для получения дополнительной информации.

Jump-хост

Может случиться так, что у вас не будет возможности установить связь с удалённой машиной напрямую. В этом случае используется jump-сервер или узел-бастион. Следовательно, необходимо соединить два или более SSH-туннеля в цепочку. Разумеется, ваши ключи должны позволять выполнить авторизацию на каждом из серверов в цепи. Для этого SSH запускается с опциями пересылки аутентификационных данных ( -A ) и выделения псевдотерминала ( -t ):

Несколько проще то же самое можно сделать с флагом -J :

Промежуточные хосты в директиве -J разделяются запятыми и располагаются в порядке установления соединения. Часть пользователь. @ необязательна. При работе с опцией -J используется стандартный файл настроек SSH, поэтому при необходимости в нём можно указать настройки соединения для каждого хоста в отдельности.

Опция ProxyJump в файле настроек эквивалентyна флагу командной строки -J , см. ssh_config(5) .

Обратный SSH через промежуточный узел

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Идея заключается в том, чтобы подключиться к серверу через промежуточный узел, причём сервер соединяется с этим узлом через обратный SSH-туннель. Например, это может быть полезно, когда сервер находится за NAT, а промежуточный узел представляет собой публичный SSH-сервер, используемый в качестве прокси. При этом:

  • у клиента должны быть ключи для авторизации и на промежуточном узле, и на целевом сервере;
  • у сервера должны быть ключи дла авторизации на промежуточном узле.
Читайте также:  Установки для концентрирования извлечений

Ниже приведён пример настройки соединения через промежуточный узел. Предполагается, что пользователь1 — аккаунт на клиентской машине, пользователь2 — на промежуточном узле и пользователь3 — на сервере. Сначала необходимо создать обратный туннель:

Это действие можно автоматизировать с помощью скрипта, службы systemd или autossh.

This article or section needs expansion.

Соединение со стороны клиента устанавливается командой:

Удалённую команду для создания соединения с обратным туннелем можно добавить в файл

/.ssh/authorized_keys на промежуточном узле. Для этого воспользуйтесь полем command :

Тогда установить соединение можно командой:

Обратите внимание, что функция автодополнения SCP в терминале клиента работать не будет, а на некоторых конфигурациях не будет работать и сама передача данных по протоколу SCP.

Мультиплексирование

Демон SSH обычно прослушивает порт 22. Однако трафик, который адресован не на стандартные порты HTTP/S (80 и 443 соответственно), на публичных серверах часто блокируется. Следовательно, в таком случае SSH-соединение невозможно. В качестве возможного решения можно указать демону sshd прослушивать один из портов в белом списке:

Поскольку порт 443 уже прослушивается веб-сервером в ожидании HTTPS-пакетов, в данном случае имеет смысл воспользоваться мультиплексором вроде sslh . Он будет прослушивать мультиплексированный порт и переадресовывать пакеты разным сервисам в зависимости от их назначения.

Увеличение скорости SSH

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

    Используйте быстрый алгоритм шифрования: в современных процессорах с инструкциями AESNI алгоритмы aes128-gcm@openssh.com и aes256-gcm@openssh.com гораздо более производительны, чем стандартный алгоритм OpenSSH, chacha20-poly1305@openssh.com . Выбрать алгоритм можно флагом -c . Чтобы сделать изменения постоянными, добавьте пункт Ciphers в файл

/.ssh/config , перечислив алгоритмы в порядке уменьшения предпочтительности, например:

  • Включите или выключите сжатие: сжатие может увеличить скорость для медленных соединений, оно включается параметром Compression yes или флагом -C . Однако в качестве алгоритма сжатия используется относительно медленный gzip(1) , который в быстрых сетях становится узким местом. Поэтому в локальных и быстрых сетях лучше отключить сжатие параметром Compression no .
  • Объединение соединений: в случае нескольких одновременных сессий к одному хосту можно объединить их в одно соединение:

где вместо

/.ssh/sockets можно использовать любой каталог без прав на запись для остальных пользователей.

  • Параметр ControlPersist позволяет задать время ожидания после момента разрыва исходного соединения. Возможны следующие значения:
    • no — соединение разрывается сразу же после отключения предыдущего клиента;
    • время ожидания в секундах;
    • yes — бесконечное ожидание, соединение автоматически разрываться не будет.
  • Время входа можно сократить, если пропустить поиск заголовков IPv6. Для этого используйте опции AddressFamily inet или флаг -4 .
  • Наконец, если вы собираетесь использовать SSH для SFTP или SCP, High Performance SSH/SCP поможет значительно увеличить пропускную способность с помощью динамического изменения размера буфера SSH. Установите пакет openssh-hpn-gitAUR , чтобы использовать OpenSSH с этим расширением.

Монтирование удалённых файловых систем при помощи SSHFS

В статье SSHFS описано, как использовать SSH для монтирования удалённых файловых систем в локальный каталог, чтобы иметь возможность выполнять любые операции над смонтированными файлами (копирование, переименование, редактирование в vim и т.д.). Предпочтительнее использовать sshfs, а не shfs, поскольку последний не обновлялся с 2004 года.

Поддержание подключения

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

  • На сервере параметр ClientAliveInterval задаёт время ожидания в секундах, по истечении которого при отсутствии данных от клиента sshd пошлёт последнему запрос. Значение по умолчанию — 0, «не посылать сообщений». Например, чтобы запрашивать ответ от клиента каждые 60 секунд, задайте параметр ClientAliveInterval 60 в настройках сервера. Также обратите внимание на параметры ClientAliveCountMax и TCPKeepAlive .
  • На клиенте параметр ServerAliveInterval задаёт временной промежуток между запросами на сервер. Например, чтобы посылать запросы каждые 120 секунд, задайте параметр ServerAliveInterval 120 в настройках клиента. Также обратите внимание на параметры ServerAliveCountMax и TCPKeepAlive .

Автоматический перезапуск туннелей SSH с помощью systemd

systemd может автоматически создавать SSH-соединения при загрузке/входе в систему, а также перезапускать их при внезапном разрыве соединения.

Ниже представлен пример службы, которая будет создавать SSH-туннель в соответствии с настройками SSH. Если соединение было по какой-то причине разорвано, служба подождёт 10 секунд и перезапустит его:

запустите/включите пользовательскую службу systemd. В разделе #Поддержание подключения описано, как предотвратить разрыв соединения из-за превышения времени ожидания. Если вы захотите запускать туннель при загрузке системы, то придётся переписать юнит, чтобы сделать его системным.

Autossh — автоматический перезапуск сессий и туннелей SSH

Если сессия или туннель не может поддерживаться в активном состоянии, например, из-за плохого подключения к сети и связанных с ним отключений, используйте autossh для автоматического перезапуска.

Подключение через SOCKS-прокси, сконфигурированный при помощи настроек proxy:

При помощи опции -f autossh может быть запущен в качестве фонового процесса. Однако, в этом случае вы не сможете вводить пароль в интерактивном режиме.

Сессия будет завершена, как только вы введете команду exit , иначе процесс autossh получит сигнал SIGTERM, SIGINT или SIGKILL.

Автозапуск Autossh при загрузке системы при помощи systemd

Если вы хотите, чтобы autossh запускался автоматически, вы можете использовать systemd. Например, вы можете создать файл юнита, подобный этому:

Здесь AUTOSSH_GATETIME=0 — это переменная окружения, указывающая, как долго ssh должен быть поднят, прежде чем autossh утвердит успешное подключение. Установка значения 0 укажет autossh игнорировать неудачное подключение ssh. Это может быть полезно при добавлении autossh в автозагрузку. Другие переменные окружения доступны на справочной странице autossh(1) . Конечно, вы можете сделать этот юнит более комплексным, если вам это необходимо (для получения дополнительных подробностей смотрите документацию systemd); очевидно, вы можете использовать ваши собственные опции для autossh, но учтите, что флаг -f , подразумевающий AUTOSSH_GATETIME=0 , не работает с systemd.

Не забудьте запустить и/или включить службу.

Мы также можете отключить ControlMaster, например:

Альтернатива на случай невозможности запустить демон SSH

Для удалённых или headless-серверов, которые полагаются исключительно на SSH, сбой запуска демона SSH (например, после обновления системы) может означать невозможность осуществлять администрирование. Systemd в этом случае может помочь, если воспользоваться опцией OnFailure .

Предположим, что на сервере работает sshd , а качестве запасного варианта выбран telnet. Создайте файл, который показан ниже. Включать telnet.socket не надо!

Это всё. Telnet не будет работать, если запущен sshd . Если же sshd не запустится, то можно будет создать сеанс telnet для устранения неисправностей.

Настройка цвета фона терминала для удалённого хоста

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

К сожалению, это работает не для всех терминалов (только для Zsh).

Настройка для работы в конкретной сети

С помощью параметра Match exec можно создавать настройки хостов для работы в конктретных сетях.

Например, если используется nmcli и соединение настроено (вручную или с помощью DHCP) на использование search-domain:

Проверка ключей хостов в локальных сетях

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

The factual accuracy of this article or section is disputed.

Лучшим решением будет воспользоваться рекомендациями из раздела #Настройка для работы в конкретной сети и использовать разные параметры UserKnownHostsFile для разных сетей. Второй способ лучше использовать, если вы работаете в новых или экспериментальных сетях — просто игнорируйте ключи хостов (hostkeys) для приватных сетей:

The factual accuracy of this article or section is disputed.

Выполнение команд во время входа

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

  • отредактируйте файл authorized_keys на удалённом хосте (см. sshd(8) );
  • отредактируйте файл

/.ssh/rc на удалённом хосте, если сервер работает с включённой опцией PermitUserRC ;

  • отредактируйте файл настроек командной оболочки, например, .bashrc .
  • Решение проблем

    Проверка

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

    /.ssh и его содержимое должно быть доступно только пользователю (проверьте и клиент, и сервер), а также права на запись в домашнем каталоге должны быть только у пользователя:
    Убедитесь, что открытый ключ клиента (например, id_rsa.pub ) указан в файле

    /.ssh/authorized_keys на сервере;

  • Убедитесь, что вы не ограничили доступ через SSH параметрами AllowUsers и AllowGroups в настройках сервера;
  • Проверьте, установил ли пользователь пароль. Иногда новые пользователи не устанавливают пароль до первого входа в систему;
  • Добавьте параметр LogLevel DEBUG в файл /etc/ssh/sshd_config ;
  • Изучите вывод команды journalctl -xe на предмет сообщений об ошибках;
  • Перезапустите демон sshd и выполните выход/вход на клиенте и сервере.
  • Подключение отклонено или проблема тайм-аута

    Проброс портов

    Если ваша машина находится за NAT или маршрутизатором (скорее всего так и есть, если речь не идёт о VPS или хосте с публичным IP-адресом), убедитесь, что маршрутизатор пробрасывает входящие SSH-соединения на неё. Узнайте внутренний IP-адрес сервера командой ip addr и настройте маршрутизатор пробрасывать TCP на SSH-порт этого адреса. Подробности смотри на https://portforward.com/.

    SSH запущен и прослушивает?

    Утилита ss покажет все процессы, прослушивающие TCP-порты:

    Если в выводе окажется, что система не прослушивает порт ssh , то SSH не запущен: проверьте файл /var/log/messages на предмет сообщений об ошибках.

    Имеются ли правила фаервола, блокирующие соединения?

    Iptables может блокировать подключения к порту 22 . Проверьте это следующей командой:

    Просмотрите вывод на предмет правил, которые могут блокировать нужные вам пакеты (цепочка INPUT ). Затем, если необходимо, разблокируйте порт командой вида:

    Информацию по настройке межсетевых экранов можно найти в разделе Файрвол.

    Трафик доходит до вашего компьютера?

    Запустите дамп трафика на компьютере, с которым возникли проблемы:

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

    Ваш провайдер или кто-то еще блокирует нужный порт?

    В некоторых случаях провайдер может блокировать порт по умолчанию (SSH порт 22). Чтобы это проверить, создайте сервер на всех интерфейсах (0.0.0.0) и подключитесь удаленно.

    Если вы получите сообщение об ошибке вроде этого:

    это означает, что порт не был заблокирован провайдером: просто на сервере не запущен SSH для этого порта (смотрите статью Безопасность через неясность).

    Однако, если вы получите сообщение об ошибке вроде этого:

    это означает, что что-то отклоняет ваш трафик TCP, предназначенный для порта 22. Как правило, этот порт скрыт либо вашим фаерволлом, либо третьей стороной (например, провайдером, блокирующим и/или отклоняющим входящий трафик на порт 22). Если вы знаете, что фаерволл на вашем компьютере не запущен и Гремлины не размножаются на ваших роутерах и свитчах, это означает, что провайдер блокирует трафик.

    Чтобы убедиться в этом, вы можете запустить Wireshark на сервере и «прослушать» трафик, предназначенный для порта 22. Поскольку Wireshark является утилитой анализа трафика на уровне 2 , а TCP/UDP используют уровень 3 и выше (смотрите статью TCP/IP), если вы ничего не получаете при создании удаленного подключения, вероятнее всего, что третья сторона блокирует трафик для этого порта на вашем сервере.

    Диагностика

    где интерфейс — сетевой интерфейс для соединения WAN (для проверки выполните ip a ). Если вы не получаете никаких пакетов при попытке удаленного подключения, можете быть уверены, что ваш провайдер блокирует входящий на порт 22 трафик.

    Возможное решение

    Вы можете просто использовать другой порт, который провайдером не блокируется. Откройте файл /etc/ssh/sshd_config и укажите другой порт. Например, добавьте:

    Также удостоверьтесь, что другие строки «Port» закомментированы. Если просто закомментировать строку «Port 22» и прописать «Port 1234», проблема не будет решена, поскольку sshd будет прослушивать лишь порт 1234. Используйте обе строки для запуска сервера SSH на обоих портах.

    Перезапустите сервер sshd.service . Готово! Теперь вам необходимо настроить ваш(и) клиент(ы) на использование другого порта.

    Read from socket failed: connection reset by peer

    Последние версии openssh иногда выдают подобное сообщение при попытке подключения к старым SSH-серверам. Это можно обойти с помощью различных параметров клиента (подробнее см. ssh_config(5) ).

    Причиной проблемы может быть алгоритм эллиптических кривых ecdsa-sha2-nistp*-cert-v01@openssh . Его можно отключить, удалив название алгоритма из списка HostKeyAlgorithms .

    Если это не помогло, возможно, список алгоритмов слишком длинен. Укажите в параметре Ciphers менее длинный список (короче 80 символов). Аналогично можно попробовать сократить список MACs .

    Также стоит изучить обсуждение на форуме openssh.

    «[ваша командная оболочка]: No such file or directory» / ssh_exchange_identification problem

    Одна из возможных причин — необходимость найти абсолютный путь (который возвращает команда whereis -b [ваша командная оболочка] , например) в $SHELL , даже если бинарный пакет вашего интерпретатора находится в одной из записей $PATH .

    Ошибки «Terminal unknown» и «Error opening terminal»

    Если вы получаете одну из таких ошибок во время входа, это значит, что сервер не может распознать ваш терминал. Приложения ncurses вроде nano могут не запуститься, выдав сообщение «Error opening terminal».

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

    Если установить файл нормально не удаётся, скопируйте его в домашний каталог на сервере:

    После выхода и отключения от сервера проблема должна решиться.

    Хак $TERM

    Можно задать переменную окружения сервера TERM=xterm (например, в файле .bash_profile ). Это заглушит сообщения об ошибках и позволит запуститься приложениям ncurses, но результатом может стать странное поведение и графические баги — кроме случая, если контрольные последовательности вашего терминала совпадают с таковыми у xterm.

    Ошибка Connection closed by x.x.x.x [preauth]

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

    id_dsa не используется в OpenSSH 7.0

    OpenSSH 7.0 прекратил использование открытых ключей DSA из соображений безопасности. Если вам очень нужно именно эти ключи, воспольуйтесь опцией PubkeyAcceptedKeyTypes +ssh-dss (на странице http://www.openssh.com/legacy.html она не упомянута).

    Не удаётся подобрать способ обмена ключами в OpenSSH 7.0

    OpenSSH 7.0 прекратил использование алгоритма diffie-hellman-group1-sha1, поскольку он ненадёжный и теоретически может быть взломан т.н. атакой Logjam (см. http://www.openssh.com/legacy.html). Если этот алгоритм будет нужен какому-то хосту, ssh выдаст соощение об ошибке следующего содержания:

    Лучшим решением будет обновить сервер и отключить использование устаревших алгоритмов. Если это сделать невозможно, вы можете заставить клиент включить алгоритм параметром KexAlgorithms +diffie-hellman-group1-sha1 .

    Сеанс tmux/screen прерывается при разрыве соединения SSH

    Если ваши процессы прерываются при завершении сеанса SSH, возможно, что вы используете активацию сокета и systemd принудительно её убивает. В этом случае есть два решения. Первый — не использовать активацию сокета и заменить ssh.socket на ssh.service . Второй — задать параметр KillMode=process в разделе Service файла ssh@.service .

    Параметр KillMode=process может также быть полезен при работе с классическим ssh.service , т.к. он не позволяет убить процесс сессии SSH или процессы screen и tmux при остановке или перезагрузке сервера.

    Сеанс SSH не отвечает

    SSH реагирует на команды управления XON и XOFF . Он остановится, если вы случайно нажали Ctrl+s . Нажмите Ctrl+q , чтобы продолжить сеанс.

    Broken pipe

    Если вы пытаетесь установить соединение и получаете ответ Broken pipe на packet_write_wait , попробуйте подключиться в режиме отладки. Посмотрите, если ли в выводе сообщений об ошибках:

    Строчка send packet указывает на то, что ответный пакет получен не был. Следовательно, проблема заключается в QoS. Чтобы уменьшить потерю пакетов, задайте значение параметра IPQoS :

    Значение reliability ( 0x04 ) должно решить проблему. Также можно задать значения 0x00 и throughput ( 0x08 ).

    Демон медленно запускается после перезагрузки

    Если демон запускается необычно долго после перезагрузки (несколько минут), особенно для headless- и виртуализированных серверов, это может быть связано с нехваткой энтропии [9]. Для решения этой проблемы установите Rng-tools или Haveged. Однако обратите внимание на вопросы безопасности, которые обсуждаются в посвящённых этим утилитам статьях.

    источник

    Добавить комментарий