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

Вступление

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

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

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

Предпосылки

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

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

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

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

Файл конфигурации на стороне клиента называется + config + и находится в домашнем каталоге вашего пользователя в каталоге конфигурации + .ssh +. Часто этот файл не создается по умолчанию, поэтому вам может потребоваться создать его самостоятельно:

touch ~/.ssh/config

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

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

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

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

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

Host




Host


Host


Host *

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

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

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

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

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

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

Host devel
   HostName devel.example.com
   User tom

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

ssh devel

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

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

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

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

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

Давайте еще раз посмотрим на файл макета + config +, который мы использовали в последнем разделе:

Host




Host


Host


Host *

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

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

Давайте попробуем это снова, делая вид, что вызываем + ssh secondhost + из командной строки.

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

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

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

Основные параметры подключения

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

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

Чтобы подключиться как пользователь с именем + apollo + к хосту с именем + example.com +, который запускает своего SSH-демона через порт + 4567 + из командной строки, мы могли бы предоставить информацию о переменной различными способами. Наиболее распространенным, вероятно, будет:

ssh -p 4567 [email protected]

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

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

Здесь мы установили все опции, которые мы хотим использовать с флагом + -o +. Мы даже указали хост как «что-нибудь» в качестве псевдонима, как мы могли бы в файле конфигурации, как мы описали выше. Фактическое имя хоста берется из опции + HostName +, которую мы устанавливаем.

Имена опций с большой буквы, которые мы используем во второй форме, те же, что мы должны использовать в нашем файле + config +. Вы можете найти полный список доступных опций, набрав:

man ssh_config

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

В этот момент у нас также есть возможность назначить псевдоним для этого соединения. Давайте воспользуемся этим, чтобы нам не приходилось каждый раз вводить полное имя хоста. Мы будем использовать псевдоним «home» для ссылки на это соединение и связанные параметры:

Host home

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

Host home
   HostName example.com
   User apollo
   Port 4567

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

Port 4567
Port=4567
Port = 4567

Единственное отличие состоит в том, что в зависимости от параметра и значения использование знака равенства без пробелов может позволить вам указать параметр в командной строке без кавычек. Поскольку мы сосредоточены на нашем файле + config +, это полностью зависит от ваших предпочтений.

Настройка общих параметров

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

Host home
   HostName example.com
   User apollo
   Port 4567

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

Host home
   HostName example.com
   User apollo
   Port 4567

Host work
   HostName company.com
   User apollo

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

Если мы используем имя пользователя «apollo» на всех машинах, к которым мы подключаемся, мы можем поместить это в наше общее определение «Host», помеченное одним + * +, которое соответствует каждому соединению. Помните, что более общие разделы должны идти дальше вниз:

Host home
   HostName example.com
   Port 4567

Host work
   HostName company.com

Host *
   User apollo

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

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

Если имя пользователя «apollo» используется на almost всех ваших хостах, вероятно, лучше оставить его в общем разделе + Host * +. Это будет применяться к любым хостам, которые не получили имя пользователя из разделов выше. Для наших аномальных машин, которые используют другое имя пользователя, мы можем переопределить значение по умолчанию, предоставив альтернативу. Это будет иметь приоритет до тех пор, пока оно определено перед общим разделом:

Host home
   HostName example.com
   Port 4567

Host work
   HostName company.com

Host oddity
   HostName weird.com
   User zeus

Host *
   User apollo

Для хоста + oddity + SSH будет подключаться с использованием имени пользователя« zeus ». Все остальные соединения не получат свое имя пользователя, пока не достигнут общего определения `+ Host * +.

Что произойдет, если имя пользователя «apollo» используется несколькими подключениями, но не достаточно распространено, чтобы использовать его в качестве значения по умолчанию? Если мы хотим переименовать псевдонимы, которые мы используем, чтобы иметь более распространенный формат, мы можем использовать подстановочный знак, чтобы применить дополнительные параметры только к этим двум хостам.

Мы можем изменить псевдоним + home + на что-то вроде + hapollo + и рабочее соединение на что-то вроде + wapollo +. Таким образом, оба хоста совместно используют часть своего псевдонима + apollo +, что позволяет нам нацеливать его на другой раздел с использованием подстановочных знаков:

Host hapollo
   HostName example.com
   Port 4567

Host wapollo
   HostName company.com

Host *apollo
   User apollo

Host *
   User diffdefault

Здесь мы переместили общее определение + User + в раздел host, который соответствует SSH-соединениям, пытающимся подключиться к хостам, которые заканчиваются на + apollo +. Любое соединение, не оканчивающееся на + apollo + (и без собственного раздела + Host +, определяющего + User), получит имя пользователя` + diff default`.

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

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

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

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

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

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

Ниже приведены некоторые другие настройки, которые вы можете настроить на широком уровне, например, в разделе «+ Host * +».

* + ServerAliveInterval + *: этот параметр можно настроить, чтобы SSH знал, когда отправлять пакет для проверки ответа от сервера. Это может быть полезно, если ваше соединение ненадежно, и вы хотите знать, если оно все еще доступно.
* + LogLevel + *: Это настраивает уровень детализации, с которой SSH будет регистрироваться на стороне клиента. Это может быть использовано для отключения регистрации в определенных ситуациях или увеличения многословия при попытке отладки. От наименее до большинства подробных уровней: ТИХАЯ, ФАТАЛЬНАЯ, ОШИБКА, ИНФОРМАЦИЯ, 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, хранящиеся в агенте на нашей локальной машине, что позволяет нам подключаться с удаленной системы, используя учетные данные, хранящиеся в нашей локальной системе. Мы также можем запускать приложения в удаленной системе и пересылать графический дисплей в нашу локальную систему, используя пересылку X11.

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

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

Оба варианта - «да» или «нет».

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

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

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

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

Мультиплексирование SSH через одно соединение TCP

SSH имеет возможность использовать одно TCP-соединение для нескольких SSH-соединений с одним и тем же хостом. Это может быть полезно, если требуется некоторое время для установления TCP-рукопожатия на удаленном конце, поскольку он удаляет эти издержки из дополнительных соединений SSH.

Следующие параметры можно использовать для настройки мультиплексирования с SSH:

* + ControlMaster + *: эта опция указывает SSH, разрешать ли мультиплексирование, когда это возможно. Как правило, если вы хотите использовать эту опцию, вы должны установить ее на «auto» либо в разделе хоста, который медленно подключается, либо в общем разделе «+ Host * +».
* + ControlPath + *: эта опция используется для указания файла сокета, который используется для управления соединениями. Это должно быть место в файловой системе. Обычно это делается с помощью переменных SSH, чтобы легко пометить сокет хостом. Чтобы назвать сокет на основе имени пользователя, удаленного хоста и порта, вы можете использовать + / path / to / socket / +.
* + ControlPersist + *: эта опция устанавливает количество времени в секундах, в течение которого TCP-соединение должно оставаться открытым после закрытия последнего SSH-соединения. Установка этого большого числа позволит вам открывать новые соединения после закрытия первого, но обычно вы можете установить это значение на что-то низкое, например «1», чтобы не оставлять открытым неиспользуемое соединение TCP.

Как правило, вы можете настроить это, используя раздел, который выглядит примерно так:

Host *
   ControlMaster auto
   ControlPath ~/.ssh/multiplex/%r@%h:%p
   ControlPersist 1

После этого вы должны убедиться, что каталог создан:

mkdir -p ~/.ssh/multiplex

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

ssh -S none @

Заключение

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

TOC