Терминал kali linux на windows 10

Windows new terminal is rocking and switching between the powershell/bash is made easy than ever. Installation of new windows terminal can be done by following their GitHub link: https://github.com/microsoft/terminal . Adding the Kali linux to the wsl is done using windows store. Follow the document to add kali to windows subsystem library: https://www.kali.org/news/kali-linux-in-the-windows-app-store/.

Scenario:

As a penetration tester we always wanted kali linux in windows machine. Always installing kali in the virtualbox is not the optimal solution. If kali is also available in windows store then why anyone should waste time in installing kali in virtual machine. By using this new windows terminal one can add kali to the terminal and can switch between windows powershell and kali terminal like ever before.

Step1:
Install Windows terminal and Kali wsl using the above links.
Step2:
Before changing the settings of terminal we need uuid of kali linux instance.
Enter the following commands in powershell to get values from registry.

(Get-ChildItem -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\PackageFamily\Data | findstr.exe "Kali").Substring(0,2).Trim()

Take the output of the command and put it the next command. In my case the output is «6f»

Get-ChildItem -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository\Cache\PackageFamily\Data | where {$_.Name -match "6f" }

Step3:
Note down the Publisher value(Without «CN=«) from the output of the above command. This is the value we insert for our guid.

Step4:
Open terminal settings by accessing options in the right pane.

Step5:
Settings file is opened in your favorite editor and insert the values like below after ubuntu record

        {
            "acrylicOpacity" : 0.5,
            "closeOnExit" : true,
            "colorScheme" : "Campbell",
            "commandline" : "wsl.exe -d kali-linux",
            "cursorColor" : "#FFFFFF",
            "cursorShape" : "bar",
            "fontFace" : "Consolas",
            "fontSize" : 10,
            "guid" : "{**guid value**}",
            "historySize" : 9001,
            "icon" : "**Your Png logo**",
            "name" : "Kali-Linux",
            "padding" : "0, 0, 0, 0",
            "snapOnInput" : true,
            "useAcrylic" : false
        }

My settings file for the reference: https://pastebin.com/C08wW1xs

Step6:
Finally access the kali terminal side by side with windows powershell.

This could help security professionals who are using windows operating system to switch kali with a single tab key.

Last update: June 3, 2020

Источник

Есть люди, которые большинство рабочего времени проводят в консоли, есть те, кто пользуются терминалом при необходимости, запуская что-то по инструкциям. Но я думаю, что каждый айтишник, будь он разработчиком, сисадмином, сетевым инженером, или даже 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-кратный прирост скорости по сравнению с первой версией.

Посмотреть версию Windows 10 и OS build можно в Start -> Settings ->System -> About, для установки WSL 2 требуется версия Windows 1903 и, как минимум, версия билда 18917. Если вы не участник Windows Insider Program, вероятнее всего, обновления не прилетят до выхода стабильного релиза. Так что если хочется обновиться до последней сборки, можно включить ранний доступ (Fast) в Start -> Settings -> Update & Security -> Windows Insider Program, обновиться и отключить дальнейшие обновления. Стоит учитывать, что устанавливаться будут ещё не оттестированные массово обновления, что может сказаться на стабильности.

Стоит иметь ввиду, что до билда версии 18995 WSL имеет баг при работе с файлами на примонтированных дисках Windows, выражающийся в Input/output error, помогает только перезагрузка WSL (wsl —shutdown в PowerShell). В целом сейчас пофиксено много багов, которые до сих пор присутствуют в WSL версии 1 (который ставится по дефолту) и не-preview дистрибутивах Windows. Если у вас обновления ОС регулируются корпоративными политиками, скорее всего самые свежие обновления прилетать не будут и нужно иметь это ввиду. На одном из ноутбуков у меня стоит билд 18956 и обновлений нет, не смотря на то, что выбрана опция Fast в настройках Insider Program. На другом ноутбуке была установлена чистая система несколько месяцев назад и обновления периодически прилетают и устанавливаются.

Установка WSL 2

Для работы WSL требуется включить Hyper-V, потому что дистрибутивы Linux запускаются в легковесных VM с помощью виртуализации Hyper-V.

Далее я приведу краткую инструкция установки из CLI PowerShell дистрибутива WSL на примере Kali Linux). При предпочтении Ubuntu или другого дистрибутива Linux из доступных, заменить ссылку и названия на соответствующие.

Проверить версию билда Windows:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select CurrentBuild

Активировать компоненты VirtualMachinePlatform и Microsoft-Windows-Subsystem-Linux:

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

Перезагрузка.
Дальше либо установить дистрибутив из Microsoft Store (https://aka.ms/wslstore), либо дальше выполнить в PowerShell:

curl.exe -L -o kali.appx https://aka.ms/wsl-kali-linux-new Add-AppxPackage .\kali.appx rm .\kali.appx

Запустить консоль WSL (дистрибутив должен был появиться в меню Start, поиск по названию дистра), дождаться приглашения установить нового пользователя, закрыть консоль.

Теперь дистрибутив должен появится в списке, если выполнить в PowerShell:

wsl -l -v

При необходимости преобразовать дистрибутив в формат WSL версии 2:

wsl --set-version kali-linux 2 wsl --set-default-version 2

Сделать root пользователем по умолчанию (опционально):

kali config --default-user 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 — автомонтирование дисков Windows
Network — генерировать файлы resolv.conf, hosts
Interop — запуск процессов Windows и добавление Windows $PATH в Linux $PATH

Изначально WSL идёт без этого конфига, его нужно прописать вручную:

[automount] enabled = true root = /mnt options = "metadata,umask=22,fmask=11" mountFsTab = true


[network]

generateHosts = true

generateResolvConf = true
[interop]

enabled = true

appendWindowsPath = true

Некоторые настойки применяются со значением по умолчанию и с пустым /etc/wsl.conf , но для корректной работы с файлами нужно прописать как минимум параметр options, иначе файлы Windows будут с правами 777 и это нельзя будет изменить из Linux.

Сделать ребут дистрибутива можно из PowerShell командой:

wsl -t kali-linux

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

apt -y update && apt -y upgrade

Файловая система WSL 2 и производительность

Файлы внутри WSL версии 2 хранятся на виртуальном диске VHDX, в качестве файловой системы используется ext4. Получить доступ к rootfs WSL можно через путь такого формата:

\\wsl$\{DistroName}\

Либо, можно набрать «explorer.exe .» в CLI и откроется обозреватель Windows в текущей директории.

В 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 свитч:

❯❯ ipconfig.exe | grep IPv4 IPv4 Address. . . . . . . . . . . : 192.168.88.200 IPv4 Address. . . . . . . . . . . : 172.31.160.1 IPv4 Address. . . . . . . . . . . : 172.27.144.1


❯❯ ip -br -4 ad show dev eth0

eth0             UP 172.27.150.196/20

❯❯ ip ro list default

default via 172.27.144.1 dev eth0

В данном случае сеть 172.27.144.0/20 используется под WSL, её первый адрес (172.27.144.1) — это хостовая система Windows.

Из Linux обращаться по сети к хостовым сервисам (запущенным в Windows) можно, например, так:

❯❯ nmap -p 3389 $(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')

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:

❯❯ ssh -D 0.0.0.0:2299 -N -f proxy.example.com

После этого в приложении 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 (Пуск > Изменение системных переменных среды), там необходимо новый путь поставить выше старой версии.

Так как в WSL не работает Systemd, есть проблема с автозапуском сервисов со стартом системы. Есть несколько способов настроить автостарт ssh сервера в WSL, самый простой — это создать задачу в Task Scheduler, где прописать команду старта сервера. В интернете можно найти разные инструкцииавтозапуска через скрипты vbs, ps1 или bat. Проблема почти всех способов в том, что триггером является запуск основной ОС Windows, то есть, если произойдёт сбой WSL и придётся перезапускать систему (wsl -t), то Linux запустится без запущенного сервиса. При старте Windows дистрибутив WSL запускается только в момент первого обращения к нему.

Я использую SSH-сервер на ноутбуке внутри WSL для того, чтобы удалённо можно было ходить с машины на машину. И, благодаря тому, что я использую техники ssh port forwarding и продуманно настроенный централизованный конфиг SSH клиентов, я могу прозрачно ходить по всем своим серверам, вводя хостнейм вместо адресов. То есть, если даже подключить какой-то из ноутбуков к мобильной сети, autossh демон подключится к jump-хосту и я всё равно смогу зайти на компьютер, никакой NAT не будет помехой. Поэтому мне важно, чтобы sshd всё время был в состоянии up.

Единственный рабочий способ попасть по SSH в WSL — это пробросить порт SSH. Это можно сделать с самого WSL с помощью RemoteForward, либо с другого сервера в домашней сети. Мало лишь кому это надо, да и это уже advanced level, так что просто приведу рабочую команду:

❯❯ ssh -R '*:2363:*:22' -N -f mt.example.com

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

❯❯ echo -n $DISPLAY | xclip

А чтобы вывести содержимое буфера по умолчанию, запустить xclip с ключом -o:

❯❯ xclip -o 172.20.160.1:0

Чтобы буфер обмена перенаправлялся через X-сервер и графические приложения запускались на локальном сервере X, необходимо в переменную $DISPLAY прописать IP-адрес, являющийся default gateway для WSL. Пока что ничего лучше того, чтобы брать его из resolv.conf (который генерируется автоматически Windows), не придумали. Поэтому, самый простой способ — прописать экспорт переменной $DISPLAY в профайле шелла (например, ~/.zshrc для zsh).

❯❯ echo "export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0" >> ~/.zshrc

В качестве X-сервера я выбрал бесплатный VcXsrv, он умеет работать с буфером, имеет разные режимы отображения окон и запускается из командной строки с прописанными опциями. По ссылке на gist можно посмотреть все опции.

Создать задачу автозапуска X-сервера можно в Task Scheduler примерно таким образом:

Triggers: At startup Actions: Start a program ____Program: "%ProgramFiles%\VcXsrv\vcxsrv.exe" ____Arguments: -wgl -dpi auto -ac -multiwindow

SSH ключи

Чтобы программы из Windows могли использовать SSH ключи (например, редактор при работе с удалённым репозиторием GitHub), и в то же время не было второй копии ключей в WSL, лучше всего сгенерировать ключи в Windows %HOMEPATH%/.ssh и создать симлинки в домашней директории WSL.

ssh-keygen -f /mnt/c/Users/${WIN_USER}/.ssh/id_rsa -b 4096 ln -sf /mnt/c/Users/${WIN_USER}/.ssh/id_rsa ${HOME}/.ssh/id_rsa ln -sf /mnt/c/Users/${WIN_USER}/.ssh/id_rsa.pub ${HOME}/.ssh/id_rsa.pub

Либо, в ~/.ssh/config можно прописать параметр IdentityFile, указав путь к ключам на диске Windows:

Host * IdentityFile /mnt/c/Users/${WIN_USER}/.ssh/id_rsa

Если ключи были скопированы откуда-то и права на файлы не выставлены правильно, поправить permissions:

chmod 600 /mnt/c/Users/${WIN_USER}/.ssh/id_rsa chmod 644 /mnt/c/Users/${WIN_USER}/.ssh/id_rsa.pub chmod 700 /mnt/c/Users/${WIN_USER}/.ssh

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

Terminal эволюционировал из проекта Windows Console (ConPTY), научившись поддерживать ANSI/VT последовательности, 24-bit RGB true color и UTF-8. По ссылкам (начало, продолжение) на Хабре замечательный перевод серии постов блога Windows Command-Line: Inside the Windows Console, где рассказывается про историю создания терминалов, связанные с этим стандарты передачи управляющих последовательностей, кодовые страницы, юникод, появление эмуляторов терминалов и в дальнейшем уже эволюцию командной строки Windows. Техногикам это может быть интересно. Инженерный состав, работающий над этим opensource проектом, ведёт девблог Windows Command Line, который более, чем полностью посвящён WSL и Windows Terminal. Никогда бы до этого момента не поверил бы, что буду с интересом наблюдать за развитием продуктов MS, но что они делают в рамках развития WSL, Terminal и VSCode, действительно заслуживает уважения. Как начиналось развитие WSL, описано в Microsoft Open Source Stories (перевод есть на Хабре). Кстати, Microsoft с 2016 года является платиновым участником Linux Foundation .

Установка и настройка 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 файле конфигурации. Оттуда можно узнать, что структурно настройки делятся на:

Global (профиль по умолчанию, изначальный размер окна терминала, тема и т.д.)
Key Bindings (настройки сочетаний клавиш)
Profiles (настройки, специфичные для каждого терминала)
Schemes (цветовые схемы)

Есть такое понятие, как динамические профили, они появляются в конфиге автоматически и имеют свойство source. Это касается дистрибутивов WSL и Azure Cloud Shell. Чтобы создать дубликат профиля одного и того же дистрибутива WSL (например, Ubuntu), необходимо сгенерировать GUID и прописать все желаемые настройки, кроме source, а в качестве commandline прописать wsl -d {DistroName}.

Шрифты

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

Fira Code
Hack
любые другие патченые шрифты

Я использую программерский шрифт Fira Code как в терминале, так и в редакторе. Им поддерживаются большинство символов, используемых в в оформлении CLI программ и консольных интерфейсов, лигатуры, а также нет никаких проблем с отображением эмодзи в терминале.

Устанавливается шрифт в Windows с помощью установщика шрифтов ОС. Для этого надо скачать последнюю версию понравившегося шрифта с github releases архивом и вручную установить шрифт в системе.

Посмотреть название шрифта (настройка терминала fontFace) можно при установке или после в приложении Character Map (Таблица Символов). Кроме этого, в Start -> Settings -> Personalization -> Fonts можно посмотреть, как шрифт рендерится в разных режимах, и заодно проверить, как рисуются лигатуры.

Заключение

Получилась очень объёмная статья, в одном месте собрана вся актуальная информация по установке, настройке и использованию Windows Terminal совместно с WSL. В дальнейшем я хочу так же оформить статьёй заметки о ZSH и tmux, и расписать свой опыт деплоя конфигураций на VM и синхронизации dotfiles между хостами. Всё в рамках автоматизации домашней сети, но это будет полезно и для разработчиков / девопсов / системных инженеров. Ещё из нераскрытых тем остался запуск Docker в WSL 2, но у меня нет необходимости запускать докер на персональном компьютере, так как для этого есть выделенный сервер.

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

References

Announcing WSL 2 (devblogs.microsoft.com)
WSL 2 is now available in Windows Insiders (devblogs.microsoft.com)
Memory Reclaim in the Windows Subsystem for Linux 2 (devblogs.microsoft.com)
Automatically Configuring WSL (devblogs.microsoft.com)
wsl2-tutorial (github.com)
Terminal v1.0 Roadmap (github.com)
Editing Windows Terminal JSON Settings (github.com)

Источник

Voulez-vous utiliser les applications de piratage Kali Linux sous Windows 11 ou 10 ?

Parmi les meilleures fonctionnalités qu’implémenté Microsoft dans Windows on trouve WSL (Windows Subsystem for Linux) ou le Sous-système Windows pour Linux car il permet aux développeurs et utilisateurs avancés d’exécuter les commandes linux de plusieurs distributions tout en gardant la puissance de Windows.

Windows 11 a connu de nombreux changements y compris l’introduction de WSL 2 qui est beaucoup plus rapide et permet d’utiliser les applications GUI de linux sur Windows.

Dans ce tutoriel, vous allez découvrir comment installer la distribution Kali Linux qui est utilisée principalement dans la sécurité informatique et le piratage en général.

Installer Kali Linux sur Windows 11 et 10 (WSL)

Premièrement on doit activer la fonctionnalité WSL sur Windows. Pour ce faire ouvrez Exécuter à l’aide de Win+R puis lancez la commande suivante :

optionalfeatures

Cochez «Sous-système Windows pour Linux» puis cliquez sur «OK«

Redémarrez votre PC.

Ouvrez une nouvelle session de Windows Terminal, CMD ou PowerShell puis exécutez la commande suivante :

wsl --set-default-version 1

Ouvrez Microsoft Store à partir du menu Démarrer.

Cherchez «Kali Linux» puis installez-le…

Pour l’installer il suffit de cliquer sur «Obtenir» puis sur «Installer«

Cette version de Kali Linux est minimale donc si vous voulez utiliser des fonctionnalités alors que vous ne les trouvez pas, il faut les installer…

Une fois installé lancez «Kali Linux» à partir du menu Démarrer.

Mettez un nom d’utilisateur et un mot de passe… et le tour est joué ! (pour le mot de passe rien ne va s’afficher)

Vous pouvez désormais utiliser Kali Linux à partir du menu déroulant de Windows Terminal.

kali linux windows terminal animation

Si vous avez des questions n’hésitez pas à laisser un commentaire

Au prochain tutoriel, je vous souhaite bon courage avec Kali Linux

Par

Источник

Setup Kali Linux in Windows 10 WSL2

Table of Contents

This article will explain how you can install Kali Linux directly inside your Windows 10 without having to run the Kali setup. This will save you a lot of time that is required to setup a Kali VM in Windows and you won’t have to go through fixing the errors which can encounter during Kali installation.

Install WSL2 in Windows 10

This article assumes you have already installed WSL2 in your Windows 10. The more information about WSL2 and its installation steps are covered in following article:

Windows Subsystem for Linux (WSL)

If you have not installed WSL2, please check this article first and then come back here to start setting up your Kali Linux environment.

Install Kali Linux

To install Kali Linux (or any other GNU/Linux distribution), open Run dialog (Windows key + R), then type “ms-windows-store:” without quotes and hit enter. This will launch Microsoft Store app.
Click on the search, type “Linux” and hit enter. You will see all the popular Linux apps.

1. Select Kali Linux and click on Install (or Get) button. If it asks you to login with Microsoft account, just click on No, thanks. This will start downloading and installing the Kali Linux which could take a while.

To launch the Kali linux, click on start and type “Kali” to search.

Tip: The most recently installed app “Kali Linux” will probably be displayed on top of start menu.

Click on “Kali Linux” and it will display a terminal window with a text “Installing, this may take a few minutes”. This will happen only for the first time.

1. Once done, you will be asked to type a user name and then set a password. After typing password twice, you will be logged in to your Kali Linux environment. This is just a minimal installation of Kali linux. In the next step, we will convert the minimal installation to full including GUI and tools.

1. The good thing is that your Windows C: drive is automatically mounted to /mnt/c directory in Kali linux. So you can browse and seamlessly transfer the files across Windows and Kali. Take a look at the following image:

Now that we have a mimimal Kali install running in a terminal. We can run commands in terminal to convert it into full GUI. The sudo apt update && sudo apt install kali-desktop-xfce -y command will do that. But instead of installing XFCE desktop environment, we will install Kali Desktop Experience for Windows (aka Win-KeX).

Now why would we install Win-KeX instead of XFCE which is default desktop environment for Kali Linux? Because “Win-KeX” offers a Kali Desktop Experience for WSL2 which is tightly integrated with Windows. It provides following features:
- Window Mode: Starts a Kali Linux desktop in a dedicated window
- Seamless Mode: Share the Windows desktop between Windows and Kali apps
- Shared clipboard: Allows copy/paste between Windows and Kali Linux apps
- Multi-session support: Supports Root and regular user sessions
- Sound support
Leave the terminal window open and proceed to the next step in order to install Win-KeX.

Install Win-KeX in Kali Linux

Type the following commands in terminal and hit enter. When prompted, enter the password you set in Step 5.
```
sudo apt update -y && sudo apt install kali-win-kex -y
```
It could take a while depending upon the speed of your computer and internet connection. Wait for installation to finish.

Run Win-KeX in Kali Linux

WSL2 allows you to run Win-KeX in three modes.

Window Mode: Window mode helps keeping the Windows and Kali environments visually apart. Kali linux will run in a dedicated window. To start Win-KeX in Window mode with sound support, type the following command in terminal and hit enter:
```
win-kex --win -s
```
Enhanced Session Mode (ARM only): Enhanced Session Mode runs the Kali Linux desktop session in a separate window using protocols and clients native to Windows. This is supported on ARM devices only. To start Win-KeX in Enhanced Session Mode with sound support, type the following command and hit enter:
```
win-kex --esm --ip -s
```
Seamless mode: Seamless Mode runs a Kali Linux panel on the screen top of the Windows desktop. It removes the visual segregation between linux and window apps which provides a great platform to run a penetration tests in Kali Linux and copy the results straight into a Windows app. To start Win-KeX in Seamless mode with sound support, type the following command and hit enter:
```
win-kex --sl -s
```

Now you know How to run Kali Linux in WSL2 without having to install and maintain a VM in VirtualBox or Hyerp-V. But wait a minute; When you want to start Kali Linux, you will have to repeat following two steps every time:

Open cmd.exe (or PowerShell console) in Windows and then type wsl -d kali-linux command
And then type win-kex --sl -s command to run WinKex in seamless mode

If you don’t want to repeat these steps every time, proceed to the next step of this article.

Install Windows Terminal

Open Run dialog (Windows key + R), then type “ms-windows-store:” without quotes and hit enter. This will launch Microsoft Store app.
Click on the search, type “Windows Terminal” and hit enter.

1. Click on Windows Terminal app from search results and click on Install (or Get) button. If it asks you to login with Microsoft account, just click on No, thanks. This will start downloading and installing the Windows Terminal app.

We will now create a shortcut in Windows Terminal which will help us start the Kali Linux automatically in just a single click.
Now launch Windows Terminal app and press “Ctrl + ,” keys simultaneously to open terminal settings. It will open “settings.json” file in “Code Writer” app so don’t freak out.

1. In settings.json file, look for the lines marked with Red box in image, copy the marked section and then paste it right below (as marked by the Green box)

Look at the “commandline” argument’s value. This is the actual command which will run Kali Linux in seamless mode when you click on Windows Terminal shortcut. You can download the kali icon from here.

If you want to run Kali in Window mode, set the “commandline” value to wsl -d kali-linux kex --wtstart -s . You must slightly change the “guid” value marked with Blue underline otherwise you won’t see the new shortcut in Windows Terminal. You can also change other values if you like and then save the file.

1. Now close the Windows Terminal and launch it again. Then click on the dropdown icon and choose the Kali Win-KeX option to launch it.

1. This will launch Kali Win-KeX in seamless mode and you will see a new window running Kali desktop.

That’s it. Now you’re running Kali Linux in Windows 10 in seamless mode where you can change through apps opened in Windows as well as Kali Linux by pressing “Alt + Tab ” or “ Windows logo + Tab ” keys.

If you want to close the Kali window, just close the Kali Win-KeX tab in Windows Terminal.

Tip: Closing the Kali Win-KeX tab in Windows Terminal doesn’t actually terminate the “kali-linux” WSL distribution. You can run wsl -l -v command in cmd.exe or PowerShell console and you will still see it Running.

To terminate the WSL instance, you need to run wsl -t kali-linux command manually as shown in image below.

Fixing Errors in Kali Linux

If you see a message saying Started Win-KeX SL on Windows Terminal but don’t see any Window for Kali Linux, it is most likely that your Windows Firewall or Antivirus Firewall is blocking the application. You need to add the following application to trusted apps list in your Firewall.
```
\\wsl$\kali-linux\usr\lib\win-kex\VcXsrv\vcxsrv.exe
```
If you see an error like Failed to execute child process “dbus-launch” (No such file or directory). You need to connect to Kali linux by running “wsl -d kali-linux” command in cmd.exe (or PowerShell console) and then execute the following commands:
```
sudo service xrdp stop
sudo apt-get install dbus-x11
sudo service xrdp start
```

Источник

WSL2 is a great option if you don’t want to completely setup your Linux machine and just want to use Linux on Windows without having to deal with dual-booting or virtual machines.

No matter if you are a security professional or are pursuing cybersecurity, you have probably heard about WSL2, which is commonly used as an alternative to VirtualBox & VMware.

But if you’re not sure how to get started with WSL2, then you are at the right place, where I will show you how to install the Windows Subsystem for Linux (WSL2) on Windows 10 with Kali Linux.

So let’s roll up our sleeves and get started with the first task of installing WSL on your Windows, and then we will show you how you can install Kali Linux on Windows 10 and 11.

Before jumping to the installation part, first understand What is the WSL? In layman’s terms, a WSL, or Window Subsystem Linux, allows users to use GNU/Linux distributions alongside Windows as their default system.

At present, WSL has two versions: WSL1 and WSL2, but it’s good to have the latest version of WSL on your Windows machine.

And here is the comparison between WSL1 and WSL2, in that you can clearly see that WSL2 is a significant improvement over WSL1 in terms of performance, compatibility, and functionality.

Comparison between WSL1 and WSL2

Not only that, after installing wsl2, you can access most of the Linux command-line tools like awk, sed, grep, and many other utilities directly on Windows without switching to Dual-Boot or using virtualization technology like VMware or VirtualBox.

Benefits of Using WSL2

No need to use VirtualBox
Download the GNU/Linux Distribution directly from Microsoft Store.
Run the native Linux command-line utilities awk, sed, grep, and the vi command line editor on Windows.
Use both Windows and Linux in parallel

There are many other advantages to using WSL2, but there are some minor limitations, too, like the fact that I/O file transfer is slow compared to native environment.

Install WSL2 on Windows 10

Now the fun part begins, where you learn how to install WSL2 on Windows 10 by two different methods, one of which is as simple as running one command and WSL is ready for use, and another one is quite intensive.

I would recommend you to go with the first method, if it’s not working for you then move the second.

Install WSL2 on latest build of Windows 10/11
Install WSL2 on older build of Windows 10

Install WSL2 on latest build of Windows 10/11

One of the easiest ways to install WSL2 on the latest build of Windows 10/11 is by running one line of command, which will install the WSL.

But for that, you need to be on the latest build, and to verify, run the following command on your system command prompt or PowerShell:

winver

Once you run the above command, it will show the system build version. If the build version is 2004 or higher, then you can follow this method, and if not, then read these steps.

The output of the above confirmed that my system is eligible for installing WSL2 with the following method:

Type command winver to check current window version

If your system build version is 2004 or higher, then run the next line of command into PowerShell or a command prompt with administrator privileges.

wsl --install

Once you have run the above command, it will make the necessary changes and install the Ubuntu distribution on it.

After completion of the above step, click here to install Kali Linux on Windows 10 or 11.

Install WSL2 on older build of Windows 10

Due to some reason, if you are not on the latest build of Windows 10, then you can follow this method to install WSL2 on your computer by first checking the minimum version that should be available (like 1903 or later, with Build 18362 or later) to install

Step 1: Check the Latest Version of Windows

If you are unsure which version of Windows 10 you are using, type the following command on the “command prompt” or in the “Run” box.

Type command winver to check current window version

In case your window version does not match the requirement, then update the window version.

To update Windows to the latest version Press the Start or Window key + I to launch the settings menu, click on Update and Security, then click on Check for updates.

Click on Check for updates

or directly click this link to open Windows Update Settings and click on Check for updates.

Download the update for your system, and then restart your computer to make sure the update is fully installed.

If you are not able to see the latest window version despite the old version, then my advice is that you should restart your PC or check the service status of “Window Update Service” from the Services.

Step 2: Enable WSL2 on Windows

After completing the above step, you now have to enable WSL2 in your system.

To enable WSL2, press the Windows Start key and search for Powershell, click on Run as Administrator, and when it prompt click on allow.

Run Windows PowerShell as Adminstrator

or else you can use the shortcut Window Key + X and open Command Prompt as administrator .

To enable WSL2, type or copy-paste the following command on Windows PowerShell:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Enable to WSL2

It’s not necessary to restart your system; then also restart your system to avoid any package clashes.

Step 3: Set WSL version to WSL2

After restarting your system, open PowerShell as administrator and pass the following command to set the WSL to version WSL2.

wsl --set-default-version 2

Set Default version of WSL2

That’s it, your work is done; now you will see how to install Kali Linux on your Windows computer.

Install and Run Kali Linux on WSL2

We were able to enable WSL2 on the Windows system, and now we will install Kali Linux on WSL.

To install Open Microsoft Store, press the Start Key and search for “Microsoft Store” or simply click the below button to open the store.

On the right side corner, you will able to see the search bar. Type “Kali Linux” and download the file.

The file size is approximately 276 MB, and it will take some time to download on your system as per your internet speed.

Kali Linux is Downloading from Microsoft Store

Run Kali Linux

When the download is finished, click on Launch or press the window key and search for Kali Linux.

Search Kali Linux

Initially, it will ask you to set a “username” andpassword,” so please enter the username, password, and confirm password.

Enter your login details

Now you will able to use Kali Linux on WSL.

Kali is successfully Installed

Troubleshooting

If you are not able to install Kali Linux from the Microsoft Store and you’re getting the error “0x80073D05” like below the screen:

error “0x80073D05”

To resolve this issue, it is advisable to restart your device and try again to reinstall Kali Linux.

If you are not able to install Kali Linux and getting the WslRegisterDistribution failed with error 0x8007019e.

To resolve this issue Open the Run box and type appwiz.cpl . On the left side of the screen, you will find the option “Turn Windows features on or off,” so please click on that.

Click on Turn Windows fetures on or off

Now scroll down below and you will see the Windows Subsystem for Linux, so please check that option and wait for a few seconds to apply the settings.

Check Windows Subsystem for Linux

Next, restart your system and run Kali Linux from the start menu.

There is another kind of error that causes WSL 2 to won’t run Ubuntu and throw the error 0x80370102. If you are getting this error, then you need to run the following command to enable Hypervisor:

bcdedit /set hypervisorlaunchtype auto

If you are facing any other issue, then check this guide for complete troubleshooting steps for WSL.

Wrap up

That’s all for this article, where you learned how to install WSL on Windows 10 and 11 with Kali Linux, but I have not included the steps to enable the GUI interface here.

If you want to learn how to install or enable a GUI for Kali-Linux using Win-Kex, then click here.

And with that message, let me end this article here.

profile

A man with a tech effusive who has explored some of the amazing technology stuff and is exploring more. While moving towards, I had a chance to work on Android development, Linux, AWS, and DevOps with several open-source tools.

Источник