Поиск по сайту:

Как настроить пользовательские параметры подключения для вашего SSH-клиента

Введение

SSH или Secure Shell — наиболее распространенный способ подключения к серверам Linux для удаленного администрирования. Хотя подключение к одному серверу через командную строку относительно простое, существует множество оптимизаций рабочего процесса для подключения к нескольким удаленным системам.

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

В этом руководстве мы рассмотрим структуру файла конфигурации клиента SSH и рассмотрим некоторые общие параметры.

Предпосылки

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

Структура файла конфигурации SSH и алгоритм интерпретации

Каждый пользователь в вашей системе может поддерживать свой собственный файл конфигурации SSH в своем домашнем каталоге. Они могут содержать любые параметры, которые вы использовали бы в командной строке для указания параметров подключения. Всегда можно переопределить значения, определенные в файле конфигурации во время соединения, добавив дополнительные флаги в команду ssh.

Расположение файла конфигурации клиента SSH

Файл конфигурации на стороне клиента находится в ~/.ssh/config — ~ — это универсальный ярлык для вашего домашнего каталога. Часто этот файл не создается по умолчанию, поэтому вам может потребоваться создать его самостоятельно. Команда touch создаст его, если он не существует (и обновит отметку времени последнего изменения, если он существует).

  1. touch ~/.ssh/config

Структура файла конфигурации

Файл config организован по хостам, т. е. по удаленным серверам. Каждое определение хоста может определять параметры подключения для конкретного соответствующего хоста. Подстановочные знаки также поддерживаются для параметров, которые должны иметь более широкую область действия.

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

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

Общий формат будет выглядеть примерно так:

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

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

Алгоритм интерпретации

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

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

Например, рассмотрим это определение:

Host devel
    HostName devel.example.com
    User tom

Этот хост позволяет нам подключиться как tom@devel.example.com, введя это в командной строке:

  1. ssh devel

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

Затем SSH перемещается вниз по файлу, проверяя, совпадают ли другие определения Host. Если будет найдено другое определение, соответствующее текущему имени хоста, указанному в командной строке, будут учтены параметры SSH, связанные с новым разделом. Затем он применит любые параметры SSH, определенные для нового раздела, которые еще не были определены в предыдущих разделах.

Это важный момент. SSH будет интерпретировать каждый из разделов Host, которые соответствуют имени хоста, указанному в командной строке, по порядку. Во время этого процесса всегда будет использоваться первое значение, заданное для каждой опции. Невозможно переопределить значение, которое уже было задано ранее сопоставленным разделом.

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

Давайте еще раз посмотрим на пример из предыдущего раздела:

Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

Здесь мы видим, что первые два раздела определяются буквальными именами хостов (или псевдонимами), что означает, что они не используют никаких подстановочных знаков. Если мы подключимся с помощью ssh firsthost, самый первый раздел будет применен первым. Это установит Hostname, User и IdentityFile для этого соединения.

Он проверит второй раздел и обнаружит, что он не совпадает, и пойдет дальше. Затем он найдет третий раздел и обнаружит, что он соответствует. Он проверит ANOTHER_OPTION, чтобы увидеть, есть ли уже значение для этого из предыдущих разделов. Обнаружив, что это не так, он применит значение из этого раздела. Затем он будет соответствовать последнему разделу, поскольку определение Host * соответствует каждому соединению. Поскольку у него нет значения для фиктивного параметра CHANGE_DEFAULT из других разделов, он возьмет значение из этого раздела. Затем устанавливается соединение с параметрами, собранными в этом процессе.

Давайте попробуем еще раз, притворившись, что вызываем ssh secondhost из командной строки.

Опять же, он начнет с первого раздела и проверит, соответствует ли он. Поскольку это соответствует только подключению к firsthost, этот раздел будет пропущен. Он перейдет ко второму разделу. Обнаружив, что этот раздел соответствует запросу, он соберет значение ANOTHER_OPTION для этого подключения.

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

Затем SSH проверяет четвертый раздел и применяет параметры внутри, которые не были определены ранее согласованными разделами. Затем он пытается установить соединение, используя собранные значения.

Варианты подключения

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

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

Чтобы подключиться как пользователь с именем apollo к хосту с именем example.com, на котором запущен демон SSH на порту 4567 из командной строки, вы можете запустите ssh следующим образом:

ssh -p 4567 apollo@example.com

Однако вы также можете использовать полные имена опций с флагом -o, например:

ssh -o "User=apollo" -o "Port=4567" -o "HostName=example.com"

Вы можете найти полный список доступных параметров на странице руководства SSH.

Чтобы установить их в файле config, вам нужно выбрать имя заголовка Host, например home:

Host home
    HostName example.com
    User apollo
    Port 4567

Общие параметры конфигурации SSH

До сих пор мы обсуждали некоторые параметры, необходимые для установления соединения. Мы рассмотрели эти варианты:

  • HostName: Фактическое имя хоста, которое следует использовать для установления соединения. Это заменяет любой псевдоним, определенный в заголовке Host. В этом параметре нет необходимости, если в определении Host указан действительный адрес для подключения.
  • Пользователь: имя пользователя, которое будет использоваться для подключения.
  • Порт: порт, на котором запущен удаленный демон SSH. Этот параметр необходим только в том случае, если удаленный экземпляр SSH не работает на порту по умолчанию 22.

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

Общие настройки и элементы подключения

  • ServerAliveInterval: этот параметр можно настроить, чтобы сообщить SSH, когда отправлять пакет для проверки ответа от сервера. Это может быть полезно, если ваше соединение ненадежно и вы хотите знать, доступно ли оно.
  • LogLevel: настраивает уровень детализации, с которым SSH будет регистрироваться на стороне клиента. Это можно использовать для отключения ведения журнала в определенных ситуациях или увеличения детализации при попытке отладки. Уровни от наименее до наиболее подробных: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG1, DEBUG2 и DEBUG3.
  • StrictHostKeyChecking: этот параметр определяет, будет ли ssh SSH автоматически добавлять хосты в файл ~/.ssh/known_hosts. По умолчанию для этого будет установлено значение \спрашивать, что означает, что он предупредит вас, если ключ хоста, полученный с удаленного сервера, не совпадает с ключом, найденным в файле known_hosts. Если вы постоянно подключаетесь для большого количества временных хостов (таких как тестовые серверы), вы можете изменить это значение на «нет». Затем SSH автоматически добавит все хосты в файл. Это может иметь последствия для безопасности, если ваши известные хосты когда-либо изменят адреса, когда они не должны, поэтому хорошо подумайте, прежде чем включать его.
  • UserKnownHostsFile: этот параметр указывает место, где SSH будет хранить информацию о хостах, к которым он подключен. Обычно вам не нужно беспокоиться об этом параметре, но вы можете установить для него значение /dev/null, чтобы они отбрасывались, если вы отключили строгую проверку хоста выше.
  • VisualHostKey: этот параметр может указать SSH отображать ASCII-представление ключа удаленного хоста при подключении. Включение этого может быть полезным способом ознакомиться с ключом вашего хоста, что позволит вам распознать его, если вам когда-нибудь в будущем придется подключаться с другого компьютера.
  • Сжатие: включение сжатия может быть полезно для очень медленных соединений. Большинству пользователей это не понадобится.

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

Например, если мы очень быстро создаем и уничтожаем хосты у облачного провайдера, может быть полезно что-то вроде этого:

Host home
    VisualHostKey yes

Host cloud*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel QUIET

Host *
    StrictHostKeyChecking ask
    UserKnownHostsFile ~/.ssh/known_hosts
    LogLevel INFO
    ServerAliveInterval 120

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

Переадресация соединения

Одним из распространенных способов использования SSH является переадресация соединений, либо позволяющая локальному соединению туннелироваться через удаленный хост, либо разрешающая удаленному компьютеру доступ к туннелю через локальный компьютер. Иногда это необходимо, когда вам нужно подключиться к удаленному компьютеру за брандмауэром через отдельный, назначенный сервер «шлюза». SSH также может выполнять динамическую пересылку с использованием таких протоколов, как SOCKS5, которые включают информацию о пересылке для удаленного хоста.

Опции, управляющие этим поведением:

  • LocalForward: этот параметр используется для указания соединения, которое будет перенаправлять трафик локального порта на удаленный компьютер, туннелируя его в удаленную сеть. Первым аргументом должен быть локальный порт, на который вы хотите направить трафик, а вторым аргументом должен быть адрес и порт, на которые вы хотите направить этот трафик на удаленном конце.
  • RemoteForward: этот параметр используется для определения удаленного порта, на который может быть направлен трафик для туннелирования с локального компьютера. Первым аргументом должен быть удаленный порт, через который будет направляться трафик на удаленную систему. Вторым аргументом должен быть адрес и порт, на которые должен направляться трафик, когда он поступает в локальную систему.
  • DynamicForward: используется для настройки локального порта, который можно использовать с протоколом динамической пересылки, таким как SOCKS5. Затем трафик, использующий протокол динамической пересылки, может быть направлен на этот порт на локальном компьютере, а на удаленном конце он будет маршрутизироваться в соответствии с включенными значениями.

Эти параметры можно использовать для переадресации портов в обоих направлениях, как вы можете видеть здесь:

# This will allow us to use port 8080 on the local machine
# in order to access example.com at port 80 from the remote machine
Host local_to_remote
    LocalForward 8080 example.com:80

# This will allow us to offer access to internal.com at port 443
# to the remote machine through port 7777 on the other side
Host remote_to_local
    RemoteForward 7777 internal.com:443

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

Другое переадресация

Наряду с переадресацией соединения SSH допускает и другие типы переадресации.

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

Вот директивы, связанные с этими возможностями:

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

Указание ключей

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

  • IdentityFile: этот параметр можно использовать для указания местоположения ключа, который будет использоваться для каждого хоста. SSH будет использовать ключи, расположенные в ~/.ssh по умолчанию, но если у вас есть ключи, назначенные для каждого сервера, это можно использовать для указания точного пути, где их можно найти.
  • IdentitiesOnly: этот параметр можно использовать, чтобы заставить SSH полагаться только на идентификаторы, предоставленные в файле config. Это может быть необходимо, если агент SSH имеет в памяти альтернативные ключи, которые недействительны для рассматриваемого хоста.

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

Заключение

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

Если вам когда-либо приходилось использовать SSH при очень плохом или прерывистом соединении, таком как Wi-Fi в самолете, вы также можете попробовать использовать mosh, который предназначен для работы SSH в неблагоприятных обстоятельствах.