Windows server клиент linux

Руководство по установке Windows Server

Подсистема Windows для Linux (WSL) доступна для установки на Windows Server 2019 (версия 1709) и более поздних версий. В этом руководстве рассматриваются действия по включению WSL на компьютере.

Установка WSL в Windows Server 2022

Теперь Windows Server 2022 поддерживает простую установку WSL с помощью команды:

Теперь вы можете установить все необходимые компоненты для запуска WSL в Windows Server 2022. Для этого введите эту команду в PowerShell от имени администратора или в командной строке Windows и перезапустите компьютер.

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

Из стандартной документации по WSL вы узнаете, как выполнять следующие задачи:

Установка WSL в предыдущих версиях Windows Server

Чтобы установить WSL в Windows Server 2019 (версия 1709+), выполните действия, описанные ниже.

Включение подсистемы Windows для Linux

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

Запустите PowerShell от имени администратора и выполните следующую команду:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux 

Скачивание дистрибутива Linux

Инструкции и ссылки для скачивания нужного дистрибутива Linux см. в разделе Скачивание дистрибутивов в статье по выполнению установки вручную.

Извлечение и установка дистрибутива Linux

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

Извлеките содержимое пакета .appx , с помощью PowerShell:

Rename-Item .\Ubuntu.appx .\Ubuntu.zip Expand-Archive .\Ubuntu.zip .\Ubuntu 

Add-AppxPackage .\app_name.appx 

Сбой установки с ошибкой 0x8007007e. При возникновении этой ошибки система не поддерживает WSL. Убедитесь, что вы используете сборку Windows 16215 или более позднюю версию. Проверьте используемую сборку. Также убедитесь, что WSL включен и ваш компьютер перезагружен после включения этой функции.

3. Добавьте путь к дистрибутиву Linux в переменную PATH в Windows (в этом примере C:\Users\Administrator\Ubuntu ) с помощью PowerShell:

$userenv = [System.Environment]::GetEnvironmentVariable("Path", "User") [System.Environment]::SetEnvironmentVariable("PATH", $userenv + ";C:\Users\Administrator\Ubuntu", "User") 

Теперь вы можете запустить дистрибутив из любого пути, введя .exe . Например: ubuntu.exe .

Источник

Перекрестное опыление: управляем 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:

cat /etc/passwd | ConvertFrom-Csv -Delimiter ':' -Header Name,Passwd,UID,GID,Description,Home,Shell | Sort-Object Name | Format-Table

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

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

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

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

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

curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/microsoft.repo yum install -y powershell pwsh

После установки появилась возможность запускать привычные 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, после чего перезапустить сервер командой:

/opt/omi/bin/service_control restart

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

winrm set winrm/config/client/auth @ winrm set winrm/config/client @ winrm set winrm/config/service/auth @ winrm set winrm/config/service @

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

winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/OMI_Identify?__cimnamespace=root/omi -r:http://server:5985 -auth:Basic -u:root -p:"password" -skipcncheck -skipcacheck -encoding:utf-8 -unencrypted

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

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

/opt/omi/bin/omicli ei root/cimv2 Win32_Environment --auth Basic --hostname server -u username -p password --port 5985 

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

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

yum groupinstall 'Development Tools' yum install openssl-devel pam-devel git clone --recursive [https://github.com/PowerShell/psl-omi-provider.git](https://github.com/PowerShell/psl-omi-provider.git) cd psl-omi-provider/ make release rpm -ihv target/Linux_ULINUX_1.0_x64_64_Release/psrp-1.4.1-0.universal.x64.rpm

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

$cred = Get-Credential #пропустим проверку сертификата для нашей тестовой лаборатории $o = New-PSSessionOption -SkipCACheck -SkipRevocationCheck -SkipCNCheck #выполнение команды: Invoke-Command -ComputerName server -ScriptBlock < Get-Process >-Authentication Basic -SessionOption $o -Credential $cred -UseSSL | Select-Object -First 5 #подключение к консоли Enter-PSSession -ComputerName 'server' -Credential $cred -Authentication basic -UseSSL -SessionOption $o

С Windows на Linux.

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

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

 Invoke-Command -ComputerName server1,server2,server3 -ScriptBlock

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

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

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

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

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

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

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

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

powershell -ExecutionPolicy Bypass -File install-sshd.ps1 

.\ssh-keygen.exe -A .\FixHostFilePermissions.ps1 -Confirm:$false

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

```bash PasswordAuthentication yes ```

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

Subsystem powershell C:/Program Files (x86)/PowerShell/6.0.0-beta.9/pwsh.exe -sshs -NoLogo -NoProfile

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

setx path "%path%;C:\Program Files\OpenSSH"

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

Set-Service sshd -StartupType Automatic Set-Service ssh-agent -StartupType Automatic net start sshd

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

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

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

Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile

Теперь проверим подключение через командлет 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 хоть и медленно, но начинают стираться, что безусловно радует.

Источник

Как подключиться к виртуальному серверу Windows по RDP из Linux?

Либо можно точно так же установить всё это через менеджер пакетов Synaptic:

После установки запускаем remmina и настраиваем подключение к удалённому серверу.

В поле “Сервер” вписываете ip-адрес вашего сервера, имя пользователя сервера и пароль, который вам выдали при создании.

Параметр “Глубина цвета” следует задать таким, чтобы соединение не тормозило. Часто возникает ошибка, если его поставить слишком большим.

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

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

После первого подключения, вам предложат принять сертификат. Соглашаемся с этим.

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

Либо, в случае, если у сервера нет графического интерфейса, то через PowerShell по адресу

Обратите внимание, что имя папки дано для примера. В вашем случае это имя может быть отличное от “rdpfiles”, но в любом случае это будет подпапка папки \\TSCLIENT .

Из обнаруженных проблем, клиента Remmina – иногда некорректно монтируется удалённая папка и сервер её не видит. Для этого необходимо полностью отключить клиент Remmina (в том числе выйти из фоновой версии программы) и перезапустить её. Тогда подключение работает корректно.

Источник