Windows and linux admin

Перекрестное опыление: управляем Linux из-под Windows, и наоборот

В прошлой статье я обещал рассмотреть механизм удаленного подключения с Windows на серверы под управлением *nix, и наоборот при помощи PowerShell. Обещанного обычно ждут три года, но я успел чуть раньше. Что ж, если хочется с верного макбука управлять гетерогенной инфраструктурой, или наоборот ― с Surface Pro рулить Linux-серверами без всяких putty, ― прошу под кат.

Microsoft Loves Linux

Еще в 2015 году Microsoft торжественно объявила о запуске программы «Microsoft Linux». Сюда вошла как банальная поддержка гостевых *nix-like OS на Hyper-V, так и встроенная в Windows 10 Ubuntu и возможность запуска в Docker продуктов Microsoft, таких как SQL Server.

Компания также опубликовала исходный код PowerShell, что позволило запускать «Ракушку Мощи» не только на Windows. Из-под одноименного аккаунта на Github, помимо исходного кода, выложены и бинарники под большинство современных систем (лицензия MIT).

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

Порой удобно совмещать традиционные консольные команды со вставками PowerShell:

Для подключения к Windows-машинам при помощи PowerShell используется протокол WS-Man. Для GNU\Linux привычен SSH. Так как сегодня становятся универсальными оба протокола, разберем их подробнее.

PowerShell 6.0 под Windows и *nix, пока еще находится в бете. Поэтому не рекомендую без хорошего тестирования применять на боевых серверах описанное ниже.

Магомед не идет к горе

Когда технология удаленного доступа при помощи PowerShell только набирала обороты, единственным универсальным способом подключения к разным системам был протокол WS-Man. Для тестового стенда я взял Windows Server 2016 и Centos 7, для которых и буду настраивать возможность удаленного подключения и выполнения команд при помощи этого протокола.

Для начала установим на Centos свежий PowerShell:

После установки появилась возможность запускать привычные Windows-администратору командлеты. Например, посмотрим версию PS и получим список запущенных процессов командлетами $PSVersionTable и Get-Process:

Работаем в консоли PowerShell на CentOS.

Чтобы подключаться к Linux-машине с консоли Windows, нам понадобится установить и настроить:

• OMI (Open Management Infrastructure) ― адаптация WMI, которую также можно использовать для управления компьютерами с ОС, отличными от Windows;
• PSRP (PowerShell Remoting Protocol) ― библиотека, необходимая для удаленного подключения PowerShell.

Подробно с работой и эволюцией OMI и PSRP можно ознакомиться в отличном материале от Matt Wrock, я же просто установлю OMI командой:

Далее нужно настроить порты и аутентификацию в конфигурационном файле /etc/opt/omi/conf/omiserver.conf, после чего перезапустить сервер командой:

Для упрощения эксперимента я не буду настраивать ни NTLM-аутентификацию, ни Kerberos. Еще и шифрование отключу ― разумеется, в боевой среде делать этого не стоит. Для включения текстовой аутентификации и шифрования на стороне Windows в работе winrm достаточно выполнить следующие команды:

После настройки можно проверить работу OMI из консоли Windows:

Подключаемся к CentOS из cmd.

Теперь проверим работу обратным подключением ― из Linux к Windows:

… а затем с CentOS подключаемся к Windows.

После того, как WMI\OMI заработал, нужно установить и настроить PSRP. К сожалению и вопреки инструкции, бинарник отсутствует. Библиотеку пришлось компилировать, долго и нудно исправляя возникающие ошибки зависимостей:

Теперь мы сможем подключаться с Windows на Linux и наоборот при помощи PowerShell. Начнем с Windows на Linux:

С Windows на Linux.

Аналогичным образом можно провести и обратное подключение.

Invoke-Command можно «натравить» на список компьютеров, и с рабочей станции Windows создать пользователя на всех серверах Linux командой вида:

Надо сказать, что способ не самый удобный и эффективный. Минусов добавляет компиляция библиотек, разнообразные баги ― например, на момент написания статьи PSRP не позволял нормально подключиться из Linux в Windows.

Да и сами разработчики рекомендуют не плясать вокруг WS-Man, а обратиться к проверенному способу ― SSH. Что ж, попробуем и его.

Гора идет к Магомету

На этот раз машина с Windows получит чуть больше специфической подготовки ― нужно установить свежий PowerShell и OpenSSH.

После можно проверить синтаксис командлета New-PSSession. Если все произошло как надо, то командлет, помимо привычного параметра ComputerName, будет поддерживать и HostName.

PowerShell 6.0.0-beta.9 и обновленный синтаксис командлета.

Качаем последний релиз или используем пакет из репозитория Chocolatey. Все это разархивируем в \Program Files\OpenSSH.

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

Теперь генерируем ключи:

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

Если вы также хотите автоматически запускать PowerShell при подключении по SSH, то в параметре subsystem нужно прописать путь к желаемой версии PS:

Для работы клиента SSH нужно добавить директорию в %PATH% любым удобным способом. Например, таким:

Остается только настроить и запустить службы:

После установки уже можно наслаждаться подключением к серверу Windows по ssh.

C Windows через Putty на Linux, с Linux обратно на Windows по SSH.

На достигнутом останавливаться не будем и перейдем к настройке Linux. При настройке сервера SSH по умолчанию достаточно прописать PowerShell в Subsystem:

Теперь проверим подключение через командлет New-PSSession и Invoke-Command.

Работаем из PowerShell с Linux-сервером.

Теперь подключимся из Linux к Windows:

Работаем из PowerShell с Windows-сервером.

В отличие от WS-Man, SSH настраивается намного проще и работает стабильнее. Да и беспарольное подключение по ключам настраивать привычнее.

В хозяйстве пригодится

С однозначным «советом потребителю» все опять сложно: SSH проще в настройке и стабильнее, но WS-Man использует API и позволяет применять инструменты вроде JEA. На боевых серверах использовать WS-Man я бы не стал однозначно, а вот реализация OpenSSH в Windows как сервера, так и клиента мне понравилась. Для самопальной автоматизации вполне подойдет даже без PowerShell.

В любом случае, границы между Linux и Windows хоть и медленно, но начинают стираться, что безусловно радует.

Источник

Установка WSL

Предварительные требования

Вам следует использовать Windows 10 версии 2004 и выше (сборка 19041 и выше) или Windows 11.

Чтобы проверить версию и номер сборки Windows, нажмите клавиши WINDOWS+R, введите winver и щелкните ОК. Вы можете выполнить обновление до последней версии Windows в меню параметров или с помощью помощника по Центру обновления Windows.

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

Установка

Теперь вы можете установить все необходимое для запуска подсистемы Windows для Linux (WSL), введя эту команду в PowerShell или командной строке Windows, а затем перезапустив компьютер.

Эта команда позволяет включить необходимые дополнительные компоненты, скачать последнюю версию ядра Linux, установить WSL 2 в качестве компонента по умолчанию и установить дистрибутив Linux (по умолчанию Ubuntu; инструкции по установке другого дистрибутива см. ниже) .

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

Изменение установленного дистрибутива Linux по умолчанию

По умолчанию в качестве устанавливаемого дистрибутива Linux используется Ubuntu. Для этого используйте флаг -d .

• Чтобы изменить установленный дистрибутив, введите wsl —install -d . Замените именем дистрибутива, который хотите установить.
• Чтобы просмотреть список доступных дистрибутивов Linux, доступных для скачивания через Интернет-магазин, введите wsl —list —online или wsl -l -o .
• Чтобы установить дополнительные дистрибутивы Linux после исходной установки, можно также использовать команду wsl —install -d .

Если вы хотите установить дополнительные дистрибутивы из командной строки Linux или Bash (а не из PowerShell или командной строки), используйте .exe в команде wsl.exe —install -d . Чтобы получить список доступных дистрибутивов, используйте wsl.exe -l -o .

Если во время установки возникла проблема, см. раздел Установка руководства по устранению неполадок.

Настройка сведений о пользователе Linux

После установки WSL необходимо создать учетную запись пользователя и пароль для установленного дистрибутива Linux. Дополнительные сведения см. в статье Рекомендации по настройке среды разработки WSL.

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

Мы рекомендуем использовать наше пошаговое руководство Рекомендации по настройке среды разработки WSL. В нем описано, как настроить имя пользователя и пароль для установленных дистрибутивов Linux, использовать основные команды WSL, установить и настроить Терминал Windows, настроить управление версиями Git, отредактировать код и выполнить отладку с помощью удаленного сервера VS Code. Кроме того, в руководстве приведены рекомендации по хранению файлов, настройке базы данных, подключению внешнего диска, настройке ускорения GPU и пр.

Хотите испытать новейшие предварительные версии функций WSL?

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

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

Источник

Linux машина в домене Windows AD с помощью sssd и krb5

Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.

Для примера будем использовать:

Домен = contoso.com
Контроллер домена = dc.contoso.com

Запускаем терминал Ubuntu:

1. Переключаемся под рута

2. Устанавливаем необходимые пакеты

3. Редактируем /etc/krb5.conf, в качестве отступов используется табуляция

4. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:

5. Пробуем получить Kerberos ticket от имени администратора домена:

Если тикет получен успешно, то теперь можно сгенерировать Kerberos principals для данного хоста, регистр важен:

Сейчас наш хост должен отобразиться в списке компьютеров в каталоге. Если все так — удаляем полученный Kerberos ticket:

6. Создаем файл /etc/sssd/sssd.conf со следующим содержимым:

Описание параметров конфигфайла sssd можно посмотреть тут

Устанавливаем права доступа для файла sssd.conf:

Перезапускаем SSSD service

7. Редактируем настройки PAM

редактируем файл /etc/pam.d/common-session, после строки

переопределить параметры через системные настройки PAM, вызываем

и отмечаем пункты sss auth и makehomdir. Это автоматически добавит
строчку выше в common-session и она не будет перезатерта при обновлении системы.

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

P.S.: Можно дать права на использование sudo доменным группам. Используя visudo, редактируем файл /etc/sudoers, или лучше, как рекомендует maxzhurkin и iluvar, создаем новый файл в /etc/sudoers.d/ и редактируем его

добавляем требуемую группу — например, Domain Admins (если в названии группы есть пробелы — их необходимо экранировать):

P.S.S.: Спасибо gotch за информацию о realmd. Очень удобно — если не нужны специфические настройки, то ввод машины в домен занимает, по сути, три (как заметил osipov_dv четыре) команды:

1. Устанавливаем нужные пакеты:

2. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:

3. Проверяем, что наш домен виден в сети:

4. Вводим машину в домен:

5. Редактируем настройки PAM

Дополнительный плюс данного варианта — сквозная авторизация на файловых ресурсах домена.

Источник