2017/10/26

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

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


以前よりマイクロソフトは Windows 向けに OpenSSH の移植を行っていたが、どうやらこれがとうとうOS側に搭載されるようになったようだ。まだβ版で以下に述べるように少々問題があるが、エスケープシーケンスが強化されてきているコマンドプロンプトウィンドウとあわせることで、TeraTermPutty といったターミナルエミュレータ抜きで 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標準で提供され、サードパーティーのアプリを入れなくて良いという点では評価ができるかと思われる。

2017/10/20

Flash 27.0.0.170 で WebClient がクラッシュする

普段使ってない vSphere 6.5 の vCenterServer アクセス、WebClient を使おうとした時に、ブラウザ内で「プラグインがクラッシュしました」などと表示され WebClient がいつまでもあがってこず難儀してしまったのでメモ。

これは、WebClient 側の問題で、VMware の KB (2151945) にも記載がある。
残念ながら現時点では解決策はない。ワークアラウンドとしては
  • Flashプラグインのβ版を導入する
  • 前のバージョンの Flash プラグインに無理矢理ダウングレードする
  • HTML5の vSphere Client ないしは C# の vSphere Client を使う
の三つだ。正直どの対応もいかがなものかと思うのだが、vSphere 6.5 の場合これまで使っていた Windows アプリ(C#) の vSphere Client も使えないし、HTML5版はまだばまだメインで使うには辛いのでダウングレードを試してみた。

macOS の Macbook Pro のため、
  1. Adobe のサイトから Flash のアンインストーラをダウンロード、実行
  2. こちらのサイトから 27.0.0.159 の Flashプラグインをダウンロード、インストール
  3. システム環境設定の Flash Playerペインから Flash の自動アップアップデートを禁止
という手順になった。
なお、1. のアンインストーラーは PPAPI の Flash も NPAPI の Flash もどちらも消してしまうので要注意だ。また、上記にリンクされている 27.0.0.159 の Flashプラグインは各OS版がまとめて入っているので少々大きい。使うのは「27_0_r0_159」フォルダのなかの「flashplayer27_0r0_159_mac.dmg」と「flashplayer27_0r0_159_macpep.dmg」だけだ。flashplayer27_0r0_159_mac.dmg が NPAPI 版のプラグインで、flashplayer27_0r0_159_macpep.dmg が PPAPI 版プラグインだ。

NPAPI はもはや Firefox しか使ってない古いインターフェイスのもので、PPAPI は Chrome および Safari が使っているより新しいインターフェイスになる。

私は Chrome を使っていないのと、普段使いの Safari と WebClient へのアクセス用のFirefox を分けていたのもあり、NPAPI 版の「flashplayer27_0r0_159_mac.dmg」飲みをインストールした。

結果、WebClient が使えるようになったが、Flash の利用には制限をかけておいた方がいいのかも知れない。