консоль kali linux на windows
Kali Linux в Windows
С введением подсистемы Windows для Linux (WSL) в Windows 10 появились новые возможности, такие как поддержка Linux дистрибутивов, в частности Ubuntu. В этой статье я расскажу, как с помощью этой подсистемы подключить Kali LInux в Windows среде не используя системы виртуализации.
Хотя работы Kali на Windows может быть не оптимальна из-за различных ограничений, все еще существует множество ситуаций, когда Kali Linux может быть необходим для использования совместно с Windows 10. Например это может быть консолидация рабочих областей, особенно если Windows является вашей основной рабочей средой. Также может быть полезна стандартизация инструментов и сценариев для работы в нескольких средах, быстрый перенос инструментов командной строки для тестирования проникновения в Linux для Windows и т. д.
Для того, чтобы установить Kali необходимо выполнить несколько шагов. В первую очередь необходимо включить и установить Windows Subsystem for Linux Command Reference — запустить powershell оболочку с правами администратора, выполнить команду и перезагрузить вашу машину:
После перезагрузки необходимо установить Ubuntu-environment:
Далее вам необходимо установить WSL Distribution Switcher. Эта программа предназначена для переключения подсистемы Linux для использования различных дистрибутивов Linux. Образы rootfs в настоящее время загружаются из репозиториев Docker Hub в виде исходников или prebuilt-сборок.
(Для клонирования проекта с git-репозитория необходимо установить git-клиент на Windows 10, например отсюда: https://git-scm.com/download/win, а также установить python для Windows).
Теперь, когда Kali-environment развернут на вашей Windows 10 вы можете вызвать его с помощью команды:
Далее вам необходимо обновить Kali Linux и установить кириллическую локализацию (при необходимости):
После развертывания Kali-environment мы можем установить необходимые утилиты и использовать их из Windows:
Таким простым способом вы получите современный дистрибутив для тестирования на проникновение в вашей Windows среде без запуска систем виртуализации, перезагрузок и прочего. Также, необходимо учесть, что из такой среды у вас не будут нормально работать утилиты по работе с железом, для вардрайвинга и т.д.
Kali Linux внутри Windows 10
Данную статью хотим посветить всем тем, кому по той или иной необходимости приходиться соприкасяться с Kali по долгу службы, а использовать его в повседневной жизни, как Вы понимаете не совсем комфортно. Но фишка данной статьи не просто в установке компонентов Linux, так же мы с Вами поднимим иксы (X) дабы сделать данную систему совершенно пригодной для полноценного проведения тестирования на проникновение.
Давно не секрет, что Microsoft в недалеком прошлом пошли на очень, как я считаю отличный шаг с разработчиком Ubuntu компанией Canonical. Они решили интегрировать bash прямо в Windows 10 и начиналось это спростых команд типа wget, grep, dig и других, аналогов которых в винде попросту нет.
Прошло время, и Вы не поверете, они не только добились полного портирования большинства команд и приклада, теперь Вы можете загрузить и установить Kali Linux или другие сборки Linux прямо из магазина Microsoft. К примеру есть уже и Debian и Suse, Ubuntu, Kali Linux…
Установка Kali Linux на Windows 10 происходит без костылей и танцев с бубном, точно также как любое другое обычное приложение устанавливаемое с Microsoft Store. Если У Вас все же появились траблы с установкой приложений или открытием магазина приложений (тут есть некоторые ньюансы, но лечатся по первому запросу в поисковиках) – ребята не качайте сборки винды, пользуйтесь оригинальными образами и не будет никаких проблем.
Итак, после загрузки основного приложения, нам необходимо активировать подсистему Linux в Windows 10 и сделать это можно 2 способами:
2. Используем мощнейший инструмент PowerShell:
Ну и ребут конечно же, как в Винде без него…
После загрузки винды, идем в ПУСК и пишем словосочетание Kali:
Запустив, система попросит создать пользователя и пароль к нему, создайте пару.
Теперь мы хотим не просто голую систему, а навешать ее софтом, у куда же без Metasploit’a…
Но, с установкой Metasploit может возникнуть одна проблема – это модули Metasploit, которые сожрут даже самый неадекватный антивирус, а в первую очередь защитником Windows. Для этого мы до его установки попросту добавим в доверенную зону:
Затем ставим сам метасплоит:
Ну и не буду Вам говорит, что это и зачем он нужен, запускаете msfconsole и радуетесь.
Далее я прикину небольшой набор утилит которыми пользуюсь сам практически повседневно:
Этот список можно продолжать бесконечно и все зависит от необходимости…
Естенственно будет много зависимостей, но для этого мы сюда и собрались, сделать пригодную для пентестинга оболочку внутри рабочей и полноценной Windows 10.
А теперь, то о чем обещал. Я долго использую связку Windows 10 + Kali, но до этого пользовался как основной осью сборкой Linux на базе Debian – Deepin (сделаю обзор о данной оси отдельно, считаю ее лучшим аналогом Винды для полного перехода на линукс среду для ленивых). Так вот, для эксплуатации, мне лично любимых и подручных sparta и armitage в установленной оболочке попросту нет X-ов или интерфейса, но я тут на днях замарочился и состряпал готовый скрипт по установке xfce на Kali под Windows 10. Сразу поясню, вся соль не в запуске интерфейса внутри эмулятора Linux, что в принципе невозможно, а именно возможность подключения к нашему Kali по RDP.
Итак в том же терминале пишем:
Затем запускаем RDP сервис:
и цепляемся привычным для нам RDP клиентом mstsc на локалхост и порт 3390.
Появится окно в котором мы авторизуемся под имеющимся логином и паролем:
И вот пруф рабочей полноценной Kali Linux Без вирутальной машины:
Всем спасибо, думаю не зря распинался, подписывайтесь на наш телеграм канал и будете в тренде последних новостей и интересных авторских статей.
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Как пользоваться Kali Linux в WSL (подсистеме Windows для Linux): подборка лучших программ (ч. 1)
Инструменты Kali Linux в WSL
В этой статье мы узнаем, что можно делать в Kali Linux в WSL (подсистеме Windows для Linux) и соберём подборку лучших инструментов для новичков
Надеюсь, вы уже познакомились с предыдущими статьями, посвящённым WSL:
Следующая статья не про WSL, но то, что написано в ней обязательно нужно знать любому пользователю Linux:
Итак, теперь, когда вы уже установили всё как нужно по данным инструкциям, просто откройте командную строку Windows (или PowerShell) и запустите Kali Linux.
Практически все рассмотренные в данной и последующих частях инструменты являются утилитами командной строки, то есть для них не нужен графический интерфейс. Если вам нужно открыть одновременно несколько консолей Kali Linux, то просто откройте несколько окон CMD или PowerShell и в каждом из них введите
Тем не менее, для данной статьи я буду использовать Kali Linux с графическим интерфейсом — просто чтобы чувствовать «дух Kali Linux». Поэтому в дистрибутиве я запускаю команду:
Если не получилось подключиться с первого раза, то делаем так:
Работу начинаем с полного обновления системы и инструментов:
Подборка лучших инструментов для новичков Kali Linux в WSL
Рассмотренные в этой части инструменты и утилиты я разделил на три группы:
В дистрибутивах WSL неплохо работают разнообразные сетевые инструменты, но нет доступа к аппаратной составляющей компьютера и периферийным устройствам — по этой причине мы не сможем запустить инструменты для аудита безопасности беспроводных сетей.
Для большинства инструментов будут даны ссылки на дополнительные материалы с подробными описаниями программ, опций и инструкциями. При желании вы сможете изучить любой инструмент более подробно.
1. Поиск и эксплуатация уязвимостей
WPScan (Проверка сайтов WordPress в Kali Linux)
Для проверки сайтов, работающих на WordPress, используется программа WPScan. Эта программа может определить старые версии WordPress, тему оформления, установленные плагины, показать известные уязвимости в плагинах и темах оформления WordPress.
Начнём с обновления базы данных (нужно делать один раз после загрузки компьютера):
Для проверки сайтов запустите команду вида:
Например, если я хочу проверить сайт minecraftz.ru, то команда следующая:
Пример результатов сканирования:
Дополнительная информация по использованию программы:
sqlmap (Поиск уязвимости SQL-инъекция)
Программа sqlmap пригодиться тем веб-мастерам, которые программируют и пишут код сервисов, CMS, сайтов. С помощью sqlmap можно найти уязвимость SQL-инъекция.
SQL-инъекция — это одна из самых серьёзных уязвимостей веб-приложений. При запуске программы нужно указать тестируемый параметр, пример:
Пример найденной SQL-инъекции:
На сайте всё очень плохо, найдено сразу три разновидности SQL-инъекций:
Добавим опцию —dbs чтобы увидеть список баз данных:
Итак, доступно три базы данных:
С помощью опции -D указываем интересующую нас базу данных, а опцией —tables мы говорим, что хотим просмотреть список таблиц в этой БД:
Всего одна таблица под названием «docs_region».
Загрузим себе на память базу данных laws15:
Дополнительная информация по использованию программы:
Nikto (сканирование веб-серверов и сайтов)
Nikto – это инструмент оценки веб-серверов. Он предназначен для поиска различных дефолтных и небезопасных файлов, конфигураций и программ на веб-серверах любого типа.
Для сканирования с Nikto нужно запустить команду вида:
Обратите внимание, что протокол также нужно указать.
Пример запуска сканирования сайта forum.comp-web-pro.ru:
Показываемая информация может быть как о серьёзных ошибках, так и о менее важных недочётах (например, не установлены заголовки безопасности HTTP протокола).
Дополнительная информация по использованию программы:
2. Сбор информации
WhatWeb (Узнаём используемые веб-технологии)
Вы можете проверить, что об используемых вашим сайтом технологиях может узнать хакер. Либо сами можете посмотреть технологии, которые применяются на другом сайте. Это делается программой WhatWeb.
Для этого используйте команду вида:
К примеру, я хочу узнать о сайте suay.ru:
Дополнительная информация по использованию программы:
Wig (Простой сбор информации о веб-приложениях)
Wig — это инструмент по сбору информации о веб приложениях, который идентифицирует ряд систем управления контентом (CMS) и другие административные приложения.
Для проверки сайта запустите команду вида:
Проверим, что удастся найти о сайте hackware.ru:
Дополнительная информация по использованию программы:
testssl.sh (Проверка правильности настройки SSL сертификата)
С помощью программы testssl.sh можно проверит, всё ли в порядке с вашим SSL сертификатом, правильно ли он установлен, не содержит ли настройка SSL вероятности использования уязвимых шифров и т.д.
Для проверки запустите команду вида:
Проверим правильность настройки TLS/SSL сайта suay.ru:
Дополнительная информация по использованию программы:
whois (Как узнать, занят ли домен)
Предположим, вы хотите узнать, занято ли доменное имя, но не хотите доверять посторонним сервисам и сайтам. Вы можете сделать проверку прямо на своём компьютере!
Это можно сделать, например, с помощью команды whois. Запустите её следующим образом:
Допустим, я хочу узнать, занят ли домен w-e-b.site:
Если домен уже кем-то зарегистрирован, то будет выведена соответствующая информация о регистрации. Если же домен никем не используется, то будет выведено, что домен не найден (возможны варианты: данные не найдены, записи не найдены и т. д.). Примеры записей, если домен не существует:
Также обязательно будет выведена информация о серверах имён (NS) и, (зависит от конкретного домена), могут быть показаны другие данные, вплоть до имени и номера телефона владельца домена.
Как посмотреть HTTP заголовки
В HTTP заголовках может содержаться информация о редиректе, о сервере и прочее. Вы можете посмотреть HTTP заголовки следующей командой:
Просмотр HTTP заголовков при обращении к сайту suay.ru:
Выполняется редирект, об этом говорит строка Location: https://suay.ru/.
Как узнать IP адрес сайта
Нет ничего проще, чем узнать IP адрес любого сайта. Для этого выполните команду вида:
К примеру, я хочу узнать IP адрес сайта suay.ru:
Как узнать все DNS записи сайта
Все DNS записи сайта можно получить командой вида:
Пример для сайта suay.ru:
Бывает, что некоторые серверы имён отказываются обслуживать запрос если в нём указано ANY, то есть показать все записи. Это не является большой проблемой, так как можно посмотреть все записи просто указывая их по одной в команде вида:
Популярные типы записей:
3. Исследование сети
Nmap (Как проверить открытые порты)
Проверку открытых портов можно сделать программой Nmap.
В самих по себе открытых портах нет ничего плохого. Например, для работы веб-сервера необходимы открытые порты 443 и 80. То есть для используемых служб порты должны быть открыты.
Порты следует закрыть для неиспользуемых служб. Например, если вам не нужен FTP сервер, то порт 21 не должен быть открыт, если вы не используете SSH, то порт 22 не должен быть открыт.
Если вы обнаружили открытый порт с необычным номером, то это может означать, что сервер взломан и хакер установил на этом порту бэкдор.
В первую очередь следует проверять свои собственные сервера (VPS), поскольку на виртуальных хостингах обычно открыто много портов и хостер это делает для каких-то своих нужд.
Для проверки открытых портов используется команда Nmap.
Команда запускается следующим образом:
В этом случае будут проверены самые часто используемые порты. Если вы хотите проверить вообще все порты, то запустите команду так:
Проверка открытых портов сервера, на котором работает сайт suip.biz:
Дополнительная информация по использованию программы:
traceroute (Трассировка маршрута для поиска проблем и исследования сети)
Трассировка маршрута пакета до сетевого хоста показывает все промежуточные узлы, через которые проходит пакет, пока доберётся до указанной цели. То есть с помощью трассировки можно узнать, по каким узлам, с какими IP адресами, передаётся пакет прежде чем быть доставленным до точки назначения.
Трассировка может применяться для выявления связанных с работой компьютерной сети проблем, а также для исследования сети (определения структуры сети, поиска промежуточных сетевых узлов).
Чтобы сделать трассировку, нужно указать удалённый хост — это может быть IP адрес сервера или компьютера или просто адрес сайта:
Например, чтобы сделать трассировка до сервера, на котором запущен сайт w-e-b.site:
ping (для проверки доступности серверов и поиска проблем сети)
Программа ping отправляет на указанный хост запрос и показывает время ответа (если ответ пришёл). В случае возникновения ошибки, программа ping выводит её.
Такое поведение позволяет проверить, есть ли доступ до определённого хоста, а также выявить некоторые проблемы сети, такие как потеря пакетов и большие задержки.
Для использования запустите команду вида:
В отличие от версии ping для Windows, которая отправляет 4 пакета и автоматически завершает работу, в Linux ping (если вы не установили иное опцией) будет отправлять пакеты до бесконечности. Чтобы завершить работу этой или иной утилиты командной строки, нажмите Ctrl+c.
Первая часть получилась достаточно объёмной и насыщенной, а ведь я не затронул даже одну третью часть того, о собирался рассказать. Поэтому обязательно будут следующие части!
Консоль kali linux на windows
This page details the steps to install Win-Kex in under 2 minutes.
Installation
All installation steps, up to the point where we install Win-Kex, are also explained in the 5 minute video guide by the amazing NetworkChuck:
Prerequisites
Install Kali Linux in WSL2
Open PowerShell as administrator and run:
Download and install the WSL2 Linux Kernel from here: https://aka.ms/wsl2kernel
Install Kali Linux from the Microsoft Store
Run Kali and finish the initial setup
Install Win-KeX
Run Win-KeX
Win-KeX supports three modes:
Window Mode: 
To start Win-KeX in Window mode with sound support, run
Refer to the Win-KeX Win usage documentation for further information.
Enhanced Session Mode: 
To start Win-KeX in Enhanced Session Mode with sound support and arm workaround, run
Refer to the Win-KeX ESM usage documentation for further information.
Seamless mode:
To start Win-KeX in Seamless mode with sound support, run
Refer to the Win-KeX SL usage documentation for further information.
Optional Steps:
Choose amongst these options:
Basic Win-KeX in window mode with sound:
Copy the kali-menu.png icon across to your windows picture directory and add the icon and start directory to your WT config:
Basic Win-KeX in seamless mode with sound:
Copy the kali-menu.png icon across to your windows picture directory and add the icon and start directory to your WT config:
Basic Win-KeX in ESM mode with sound:
Copy the kali-menu.png icon across to your windows picture directory and add the icon and start directory to your WT config:
For more information, ask for help via:
or consult the manpage via:
Enjoy Win-KeX!
Updated on: 2021-Nov-15
Author: Re4son
Настройка окружения в CLI. WSL / Windows Terminal
Есть люди, которые большинство рабочего времени проводят в консоли, есть те, кто пользуются терминалом при необходимости, запуская что-то по инструкциям. Но я думаю, что каждый айтишник, будь он разработчиком, сисадмином, сетевым инженером, или даже senior yaml developer`ом, пользуется command line interface. Далеко не все задумываются об улучшении рабочего окружения в CLI и повышении продуктивности работы в терминале. Мне хотелось бы поделиться своим опытом настройки окружения для работы с Linux из Windows.
Из статьи вы узнаете, какими средствами и каким терминалом актуально пользоваться в настоящее время для запуска Linux приложений в Windows 10. Речь пойдёт о WSL 2 и Windows Terminal, набирающим всё большую популярность у пользователей, которым для работы нужен Linux. Так как большинство use-case`ов у меня связаны с удалённым подключением через SSH, большая часть информации будет релевантно для случаев удалённых подключений, со всеми особенностями, связанными с этим (пробросом ssh ключей через ssh agent, пробросом X-сервера, управлением подключениями etс).
Внимание! Под катом много картинок и ужатого, но местами объёмного, gif`а, рекомендуется открывать статью при наличии соответствующего доступа к интернету. Заходите под кат, если вам актуален запуск Linux утилит под Windows, оптимизация работы в окружении CLI, или вы просто любите технические тексты и цветные терминалы. Текст я постарался скрасить скринкастами и скриншотами терминала, чтобы было не скучно.
Введение
Как на домашнем, так и на рабочем ноутбуке, единственная ОС сейчас у меня Windows 10, и в этом году я окончательно перешёл на использование только WSL вместо VM / dualboot / Cygwin / MinGW. Теперь мой терминал по умолчанию — это локальный шелл WSL, где я могу запускать практически любые задачи, как в нативном Linux. Кроме этого, в домашней сети работает мини-сервер Intel NUC, на котором развёрнут Proxmox с LXC контейнерами и KVM, в котором крутится Docker. На все VM хожу по SSH, с ключами из директории Windows. Очень много времени в профессиональной деятельности проходит в CLI, с домашним сервером и сетью тоже самое. Поэтому всегда возникает желание разобраться с инструментами для более комфортной работы в терминале, а в Windows всегда с этим были проблемы. Но сейчас всё меняется.
Эта и последующие статьи больше ориентированы на энтузиастов, которые ищут свежие решения и желают прокачать свой шелл. Но и новичкам должно быть что-то интересно, хотя статья получилась с достаточно глубоким погружением в тему и предполагает, что у читателя есть какие-то фундаментальные знания в Linux. Вся информация собрана на основе личного опыта использования WSL, терминала, а так же бесконечного листания Stack Overflow и Github issues в процессе постоянного усовершенствования конфигов и поиска удобных тулов для работы.
Windows Subsystem for Linux (WSL) 2
В интернете и на Хабре есть несколько нормальных статей про WSL (раз статья про установку/настройку WSL с X-сервером, два заметка про WSL 2, три статья про Python разработку в VSCode с WSL), описывающих установку и настройку системы. Однако не все действия по установке уже актуальны, так же как и ограничений с подводными камнями становится меньше. Я не буду подробно останавливаться на установке, инструкция по установке актуальной (второй) версии WSL есть на сайте Microsoft, также в интернете можно найти краткие туториалы.
Сейчас WSL ещё находится в стадии активной разработки и недавно (июнь 2019) вышла новая версия WSL 2, которая на данный момент доступна только для свежих версий Windows участникам Windows Insiders. При возможности советую сразу проапгрейдить WSL до версии 2, так как в ней улучшили работу системных вызовов, работу с сетью, ФС, и в целом она построена на другой архитектуре и по некоторым данным даёт 20-кратный прирост скорости по сравнению с первой версией.
Установка WSL 2
Для работы WSL требуется включить Hyper-V, потому что дистрибутивы Linux запускаются в легковесных VM с помощью виртуализации Hyper-V.
Далее я приведу краткую инструкция установки из CLI PowerShell дистрибутива WSL на примере Kali Linux). При предпочтении Ubuntu или другого дистрибутива Linux из доступных, заменить ссылку и названия на соответствующие.
Проверить версию билда Windows:
Активировать компоненты VirtualMachinePlatform и Microsoft-Windows-Subsystem-Linux:
Перезагрузка.
Дальше либо установить дистрибутив из Microsoft Store (https://aka.ms/wslstore), либо дальше выполнить в PowerShell:
Запустить консоль WSL (дистрибутив должен был появиться в меню Start, поиск по названию дистра), дождаться приглашения установить нового пользователя, закрыть консоль.
Теперь дистрибутив должен появится в списке, если выполнить в PowerShell:
При необходимости преобразовать дистрибутив в формат WSL версии 2:
Сделать root пользователем по умолчанию (опционально):
Если вы получили ошибку «A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.», значит у вас стоит билд, в котором проявляется очередной (уже исправленный в последних релизах) баг. Как обычно, есть воркэраунд, либо использовать дистрибутив Ubuntu, с ним у меня не было проблем на той же не последней версии билда.
При необходимости, переместить виртуальный диск WSL на другой раздел (отличный от C:) можно по инструкции. Делать это лучше сразу, так как не всё может пройти гладко.
Disclaimer про безопасность. В WSL и на других Linux-серверах в домашней сети я не запускаю никаких критически важных систем, и других пользователей (кроме меня), в сети нет, поэтому я почти везде хожу под root, с ssh аутентификацией через ключи. Я знаю, что это не лучшая практика, однако речь про личное dev-окружение и я не вижу смысла создавать не-root пользователя. Вопросы безопасности в этой статье рассматриваться не будут, об этом я собираюсь когда-нибудь написать отдельно (про то, как в домашней сети без боли организовать взаимодействие сервисов через TLS с централизованным обновлением сертификатов; о синхронизации
/.ssh/config между серверами, пробросе портов и ключей и т.д.).
Конфигурация WSL
Начиная с билда 17093, основной файл конфигурации WSL находится на ФС дистрибутива по адресу /etc/wsl.conf, в нём описываются настройки, которые будут применять при каждой загрузке дистрибутива:
[automount]
enabled = true
root = /mnt
options = «metadata,umask=22,fmask=11»
mountFsTab = true
[network]
generateHosts = true
generateResolvConf = true
[interop]
enabled = true
appendWindowsPath = true
Сделать ребут дистрибутива можно из PowerShell командой:
После этого можно обновить пакеты и заняться настройкой ОС под себя. Я пока не буду касаться настроек шелла и окружения в Linux, оставлю это для следующей статьи.
Файловая система WSL 2 и производительность
Файлы внутри WSL версии 2 хранятся на виртуальном диске VHDX, в качестве файловой системы используется ext4. Получить доступ к rootfs WSL можно через путь такого формата:
В WSL версии 1 не использовался VHDX и был простой доступ к директории, в которой находились файлы Linux, и Microsoft строго не рекомендовали изменять Linux файлы из Windows. В новой версии WSL доступ к ФС на виртуальном диске обеспечивается с помощью файлового сервера Plan 9 Filesystem Protocol.
В предыдущих версиях WSL были проблемы с производительностью файловой системой, потому что системные вызовы эмулировались через API Windows, доступ к файлам был медленный и нестабильный. В концу 2019 года в WSL 2 архитектура поменялась и используется нативное ядро Linux. Судя по слайду из youtube-презентации The new Windows subsystem for Linux architecture: a deep dive, производительность дисковых операций выросла в 2-5 раз.
Максимальный объём диска ограничен 256GB, при превышении этого объёма необходимо будет делать ресайз, инструкция есть в документации.
Изначально, у WSL были проблемы с тем, чтобы высвобождать ресурсы после использования RAM. В билде 19013 эту проблему решили. Если запускать ресурсоёмкие задачи (например, сборка rust приложения) можно заметить, что процесс Vmmem будет в топе Диспетчера задач, однако потребление памяти значительно снизилось в последних версиях WSL.
Имя хоста (hostname) в Linux берётся из имени PC в Windows, независимо от того, что прописать в /etc/hostname или командой hostnamectl set-hostname.
В отличии от первой версии, в WSL 2 сеть работает через виртуальный Hyper-V свитч:
В данном случае сеть 172.27.144.0/20 используется под WSL, её первый адрес (172.27.144.1) — это хостовая система Windows.
Из Linux обращаться по сети к хостовым сервисам (запущенным в Windows) можно, например, так:
IP-адрес Windows тут берётся из /etc/resolv.conf, где он генерируется автоматически согласно настройкам wsl.conf.
Наоборот, если нужен коннект к Linux сокету из приложения Windows, необходимо обращаться к IP-адресу WSL. При этом есть нюанс — в Linux сервис необходимо запускать не на localhost (127.0.0.1), а на адресе 0.0.0.0. Например, чтобы быстро поднять SOCKS5 proxy до своего VPS, нужно запустить SSH с параметром dynamic port forwarding:
После этого в приложении Windows, например Chrome, в качестве адреса SOCKS5 прописать не localhost, а адрес WSL, в данном случае 172.27.150.196. Кстати, таким нехитрым способом туннелирования трафика через VPS в Хроме появляется возможность использовать доступ к сайтам через IPv6.
IP-адрес в Linux после перезагрузки будет каждый раз меняться, так что в сценариях, когда нужно иметь постоянно работающий и автоматически запускающийся port forwarding, нужно искать воркэраунд. Есть много способов решения этой проблемы, разной степени костыльности, почитать подробнее можно в этом issue на github. Я воспользовался утилитой go-wsl2-host, которая реализует Windows Service, добавляющий автоматически IP-адрес WSL в файл hosts Windows, таким образом на хостовой системе можно прописать хостнейм типа ubuntu.wsl и по нему обращаться к Linux. Однако всё это костыли и работает не очень хорошо, остаётся ждать, когда Microsoft пофиксят эти проблемы.
UPD. Пока я писал эту статью, обнаружил, что вышли обновления (билд 18945), в которых появилась возможность достучаться через localhost до сервисов, запущенных в WSL. Правда, оказалось, что есть баг, из-за которого всё равно это не работало у всех, фикс в августовском билде 18970. Так как не всем прилетают обновления, даже если быть участником программы Windows Insiders, я не стал корректировать информацию, может кому-то это поможет настроить сетевое взаимодействие.
OpenSSH в Windows и автозапуск сервисов
Windows 10, как и Windows Server 2019, комплектуется форком OpenSSH, включающем все знакомые утилиты ssh-keygen, ssh-add, scp и другие, а том числе ssh-agent и сам сервер sshd. И клиент, и сервер поставить можно через Apps > Apps and Features > Manage Optional Features, но версия клиента ssh будет не последняя. Я столкнулся с багом, не позволяющим коннектиться к хосту через jump-хост с опцией ProxyJump и оказалось, что эту проблему пофиксили, но нужно вручную обновить SSH клиента. Установить актуальную версию Win32 OpenSSH можно, скачав zip из раздела Releases на гитхабе, и распаковав, к примеру, в C:\Program Files\OpenSSH. Сторонним софтом ssh.exe (например, при использовании Remote Development режима в VSCode) вызывается из $PATH (%SYSTEMROOT%\System32\OpenSSH\), нужно изменить переменную среды. Environment variables изменяются через GUI в Start > Edit the system environment variables (Пуск > Изменение системных переменных среды), там необходимо новый путь поставить выше старой версии.
Я использую SSH-сервер на ноутбуке внутри WSL для того, чтобы удалённо можно было ходить с машины на машину. И, благодаря тому, что я использую техники ssh port forwarding и продуманно настроенный централизованный конфиг SSH клиентов, я могу прозрачно ходить по всем своим серверам, вводя хостнейм вместо адресов. То есть, если даже подключить какой-то из ноутбуков к мобильной сети, autossh демон подключится к jump-хосту и я всё равно смогу зайти на компьютер, никакой NAT не будет помехой. Поэтому мне важно, чтобы sshd всё время был в состоянии up.
Единственный рабочий способ попасть по SSH в WSL — это пробросить порт SSH. Это можно сделать с самого WSL с помощью RemoteForward, либо с другого сервера в домашней сети. Мало лишь кому это надо, да и это уже advanced level, так что просто приведу рабочую команду:
Теперь при коннекте на адрес mt.example.com:2263 можно попасть прямо в WSL.
Если планируется поднимать SSH-сервер в WSL, нужно не забыть сконфигурировать необходимые параметры запуска сервера в /etc/ssh/sshd_config. Чтобы не было конфликта при бинде сервиса на порт 22, OpenSSH сервер в Windows следует отключить или вовсе удалить, если он установлен (Apps > Apps and Features > Manage Optional Features).
X forwarding
Приятным моментом оказалось, что в Windows 10 есть утилита clip.exe, позволяющая перенаправлять stdout напрямую в буфер обмена Windows. Это удобно использовать в таких программах как tmux, а благодаря пробросу X-сервера текст можно копировать и с удалённых хостов. Чтобы всё работало, необходимо иметь всегда запущенный X-сервер в Windows и правильно прописанную переменную $DISPLAY.
Немного скучной теории. На *nix системах с запущенным X имеются разные типы буферов обмена (primary, secondary, clipboard), в контексте этой статьи это не так важно, но важно для общего понимания механизма работы. Для работы с буферами обмена на Linux есть две утилиты (xclip и xsel). Обе утилиты имеют схожий функционал, в xsel его немного больше, но базовый функционал, необходимый для проброса содержимого буфера, одинаков. В X приложениях выделенный текст попадает в primary selection, вставляется при этом средней кнопкой мышки, в xclip и xsel используется по умолчанию primary selection.
Например, чтобы скопировать в буфер по умолчанию содержимое переменной, нужно передать stdout на stdin утилиты xclip, без дополнительных параметров:
А чтобы вывести содержимое буфера по умолчанию, запустить xclip с ключом -o:
Чтобы буфер обмена перенаправлялся через X-сервер и графические приложения запускались на локальном сервере X, необходимо в переменную $DISPLAY прописать IP-адрес, являющийся default gateway для WSL. Пока что ничего лучше того, чтобы брать его из resolv.conf (который генерируется автоматически Windows), не придумали. Поэтому, самый простой способ — прописать экспорт переменной $DISPLAY в профайле шелла (например,
В качестве X-сервера я выбрал бесплатный VcXsrv, он умеет работать с буфером, имеет разные режимы отображения окон и запускается из командной строки с прописанными опциями. По ссылке на gist можно посмотреть все опции.
Создать задачу автозапуска X-сервера можно в Task Scheduler примерно таким образом:
SSH ключи
Чтобы программы из Windows могли использовать SSH ключи (например, редактор при работе с удалённым репозиторием GitHub), и в то же время не было второй копии ключей в WSL, лучше всего сгенерировать ключи в Windows %HOMEPATH%/.ssh и создать симлинки в домашней директории WSL.
/.ssh/config можно прописать параметр IdentityFile, указав путь к ключам на диске Windows:
Host *
IdentityFile /mnt/c/Users/$
Если ключи были скопированы откуда-то и права на файлы не выставлены правильно, поправить permissions:
chmod 600 /mnt/c/Users/$
chmod 644 /mnt/c/Users/$
chmod 700 /mnt/c/Users/$
Таким образом, при дальнейшей настройке доступа по ключам SSH пользователь идентифицируется однозначно одним набором ключей в одном месте, как при использовании приложений Windows, так и Linux. Теперь можно добавить публичный ключ на сервера/сервисы, куда необходимо будет ходить с этого компьютера. Если в домашней сети есть другие устройства, на которые требуется доступ по SSH, то правильно будет скопировать свой публичный ключ на эти сервера (ssh-copy-id), но не надо копировать ключи одного сервера на другой. Так как при работе через SSH можно (и нужно) использовать ssh-agent, то при коннекте с одного сервера на другой, агент заботится, чтобы авторизация происходила по проброшенному ключу. Чтобы всё работало правильно и ожидаемо, нужно позаботиться о файле
/.ssh/config, в котором надо прописать все необходимые опции.
Host *
TCPKeepAlive yes
ServerAliveInterval 30
ServerAliveCountMax 3
ForwardAgent yes
AddKeysToAgent yes
ForwardX11 yes
ForwardX11Trusted yes
Какой терминал выбрать для работы в Linux на Windows
Сначала хочется сделать небольшое ревью существующих терминальных оболочек под Windows, умеющих запускать WSL. Среди пользователей популярен функциональный комбайн MobaXterm, который умеет создавать различные сессии, в том числе графические (WSL, bash/zsh, Mosh, RDP, VNC и т.п.), позволяет делать макросы и запускать скрипты, имеет много настроек и функциональных возможностей, ssh agent, автозапускаемый ssh port forwarding, и даже имеет встроенный сервер ftp/tftp/http, но продукт closed source и, к тому же, платный. Hyper — другой, более современный эмулятор терминала, позволяющий запускать WSL shell, терминал построен на HTML/JS/CSS и расширяется с помощью плагинов в виде node.js модулей (awesome list). Есть и другие терминалы, позволяющие запускать WSL с разной степенью костыльности (ConEmu, его форк Cmder, WSLtty и др.), но их я оставлю без внимания.
Дальше в этой статье речь пойдёт про Windows Terminal, на который я перешёл с недавних пор, и пока что испытываю только положительные эмоции. Terminal пока что ещё в статусе бета, но работает достаточно стабильно. Из фич на данный момент реализован мультитаб, разделение панелей (splitting), настраиваемые профили терминальных подключений, цветовые схемы, ну и больше нечего перечислить. Но этого функционала вполне хватает, мне даже нравится, что софт не перегружен лишним — как будто бы разработчики придерживаются принципа KISS.
Установка и настройка Windows Terminal
Установить Windows Terminal можно из Windows Store, либо скачав бинарник из раздела Releases на гитхабе проекта, там же и вся актуальная информация, инструкции и FAQ. Терминал требует, как минимум, версию Windows 1903 и билд 18362. Предпочтительнее устанавливать через Windows Store, так как обновлять в этом случае проще, прямо из стора. Обновления выходят регулярно, на гитхабе выложен план развития (roadmap) первой версии терминала. На данный момент все фичи версии 1 уже реализованы (по плану до конца 2019 года реализовать все улучшения), дальше несколько месяцев работы над устранениями багов и в апреле 2020 планируется официальный релиз Terminal v1.0. Приятно, что MS теперь есть на гитхабе, их софт научился показывать логи, внятные ошибки и любые проблемы легко гуглятся.
Настроек в терминале пока не много, но их хватает для комфортной работы, продукт активно развивается, есть на github, где пользователи могут создать feature request или bug report. Разработчики принимают участие в обсуждении проблем с пользователями, зачастую предлагая воркэраунды, когда обнаруживается баг.
Конфиг хранится в json формате, после сохранения применяется сразу же. Это удобно хотя бы потому, что можно применять хорошие практики управлением конфигурациями рабочего окружения — все линуксовые конфиги я храню в git репозитории, на Windows из рабочего инструмента использую только VSCode, который умеет синхронизировать конфиг через github gist, а локальный конфиг воркспейса сохранять отдельно в dotfiles. Вот и Terminal движется в ту же сторону, используя те же хоткеи и формат конфига, как VSCode. Править конфиг, кстати, удобно через VSCode, особенно если уже пользуетесь этим отличным редактором от MS. Файл конфигурации терминала уже содержит многие дефолтные настройки, а правильный редактор позволяет посмотреть все опции с описанием key и вариантами value из schema (особенно это удобно, когда у проекта ещё нет полноценной документации). Плюсом доступны все фишечки IDE в виде автодополнения, intellisense, проверкой синтаксиса, форматированием и т.д.
Документация для разработчиков доступна тут, а здесь пока что небольшая страничка документации для пользователей. Отдельная страница посвящена настройкам, которые прописываются в json файле конфигурации. Оттуда можно узнать, что структурно настройки делятся на:
Шрифты
Чтобы терминал по-настоящему радовал пользователя, обязательно надо инсталлировать шрифты с поддержкой спец символов и лигатур. Выбрать можно из:
Устанавливается шрифт в Windows с помощью установщика шрифтов ОС. Для этого надо скачать последнюю версию понравившегося шрифта с github releases архивом и вручную установить шрифт в системе.
Заключение
Получилась очень объёмная статья, в одном месте собрана вся актуальная информация по установке, настройке и использованию Windows Terminal совместно с WSL. В дальнейшем я хочу так же оформить статьёй заметки о ZSH и tmux, и расписать свой опыт деплоя конфигураций на VM и синхронизации dotfiles между хостами. Всё в рамках автоматизации домашней сети, но это будет полезно и для разработчиков / девопсов / системных инженеров. Ещё из нераскрытых тем остался запуск Docker в WSL 2, но у меня нет необходимости запускать докер на персональном компьютере, так как для этого есть выделенный сервер.
Я надеюсь, что никто не пожалел, что дочитал статью и вынес для себя какие-то новые знания. Если кому-то есть, что добавить, давайте делиться мыслями в комментариях. Если есть какие-то замечания по тексту, пишите в ЛС, хочется поддерживать этот гайд в актуальности.