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

Если вы хотите добавить некоторые дополнительные ограничения безопасности, минимизировать сбои или предотвратить запястный туннель, ssh_config часто используется недостаточно, но мощный инструмент. Наша цель – упростить управление парком серверов и пользователей. Мы сделаем это здесь, создав файл гибкой конфигурации для нашего SSH-клиента.

Обратите внимание, это сообщение нет о конфигурации на стороне сервера через sshd_config.

Что такое ssh_config?

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

ssh -i /users/virag/keys/us-west/ed25519 -p 1024 -l virag  myserver.aws-west.example.com

Это слишком долго, чтобы печатать один раз, не говоря уже о том, чтобы печатать несколько раз в день. Если вы управляете несколькими серверами и виртуальными машинами, создание настраиваемого файла ~ / .ssh / ssh_config – отличный способ сократить часто используемые команды ssh. (Читать далее: “Сравнение ключей SSH. »)

Например, мы можем сократить приведенное выше до ssh myserver отредактировав ssh_config следующим образом:

Host myserver
      Hostname myserver.aws-west.example.com
      User virag
      Port 1024
      IdentityFile /users/virag/keys/us-west/ed25519

Как работает ssh_config?

Клиент SSH считывает информацию о конфигурации из трех мест в следующем порядке:

  1. Общесистемный в / etc / ssh / ssh_config
  2. Зависит от пользователя в ~ / .ssh / ssh_config
  3. Флаги командной строки, передаваемые в SSH напрямую

Это означает, что флаги командной строки (# 3) могут отменять пользовательскую конфигурацию (# 2), которая может отменять глобальную конфигурацию (# 1).

Возвращаясь к приведенному выше примеру, вы можете заметить, что ssh_config организован в строфы, начинающиеся с заголовка хоста:

Host [alias]
      Option1 [Value]
      Option2 [Value]
      Option3 [Value]

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

Host myserver2
      Hostname myserver2.aws-west.example.com
Host myserver*
      Hostname myserver1.aws-west.example.com
      User virag
      Port 1024

Используя псевдоним myserver1, мы получаем то, что ожидаем от второй строфы.

      Hostname myserver1.aws-west.example.com
User virag
Port 1024

Но myserver2 также имеет аналогичный список опций.

      Hostname myserver2.aws-west.example.com
      User virag
      Port 1024

Клиент SSH получает эту информацию путем сопоставления с образцом и блокировки значений при последовательном чтении файла. Поскольку myserver2 соответствует как myserver2, так и myserver *, он сначала принимает значение Hostname из myserver2. Затем, когда дело доходит до второго совпадения с шаблоном, используются значения User и Port, но поле Hostname уже заполнено. Позвольте мне повторить: SSH принимает первый значение для каждого варианта.

ssh_config пример

Расширяя то, что мы узнали, давайте посмотрим, как мы можем организовать ssh_config, когда у нас небольшой парк. Возьмем следующий сценарий:

  • Virag работает с шестью средами: Dev, Test и Prod в регионах AWS восточного и западного побережья.
  • У Virag есть постоянный пользовательский доступ к средам Dev и Prod, но он имеет root-доступ в Test.
  • В производственных средах применяются более строгие меры безопасности.

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

Host east-prod
      HostName east-prod.prod.example.com
Host *-prod
      HostName west-prod.prod.example.com
      User virag
      PasswordAuthentication no
      PubKeyAuthentication yes
      IdentityFile /users/virag/keys/production/ed25519
Host east-test
      HostName east-test.test.example.com
Host *-test
      HostName west-test.test.example.com
      User root
Host east-dev
      HostName east-dev.east.example.com
Host *-dev
      HostName west-dev.west.example.com
      User virag
Host * !prod
      PreferredAuthentications publickey
Host *
      HostName bastion.example.com
      User Default
      ServerAliveInternal 120
      ServerAliveCountMax 5

Если бы мы бежали ssh east-test, наш полный список вариантов будет выглядеть так:

HostName east-test.test.example.com
User root
PreferredAuthentications publickey
ServerAliveInternal 30
ServerAliveCountMax 5

Клиент SSH подобрал предполагаемые значения параметров путем сопоставления с east-test, * -test, *! Prod и *. Вы можете заметить, что строфа Host * будет применяться к любому аргументу SSH. Другими словами, Host * определяет глобальную настройку для всех пользователей. Это особенно полезно для применения средств управления безопасностью, доступных клиенту. Выше мы использовали всего два, но есть несколько ключевых слов это повысит безопасность, например CheckHostIP, HashKnownHosts, StrictHostKeyChecking и многие другие скрытые жемчужины. (Читать далее: “Как правильно использовать SSH. »)

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

Если возникают разовые случаи, всегда помните, что параметры, введенные в командной строке, переопределят параметры в ssh_config:

ssh -o "User=root" dev

Простота SSH

Более широкий вывод из этой статьи – сделать жизнь проще. Этого можно достичь даже с помощью простейших параметров конфигурации, используемых умным способом (или с помощью Телепорт). Это позволяет нам обеспечивать надежную безопасность и сводить к минимуму человеческий фактор. (Читать далее: “Безопасность инфраструктуры, удобной для разработчиков. »)

Вираг Моди присоединился Телепорт в январе 2020 года, после создания компании по аудиту программного кода для приложений Ethereum. Он продолжает изучать современные технологии и создает высококачественный письменный и видеоконтент. В свободное время Вираг увлекается скалолазанием, видеоиграми и гуляет со своей собакой.

Форум новых технологий предоставляет площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор является субъективным и основан на нашем выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы отправляйте по адресу newtechforum@infoworld.com.

Авторские права © 2021 IDG Communications, Inc.


#Сделайте #жизнь #проще #sshconfig

Source link