Fall Creators Update で OpenSSH が標準搭載に(ただしBeta)

ふと、Windows10 の設定アプリにて、「アプリと機能」の「オプション機能の管理」から、「機能の追加」を見たところ、OpenSSH のサーバとクライアントを Windows10 のオプションとして導入できるようになっていた。

以前よりマイクロソフトは Windows 向けに OpenSSH の移植を行っていたが、どうやらこれがとうとうOS側に搭載されるようになったようだ。まだβ版で以下に述べるように少々問題があるが、エスケープシーケンスが強化されてきているコマンドプロンプトウィンドウとあわせることで、TeraTerm や Putty といったターミナルエミュレータ抜きで SSH によるリモートアクセスが可能になる点は歓迎したい。

せっかくなので OpenSSH Client の方をインストールしてみた。モジュールは %SYSTEMROOT%\System32\OpenSSH 以下にインストールされる。システム環境設定のPATHにも設定されるのだが、これは次にサインインするセッションから有効なため、インストールを行ったそのセッションではパスが設定されないことに注意。インストールが終わったら一度サインアウト/サインインをしなおすようにしよう。

たまたま macOS Sierra で sshd が動いているのでこちらに接続してみた。パスワードを用いた場合はあっさりとログインできた。

\Users\<アカウント名>直下に .ssh フォルダを作成、config ファイルを作成する事で ssh クライアントの設定を行う事もできる。

しかし、ssh-keygen を用いて鍵を作成しようとしたところ、RSA, DSA などはそもそも作成できず、ed25519 については作成できているものの、id_ed25519 ファイルの作成で失敗する。おそらく、\ と / が混在したパスがデフォルトで指定されているために見受けられる。

では、と id_ed25519 ファイルのパスを手入力してみたところ、/ だとパスの区切りとして認識できないのか失敗し、\ は「￥￥」にエスケープされてしまい、これまた失敗してしまう。今のところ、ssh-keygen でキーの作成には成功していない。

それでは、とこれまで使っていた TeraTerm を使って公開鍵と秘密鍵を作成、macOS 側の ~/.ssh/authorized_keys に公開鍵を登録してみた。TeraTerm  でこの公開鍵と暗号鍵でパスフレーズによる認証ができた事を確認した後、今回の ssh コマンドでも試してみた。

結果がこれである。

ssh コマンドも id_ed22519 ファイルが読めていないように見受けられる。これもパスの問題の模様だ。この事から、公開鍵による認証は現時点ではできないと言える。



また、ESXi にサインインしようとしたところ、暗号化方式が合致せずサインインできなかった。

この ESXi は 6.5.0 build-4887370 なのだが、/etc/ssh/sshd_config では以下の暗号化およびメッセージ認証符号が以下に設定されている。

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbcMACs hmac-sha2-256,hmac-sha2-512,hmac-sha1

...正直、これは少々後ろ向きというかトラッディショナルというかいまどきな設定に見受けられる。なお、macOS Sierra での sshd の設定では Ciphers も MACs も特に設定されていないが、デフォルトで以下のように設定されている。

macOS Sierra と Windows10 の ssh でそれぞれのバージョン、対応している暗号(Cipher)およびメッセージ認証符号(MAC)を出力させたが、バージョンは 7.4p1 と 7.5p1 でほぼ同じだが、対応している Cipher と MAC が段違いである事が分かった。

しかも、この出力が正しいなら ESXi とは Cipher: aes256-ctr, MAC:hmac-sha2-256 あたりでネゴシエーションしそうなのだが、どうも記載されている全ての Cipher,MACが使えるわけでもないようだ。

公開鍵による認証ができない、Cipher,MAC が今風のしかない事から接続先が限られるなど、現時点では諸々問題がありこれ一個で、とはいかない。他の SSH クライアントは用意しておくべきだろう。とはいえまだβ版だ。そのうちこれらの問題は解決していくだろう。


コマンドとしての動作は十分に軽快で、OS標準で提供され、サードパーティーのアプリを入れなくて良いという点では評価ができるかと思われる。

Pico process

とある事情で少々調べたので、ここにメモしておく。

だいたいの元ネタは、以下のページになります。
https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/


● PE と ELF

Windows は Portable Executable (PE)という実行ファイル形式をサポートしている。逆に言えば、PE形式のバイナリしか起動させることができない。NT系の Windows では、環境サブシステム(Environment Subsystem) という名前のパーソナリティを、NT Executive というマイクロカーネル上に複数実装できるようになっており、実際に OS/2, POSIX, Interix などのサブシステムが存在した。

しかし、実はこれらの、Win32とは異なるサブシステム上のバイナリも、実質的に PE形式のバイナリ(OS/2については変種だが)を実行するものであった。Service for UNIX の UNIXコマンドも PE形式だったわけだ。

一方、Linux は ELF形式のバイナリを実行するようになっている。

Windows Service for Linux (WSL) が Ubuntu のバイナリを無変更で実行していると言うことは、とりもなおさず ELF形式の、本来実行できないバイナリを実行していることになる。

これはどうやって実現しているのだろうか?

● pico process

WSL のキモが、この pico process を使った ELF バイナリの実行だ。
pico process というものは Microsoft Research で開発された Drawbridge より持ち込まれた、より軽量なプロセスを指す。下図の右側が通常の Windows でのアプリケーションプロセスだ。

https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/  より抜粋

Windows のカーネルは、アプリケーションの起動時、アプリケーションが必要とするメモリを確保した後、アプリケーションの実行に必要なモジュールをそのメモリ内にロードする。全てのプロセスで共通の NTDLL.DLL や、アプリケーション間で共有されるユーザの情報、スレッドが実行するのに必要な情報(TEB)等々だ。もちろん、アプリケーションのバイナリやDLLもこのプロセス内に展開される。アプリケーションが実行をはじめた時には、アプリケーションが必要な情報はメモリに全部用意された状態になっている。

これは便利だが、言い換えれば、Windows のお仕着せの方式でメモリが利用されてしまっている。何らかの理由でメモリ上の位置を最初から変えておきたい場合、これは不都合が多い。

Windows10 では、Minimal Process と Pico process というこれまでとは違うメモリの使い方をしたプロセスを用意した。


Minimal Process はメモリ内のお仕着せの準備を一切やめた。プロセスが用意されたときはメモリはすっからかんで用意される。スレッドも用意されないので、このプロセスはほっとくとメモリを食ってるだけでCPUがスケジュールされず、つまり実行されない。それ以前に実行すべきプログラムもメモリ上に展開されていないのでCPUが割り当てられても実行することができない。
ただ、環境サブシステムなど特権的なプロセスはこのメモリ内に色々書き込むことができる。適切なコードを割り当て、スレッドを作れば実行もできるようになる。通常の Windows のアプリケーションとは別種のものを実行しつつ、最低限の管理は NT カーネル 側で実施されるわけだ。
Windows10 では、メモリ圧縮や「Device Guard」「Credential Guard」といった仮想化を利用したセキュリティ機能で、この Minimal Process が利用されている。


Minimal Process はメモリはすっからかんでも、特定の手順(システムコール)でOSを呼び出させば、他のアプリケーションと同じく Windows のOSの機能を呼び出すことができた。
Windows も Linux も、最近の x86-64 (x64) の OS では、CPU のもつ sysenter もしくは syscall という命令を使用する。呼び出したいシステムコールの番号をCPUのレジスタに記録、指定したあと sysenter 命令を実行する。sysenter を実行した瞬間にアプリケーションは停止、各OSのカーネル側に処理がうつり、CPUのレジスタの中を見てアプリケーションがどのシステムコールを呼ぼうとしたか、どういうデータをわたそうとしたかを確認、処理を行う。ただ、どのシステムコール番号がどの処理に対応しているかとか、そもそも処理の有無や機能がOSごとに異なっているわけだ。


通常のプロセスでも Minimal Process でも、sysenter 命令が実行された場合の処理は同じ NTカーネルが担う。

一方、Pico Process では、Pico Provider と呼ばれるカーネルのモジュールが sysenter 命令の処理を行う。Windows に代わってお仕置き...ではなく対応を行うわけだ。WSL の場合、カーネルに組み込まれる LxCore.DLL, LXSS.DLL のどちらか(多分 LxCore)が Pico Provider になっている。ここには Linux のシステムコールが「そのまんま」実装されている。つまり Windows のシステムコールではなく、Linux のシステムコールの番号として判断され、適切な処理が呼び出される。


● bash 起動から、Linux コマンドの実行まで

bash.exe をアイコンから実行すると、これはただのコンソールアプリケーションのため、コマンドプロンプトウィンドウが開き、その中でコマンドが実行される。LxCore, LXSS が必要に応じてNTカーネルに読み込まれ、LxssManager が起動される。

(多分)LxCore が pico process を生成し、(多分)LXSS とサービスとして起動される LxssManager が協力してファイルシステムにある ELF形式の init や bash のバイナリを読み込み、すっからかんのプロセスメモリ内に「さもLinux のように」展開を行い、スレッドを作ってCPUを割り当てる。通常の命令はCPUによりそのまま実行される。

ファイルを読み込んだりテキストを出力を試みると、これはOSの力を借りることになるのでシステムコールが呼ばれる。このとき、sysenter の結果は NTカーネルではなく(多分)LxCore が引き取り、Linux のシステムコールとして処理がなされる。簡単なものなら (多分)LxCore に記述された Linux と同じ処理が行われて、結果が pico process に返される。コンソールへの出力の場合は、LXSS 経由で LxssManager が呼び出され、bash.exe にわたされ、コマンドプロンプトウィンドウに出力がなされる。

Linuxのバイナリは何一つ書き換えられることなく、Linux カーネルの上で実行されていたのと同じように、Windows10 のNTカーネル+LxCore+LXSS の上で実行、できてしまうわけだ。

【Windows10】コンパクトOSでディスク占有量を削減する

Macbook Air(2012)を業務に利用しているが､3年前の機種とはいえ性能的には全く不満はない｡ただ､ディスク容量が 256GB しかないため､仮想マシンを沢山作っていると容量が足りないことがままある｡そこで､普段使いの Windows10 についてはできるだけ小さくインストールすることを試してみた。


● コンパクトOSとは

Windows10 では､コンパクトOSという、主に小容量ディスクのマシン向けにシステムを圧縮して占有ディスク領域を削減する機能が用意されている。詳細は、以下ページを参照して欲しい。
https://blogs.windows.com/japan/2015/04/01/how-windows-10-achieves-its-compact-footprint/
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn940129(v=vs.85).aspx


以前の Windows8.1 では、同様の目的で wimboot という機能が存在した。wimboot はシステムファイルそのものをインストールせず、リカバリパーティションにある再インストール用イメージの中のファイルをつど参照することで､システムの占有するディスク容量を節約することができた。ディスク容量の少ないネットブックやタブレットなどで便利だっだのだが､一方で様々な問題が存在した。

たとえば、WindowsUpdate で更新されたシステムファイルは通常のディスク領域に配置され、かつ圧縮されていないため、時間がたつにつれシステム領域が肥大していくという難点があった。wimboot が参照しているイメージファイルを書き換えられないことからくる制限だ｡
wimboot は SSD/eMMC といったソリッドステートドライブ向けで、HDD はサポートされない、ファームウェアに EFI が必須で PC-BIOS をサポートしないなどの制限もあった。


そこで、Windows10 では wimboot ではなく、コンパクトOSという方式に切り替えられた。

コンパクトOSでは、通常と同じくシステムファイルはインストールされる。ただし、ファイルごと個別に圧縮がかかった状態になっている。WindowsUpdate がかかったときにはシステムファイルが置き換えられるが､更新されたファイルも圧縮されているので容量の肥大は緩やかにとどまる｡
また、wimboot とは逆に、リカバリパーティションにはファイルそのものが配置されず、通常のシステム側のファイルを参照するだけとなっている。

これにより、システムファイルを圧縮、リカバリ用イメージとの重複を避けることでディスク領域を削減するという wimboot と同じ特徴を持ちつつ、アップデートによる肥大を避けることができるようになった。

ハードウェアについても、SSD向けであるのは変わらないとしても､PC-BIOSでもブートできるよう制限が緩和された｡


● 圧縮がかかってるかの確認

圧縮がかかっているかは､compact コマンドで確認ができる｡

管理者権限のコマンドプロンプトで compact コマンドを実行、引数に /compactos を
指定、query オプションをつけることで現在の状態を確認できる

wimboot も windows10 のシステムの圧縮もどちらかというとタブレットなど､ディスク容量に制約がある機器向けのもので､通常のパソコンに Windows10 をインストールするとシステムの圧縮はまず使用されていないはずだ｡

圧縮してインストールするかどうかは､システムをインストールするディスクの容量と､そのマシンのCPUスペックを見るとある｡システムを圧縮､展開するのはそれなりに負荷がかかるため､非力なマシンの場合はかからないことがあるようだ｡

物理ハードウェアにインストールする際は､それでもいいだろう｡

タダ今回は仮想マシンにインストール､さらにクローンでディスク容量を取らないようにするのが目的だ｡CPUパワーは充分にあるし､ディスク容量はクローンするごとに差がでてくるので､強制的に圧縮したインストールを行った｡



● 仮想マシン上での､システムの圧縮されたままでインストールする

まずは VMware Fusion などで普通にWindows10 のインストールメディアから仮想マシンを作成する。
通常のインストール手順を使わないので簡単インストールはオフにしておくこと｡

仮想マシンを起動したら、最初の画面でSHIFT-F10 を押し、コマンドプロンプトウィンドウを呼び出す。

コマンドが使えるようになったら､以下コマンドを実行してインストール先となるパーティションを作成､NTFSでフォーマットしておく｡

X:\Sources> diskpart
DISKPART> elect disk 0
DISKPART> create partition primary
DISKPART> select partition 1
DISKPART> format quick
DISKPART> assign letter=e
DISKPART> active
DISKPART> list partition
DISKPART> list volume
DISKPART> exit

diskpart コマンドを起動､最初のディスク(disk 0)を選択､プライマリパーティションを一つ作成する｡容量を指定していないのでディスクの空き全てをそのパーティションに､つまり全領域で一つのパーティションが作成される｡

select partiton 1 で作成したその最初のパーティションを指定する｡なお､ディスクやボリュームと異なり､パーティションだけは1から始まるので要注意｡

format quick でNTFSでのNTFSでのクイックフォーマットをかけ､仮に Eドライブと設定しておく｡アクティブパーティションとサインすることで､終了だ｡

list partiton ではパーティション一覧が､list volume では Windowsが最終的に認識するドライブ一覧が表示される｡パーティションの先頭に * があってアクティブである事､ボリューム一覧で DドライブとEドライブがあることを確認しておこう｡また､Dドライブはブートした isoイメージだ｡



確認が終わったら終了をし､こんどは OS イメージの書き込みを行う｡

X:\Sources> dism /apply-image:D:\source\install.wim /index:1 /applydir:e:\ /compact

最後にある /compact がシステム圧縮されたままのインストールの指定となる。忘れないように｡

dismコマンドの実行が終わりイメージのインストールが終わったら､以下コマンドでブートローダをセットアップする

X:\Sources> bcdboot e:\Windows /s e:

セットアップが終わったら､一旦シャットダウンする｡
再起動でなくてリブートでもいいと思うだろうが、再起動だとなぜか直後のブートに失敗することが頻発した。リセットして起動しなおすと次のフェイズに行くのだが、ここは確実性を取っていったん仮想マシンごと停止している。

X:\Sources> wpeutil shutdown

再び仮想マシンを起動し直すと､初期設定のフェイズに入る｡

初期アカウントの作成、WindowsUpdate の適用などが行われ、デスクトップが表示されてインストールが完了する。

この時点での VMDK サイズだが、おおむね 5〜6 GB 程度になる。通常のインストールだと 9GB 程度になるので、3-4GB 程度、4割ぐらいが削減できたようだ。


● すでにインストールされた Windows10 をコンパクトOSにする

通常のインストールを行ったWindows10でも、後からコンパクトOSに圧縮し直すことは可能だ。管理者権限で compact /compactos:always を実行すると、システムファイルに圧縮がかけられ、コンパクトOS化される。

既存の Windows10 をコンパクトOSに変更。
それなりに時間がかかり、CPUやディスクに負荷がかかるので注意

この処理は CPUとディスクIOをかなり使う処理なので、時間と電源に余裕がある場合に実行すべきだ。上記手順でコンパクトOSとしてインストールしたものと、インストール後にコンパクトOS化では容量差はない模様。CPUと時間を節約したければ最初からコンパクトOSを、手軽さを考えるなら通常インストールからの compact /compactos:always を入れる、という感じだろう。

Windows 10 でキーボードレイアウトを変更する

Fusion 8 では Windows 10 を正式にサポートしており、光学ドライブやISOイメージからの簡易インストールも可能になっている。

簡易インストールは メディアを指定して仮想マシンを作成、ユーザ名、パスワード、プロダクトキーを入力しておけば、あとは自動的にインストールを行い、VMwareTools まで入れてくれるというものだ。インストールの時間はかかるが、細々とした入力のために画面を見ておく必要がない、ほったらかしで構わないというのは便利だ。

さて、簡易インストールした仮想マシンを試しに使ってみていたら、キーボードレイアウトが 106 になっていることに気がついた。ほとんどのユーザはその方が便利なのだが、私の Mac はいずれも英語配列のため、106 配列だと少々面倒なことになる。

これまでの Windows では、キー配列を変更する最も手っ取り早い方法はデバイスマネージャからキーボードの項目を展開、標準106キーボードになってるドライバの更新をかけ、手動で101キーボードを指定することだった。この方法自体は Windows10 でも可能だ。

しかし、もっと簡単な方法が用意されていたのでここに記録しておく。

まず、Windows 10 の「設定」アプリを開く。「設定」はスタートメニューから開いてもいいし、アクションセンターのボタンをタップしてもいい。

「設定」を開いたら「時刻と言語」を選択する。

「時刻と言語」を開いたら、左側のメニューから「地域と言語」を選択する。

ここで、「日本語」となっているアイコンのあたりをクリックする。するとボタンが現れる。出てきたボタンの中から「オプション」を選択する。

表示された言語のオプションの真ん中あたり、ハードウェア キーボード レイアウトの項目で「レイアウトを変更する」のボタンがあるのでこれを押す。

するとキーボードレイアウトを選択できるパネルが表示されるので、ここで「日本語キーボード(106/109キー)」から「英語キーボード(101/102キー)」に変更する。あるいは日本語キーボードにしたい場合はその逆を選択する。

ただ、サインアウトするとレイアウトが変わると表示されているが、私の仮想マシンではサインアウトしたあとサインインしただけではレイアウトは変わっておらず、仮想マシンの再起動が必要だった。

ともあれ、危険の伴うドライバの更新ではなく、もっと簡単で安全な設定手順が用意されたのは喜ばしいことだ。

Fusion 上の NanoServer に関する短いメモ

最近は WindowsServer 2016 TP2 のメディアから NanoServer をインストールしていろいろ見ている。

まだ、Hyper-V のロールが提供されていないので本当に動かして遊んでいるだけだが、確かに小さいし、余計なものは一切入ってないので ESXi のようにミニマムなハイパーバイザ環境としても使えるし、ファイルサーバや iSCSIのターゲットとして使うもよし、来たるべき Windows のコンテナのベースとしても良さそうだ。

さて、NanoServer を Fusion 上にインストールすると、起動時のボールがくるくる弧を描くのががずっと続いて、起動にすごく時間がかかっているのかと思っていたのだが、どうもそうではないようだ。

先日の Bonjour を有効にすることで気がついたが、仮想マシンをパワーオンしてからほぼ一瞬で起動しており Bonjour に返事をしていた。
WinRM 等を使ってコマンドを一個でも実行すると即座に黒字に「_」だけの画面になる。

どうも、Fusion 上では起動画面を切り替えるタイミングが何故かはわからないがミスってるっぽく、切り替わらずだらだらと弧を描いている模様だ。

Windows 10 and Bonjour

Windows 10 の Insider Preview といプログラムが始まっており、登録することで誰もがプレビュー版を取得できる。VMware Fusion 7 は昨年の段階で Windows 10 のプレビュー版がインストール可能となっており、フラットデザインのGUIなど新しい Windows を試すことができる。

このプレビューの目的は広くフィードバックを得ることでリリース時の製品品質を上げることにある。リリースされてからあれこれ困るぐらいなら、積極的にフィードバックを出しておいた方が世のため人のためになるだろう。なお、日本語でOKとのことだ。

さて、Windows 10 をいろいろ試しているときに面白いことに気がついた。netstat -an とうつと、5353/udp を LISTEN しているプロセスがある。

5353/udp はそう、Bonjour だ。最初LLMNR(5355/tcp)かと思ったがこちらも開いており、それとは別に 5353/udp が開いているのだ。

netstat -an の実行結果、5353 が 5355 と同じく開いているのがわかる

試した結果、少なくともこのビルド10074では Bonjour がサポートされており、<コンピュータ名>.local に対して応答している。

ただし、ファイアーウォールのポートが開いていないためそのままでは通信できない。
管理者権限を持つコマンドウィンドウを開き、以下のコマンドを実行、ファイアーウォールのポートを開く必要がある。
(なお、少なくとも私の所では、コントロールパネルのWindowsファイアーウォールの詳細設定で受信の規則を見ようとするとプロセスがクラッシュしてしまい、GUIからは設定できなかった。)

c:\> netsh advfirewall firewall add rule name="mDNS in" dir=in protocol=udp localport=5353 action=allow

Windows メニューを指二本で右クリックし、管理者権限のコマンドウィンドウを開く
なお、私はデフォルトで PowerShell に設定している

管理者権限で上記のコマンドを実行

結果、ホストの Mac から Fusion上の Windows 10 (plaster) に対する名前解決に成功、IPアドレスを拾うことができた。(ICMPを Windowsファイアーウォールがふさいでいるため、PINGそのものは失敗している)

PINGは失敗しているが、IPアドレスが表示されている、名前解決に成功していることに注目

なお、これは WindowsServer 2016 Tech Preview 2 でも、その中の NanoServer でも同じだ。ファイアーウォールさえ開けておけば、Bonjour で、あるいは LLMNR で名前解決が可能となっている。(そう、何故かLLMNRもポートが閉じている、同じように 5355/udp を開くことでLLMNRによる名前解決も可能になる。)

こちらの NanoServer のスタートアップ記事などでは、「なんとかIPアドレスを調べて」となっているが、Windows10 でも NanoServer でも Bonjour/LLMNR を有効にしておけばこの部分がだいぶ楽になる。(NanoServer の場合、SetupComplete.cmd  に上記のファイアーウォールルールの設定を書いておけばいいだろう。)

正式リリース版でどうなるかはわからないが、しかし、プレビューの間だけであっても、Windows 自身で Bonjour サポートがなされるとはなかなか感慨深いものがある。