いやー、まいった。

snapshotの検証やってたら、piscesを壊しちゃったよ。
pisces作り直しだ。

作り直すと、sshdのホスト鍵が変わるので、sshログイン時に「このサーバ、偽物ちゃう？」ってエラーが出る。
その場合は、ローカルのホスト鍵(known_hostsに書かれている)を削除しよう。

接続元がLinux/Unixの場合は、
$ ssh-keygen -R 接続先ホスト名orIPAddress
かな？

おうふっ！仮想マシンのメモリを128MBに縮小したままだと、インストーラの起動に失敗する。
インストール時は512MBまで拡張しておこう。

sshのエージェント転送を使おう！

ゲストOSのpisces/ariesは、物理的にはホストOSであるaquariusの中に入っているけど、Open vSwitchのブリッジのお陰でネットワーク的にはaquariusや他のPCとフラットな関係にある。

そのため、作業用の端末を家のLANに繋いでいる場合、pisces/ariesへは直接sshログインが出来る。

ところが、外から接続する場合、今はルータの設定上、一度aquariusにログインした後、pisces/ariesへログインするという、sshを多段に通す必要がある。

ルータの設定で、pisces/ariesへポート転送すれば、外からも直接アクセス出来るようになるんだが、あまり穴を空けすぎるのも危険なので、外から接続する時は、aquariusを経由しなければならない制約は我慢することにする。

で、sshの鍵の配置について考えてみよう。

作業用端末を家のLANに直接繋いでいる状態で、pisces/ariesへ直接ログインする場合、作業用端末のssh公開鍵をpisces/ariesへ登録しておけばいい。
これは、sshで接続＠鍵認証で行った公開鍵の登録と同じ作業を行うということだ。

作業用端末が外にあって、外からaquariusにsshログインし、そのセッションからpisces/ariesへsshログインする場合は？

普通に考えれば、aquariusで鍵ペアを作成し、その公開鍵をpisces/ariesに登録すればいいと思う。

この場合、作業端末で作成した鍵ペアと、aquariusで作成した鍵ペア、両方を管理しないといけなくなる。
今はまだいいが、将来増えてくると、ちょっと管理しきれなくなる。
そこで出て来るのが「エージェント転送」という機能だ。

エージェント転送は、sshで接続＠Agent認証その2の最後に名前だけ出している。ようやく、解説と実装する機会が来た、というわけだ。

エージェント転送とは…
sshの鍵認証のやり取り部分を、もう一つ手前のsshセッションに任せる、という感じの仕組みとなる。
文章だと分かりにくいが以下の図を見ればわかると思う。

つまり、踏み台になっているaquariusで鍵ペアを作る必要はなく、作業用端末で持っている秘密鍵で認証が出来るわけだ。

これなら、複数の鍵ペアを管理する必要は無い、だけでなくpisces/ariesへ直接ログインする時も、aquariusを経由してログインする時も、同じ鍵を使って認証出来る。

これを実現するためには、条件が2つある。
一つは、言うまでもなく、最終接続先であるpisces/ariesに、作業端末の公開鍵が登録されていることだ。

もう一つは、作業端末→aquariusの接続で、エージェント転送を許可していることだ。

それぞれ実装しよう。
まずは、pisces/ariesに公開鍵を登録する。
これは、sshで接続＠鍵認証と同じ手順でいいのだが、既にaquariusに登録されている鍵を、そのままpisces/ariesへ持っていって登録すればいい。

以下の手順で実施しよう。
piscesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.133:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.133
(pisces)$ mkdir .ssh
(pisces)$ chmod 700 .ssh
(pisces)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(pisces)$ rm authorized_keys.aquarius
(pisces)$ exit
ariesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.134:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.134
(aries)$ mkdir .ssh
(aries)$ chmod 700 .ssh
(aries)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(aries)$ rm authorized_keys.aquarius
(aries)$ exit

次は、作業端末→aquariusの接続でエージェント転送を許可、だ。

これは、teratermからのsshログイン時、ユーザ名を入力するダイアログにある「エージェント転送する(O)」にチェックボックスを入れておくだけでいい。

一旦ログアウトして、再度ログインする時にチェックを入れよう。

そこまで準備が整ったら、エージェント転送の確認だ。
既にaquariusへはログインしていると思うので、そこからpisces/ariesへログインしてみよう。
(aquarius)$ ssh 192.168.55.133
もしくは
(aquarius)$ ssh 192.168.55.134
「エージェント転送要求を受け入れますか？」というダイアログが出てきたと思う。

このダイアログに対して、「はい(Y)」を選択してみよう。
パスワードを入力することもなく、ログインすることが出来たはずだ。
これによって、鍵ペアを複数管理する必要もなく、ログインパスワードを入力する必要もなく、多段ログインが出来るようになった。

更に、作業端末を家のLANに直結して、pisces/ariesへ直接ログインする時も、パスワード認証をせずにログインが出来るようになったぞ。

というところで、今回のsshエージェントに関してはオシマイ。

KVMその4(SPICE)

さて前回、KVMの画面描画にSPICEというプロトコル？が使えることは軽く書いた。

今回は実際に、SPICEプロトコルを使った画面の確認をしてみたいと思う。

SPICEは、RDPと同じように作業端末側から繋ぎに行く。そのための専用クライアントソフトがある。
手元のWindowsマシンで動くクライアントもある。
https://virt-manager.org/download/
この中の virt-viewer というエントリに、 Win x86 MSI/Win x64 MSI のそれぞれのリンクがあるので、手元のWindowsの32bit/64bitに併せてダウンロード、インストールしておこう。

--2016/07/19追記--
2016/06/30付で、virt-viewerの4.0がリリースされているようだが、これのWin x64版にはどうやらバグがある。(確認したのはWin x64版だけで、x86版にも同様にバグがあるかもしれない。)
一度画面描画された後、画面が更新されないというバグだ。ウィンドウを裏に隠してから、また表に出すと描画が更新されるが、毎回それをやらないといけない、というバグ。
そのため、再リリースされるまでは、3.1を使おう。
https://virt-manager.org/download/sources/virt-viewer/virt-viewer-x86-3.1.msi
https://virt-manager.org/download/sources/virt-viewer/virt-viewer-x64-3.1.msi
--2016/07/19追記ココまで--

作業端末にインストールが終わったら、さっそくaquariusにログインしよう…。と、言いたい所だが、F/W(ルータ)の外側からaquariusにログインする場合、sshトンネルを使ったリモートデスクトップその2の時と同じように、ポートフォワーディングの設定をしておこう。
SPICEは、使用するポート番号は特に決まっていないようなので、今回は暫定的に9001を使用する。
設定内容は以下の通り

• ローカルのポート：9001
• リッスン：127.0.0.1
• リモート側ホスト：127.0.0.1
• ポート：9001

ポートフォワードの設定が終わったら、今度こそaquariusにログインしよう。
ログインしたら、前回までと同様に、kvmを起動するが、spiceオプションを付けて起動する。
$ cd iscsivol/
$ kvm -machine type=q35 \
      -hda     test.img \
      -boot    c        \
      -m       512      \
      -cpu     host     \
      -smp     4,cores=2,threads=2,sockets=1 \
      -spice   port=9001,password=test &
(ちょっと長いため、改行を入れた。-machineオプション、-smpオプション、-cpuオプションは付けても付けなくてもいいぞ。)
今回は & 付きでバックグランド実行させている。そのため、プロンプトはすぐ戻ってきたはずだ。

この時点で今までだったら新しいウィンドウが立ち上がり、そこに仮想マシンの画面が表示されていたはずだ。
今回 spice オプションを付与したため、新しいウィンドウは立ち上がって無いはずだ。

ここで、先ほど作業用端末にインストールしたspiceクライアント(virt-viewer)を起動しよう。
プログラムの名前は「Remote Viewer」になっていると思う。

起動したら、以下のようなウィンドウが立ち上がってくるはずだ。

このウィンドウの「Connection Address」欄に、

spice://127.0.0.1:9001 と入力しよう。
＃自宅内LANから接続している等、sshポートフォワードをしていない場合は、IPアドレスは aquarius のIPアドレスになるぞ。

入力が終わったら、上記画面で示したとおり「Connect」ボタンを押そう。

「Connect」ボタンを押したら、新しいウィンドウがオープンし、パスワードを入力するダイアログが表示されたはずだ。
(「Username」欄は入力出来ない状態だ。)

Password欄には、kvmを実行した時のpassword=の値を入力しよう。
先ほどのコマンドなら、test のはずだ。
右下の「OK」ボタンを押すと、ウィンドウサイズがリサイズされて、今までと同じようなログイン画面が出てきたはずだ。

今まで通りログインしてコマンド類を実行してみよう。
普通に使えることが分かるはずだ。

piscesをOS再起動しても、spiceクライアントがそのまま利用出来るのも確認しておこう。
(pisces) $ sudo shutdown -r now

また、今までの X を用いた画面転送では、画面がクローズする(右肩のXボタンを押す)と、ゲストOS(pisces)も停止してしまっていた。
spiceクライアントを利用している場合は、spiceクライアントが停止しても、ゲストOSは稼働したままだ。
再びspiceクライアントから接続すれば、作業が継続出来る。

但し、ホストOSである aquarius からpsを見ると、passwordも丸見えなので、扱いには気をつけよう。

kvmコマンドの-spiceオプションは他にも色々ある。今回はsshトンネルを通しているため、特に暗号化を行う必要は無い(sshトンネルで暗号化されている)が、TLS(Transport Socket Layer)も使える。いわゆるSSL暗号化と言うヤツだ。(微妙に違うが…)
この辺りも、少しずつ調査をして記録していきたい。(要するに、まだ理解していないってことだ…)

稼働確認等が終わったら、忘れないようにshutdownしておこう。
(pisces) $ sudo shutdown -h now
SPICEクライアントも終了してウィンドウがクローズされたはずだ。

今回はここまで。

KVMその1

というわけで、ようやく本命のKVMに入れる。
(初めて触るので、正直どこまでやれるか…)

なので、まずは環境整備から。

KVMを使用するためには、作業用端末でX Window System(以下X)を利用できる状態にする必要があるようだ。(サーバ本体でX Window Systemを動かしてもいいんだけど、それだと常にサーバの前にいないといけないので…)

で、作業用端末がWindowsの場合、X Window Systemが動くようにするには、幾つかの方法がある。

• 製品を買う。(ASTEC-XとかReflextionXとか)
• Cygwin-Xで頑張る
• VcXsrvを使う
• その他…

細かいことは抜きにして、今回はVcXsrvを使用することにする。(フリーだし、同じくフリーで実績のあったXmingの分離版らしいし。)
VcXsrvはsourceforgeからダウンロード出来る。(https://sourceforge.net/projects/vcxsrv/)
但し、動かすためには、VC++2015 Runtimeが必要だ。併せて入手しておこう。

細かいところは省略するけど、VC++RuntimeとVcXsrvをそれぞれインストールしておくこと。

導入が終わったら、VcXsrvを立ち上げておく。
スタートメニューから、VcXsrv→XLaunchを起動しよう。
起動したら、Display settingsで、画面の形式を指定するダイアログが表示される。
デフォルトの「Multiple windows」のまま「次へ」
Display numberもデフォルトの-1のままで構わない。

次のClient startupも、「Start no Client」でいいだろう。

次のExtra settingsも、デフォルトのままでいい。

最後に、この3画面分の設定を保存することが出来る。保存してもいいし、都度XLaunchから設定しても構わない。

タスクトレイに「X」みたいなアイコンが表示されたら起動完了だ。

続いて、teratermのssh転送で、X転送が可能なようにしておこう。
これは簡単で、ログイン前のteratermのメニューから、「設定」→「ssh転送」

出てくるダイアログの「リモートの(X)アプリケーションをローカルのXサーバに表示する」のチェックを入れて「OK」してから、sshでUbuntu Linuxへログインすればいい。

これで作業用PCの設定は終わりだ。
続いてUbuntu Linux側の環境を整えよう。

幾つか必要なパッケージがあるけど、最低限qemu-kvmは入れておく必要が有る。
$ dpkg-query -l qemu-kvm

OS構築の時に「Virtual Machine」というパッケージグループを入れているので、入っているはずだ。
もし入っていなかったら、以下のコマンドで入れておこう。
$ sudo apt-get install qemu-kvm

それ以外にも、virt-managerというのが入っていると便利らしいのだが、今はまだ入れないでおく。
この先、導入する予定だ。
$ dpkg-query -l virt-manager

で、qemu-kvmを導入した時かどこかのタイミングで、/dev/kvmというデバイスファイルが出来る。
このデバイスファイル、ubuntuの場合はグループがkvmグループになるはずなんだけど、そのためには一度再起動をしておく必要が有るらしい。
$ ls -l /dev/kvm

もし、/dev/kvmの所有グループがkvmではなかった場合は、一旦再起動しておこう。
$ sudo shutdown -r now

で、kvm関連の操作には、/dev/kvmへのアクセス権限も含めて、kvmグループに属しておく必要があるらしい。そのため、以下のコマンドで自分のアカウントをkvmグループに含める。
$ grep kvm /etc/group
$ id
$ sudo adduser (自分のユーザ名) kvm
$ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
$ id

あと、カーネルにkvmモジュールが組み込まれているか確認しておこう。
$ lsmod | grep kvm
使っているマシンがIntel NUCなので、kvm_intelとkvmの2モジュール出てくるはずだ。

ここまで来たら、kvmコマンド自体は使用可能になっているはず。簡単な操作で確認してみる。
$ kvm -monitor stdio
これを実行したら、勝手に一つウィンドウが開いたのではないだろうか？
これを表示させるために、先にVcXsrvをインストールした。
(作業用PCをUbuntu Linuxの間のネットワークが、モバイルネットワーク(4G回線等)の場合、表示されるまでに非常に時間がかかると思うが、数分待ってみて欲しい。)

よく見てみると、「Booting from Floppy」だの「Booting from DVD/CD...」だの、PCが起動する時のBIOSのメッセージに似ているというのに気付くはずだ。
最終的に「No bootable device.」で終わっている。
過去に、PCのOS用HDDがクラッシュしたことのある人なら、恐怖とともに見たことがあるメッセージではないだろうか？
QEMU環境で、簡単なBIOSブートをしてみた、というのがこの画面だ。
この画面が出れば、QEMU(KVMのベースとなる環境)が稼働しているということになる。

teratermの方を見てみると、プロンプトが(qemu)となっているはずだ。
これが、qemuを操作するためのプロンプトだが、詳細は不明なので、おいおい書いていくこととする。

qemuのプロンプトから、kvmの状態確認コマンドを打ってみる。
(qemu) info kvm
kvm spport: enabled と表示されるはずだ。
このマシンで kvm が利用できる、ということらしい。

最後に、quitで抜けておこう。
(qemu) quit
先ほど起動したウィンドウも消滅したはずだ。

まずはココまで。
--2016/06/20追記
間違って「X Windows System」と書いてしまってた場所が有ったので、「X Window System」に修正。
同じく「Flopply」と書いていたので、「Floppy」に修正。

sshトンネルを使ったリモートデスクトップその2

前回は、軽くポートフォワーディングについて記載した。
んで、自宅内のWindowsマシンに、外出先からリモートデスクトップ(RDP)接続出来るようにしたい。

ただ、「外部からsshでログインその1」でルータに設定を施したように、Windowsマシンへも転送するようにすれば、別にsshを通す必要は無い。

これなら、RDPのポート番号さえ分かっていれば、簡単に実現できる。

ただこの場合、幾つか問題点がある。

1. WindowsPCが増えるたびに、ルータのポート転送を追加する必要がある
2. 当然、WindowsPCが減ったら、ルータのポート転送を削除する必要がある
3. ポートスキャンをかけると、RDPサービスだということがバレる
4. アクセス制御が、RDPの仕組み(ユーザ認証)しか無い
5. 生RDP通信であり、暗号強度が不安(どのような暗号アルゴリズムなのか不明)
6. ルータにたくさんの穴開けをしないといけなくなる(台数分)

1,2,6は、「そもそもそんなにWindowsマシン作らないよ」ということになると思うが、今後Ubuntu Linuxマシンや、Windowsマシン上に仮想マシンを作って、WindowsOSをどんどん作っていったら…？なんてことを考えると、意外と管理に手間がかかる。
(ま、WindowsOSのライセンスが高いので、そんなに作ることは無いと思うが)

3,4,5は、RDPセキュリティに関連するそのことだが、正直RDPの暗号強度が高いとは思えない。
また、「外部からsshログインその1」「その2」で書いたように、外部からのアクセスはユーザID/パスワードの組み合わせ以外の仕組みも使いたい。

そういった点を考慮しつつ、それでもRDPで接続出来るようにならないか？
というところで出てくるのが、先に紹介した「sshポートフォワーディング(ローカルポートフォワーディング)」だ。
ローカルポートフォワーディングを使って、以下のような接続状況を作ればいい。


と言っても、これだけではイマイチ良く分からない。
なので、実際に動かしながらやってみよう。

条件としては、外(The Internet側)から、家の中のUbuntu Linuxへsshログイン出来ること。
Ubuntu Linuxと同じネットワーク内(家のネットワーク)に、RDP接続を許可したWindowsマシンがいること。(そもそも、WindowsのHome EditionではRDP接続出来ないため、Professionalとかそういうエディションを使うこと)
作業用PC(クライアント)は、Windows＋teratermでサンプルを書く。

1. teratermでsshログインする前の設定
   ログインする前に、teratermの設定でSSHポート転送を有効にしておこう
   
   
   
   設定内容は以下の通りだ。
   
   • ローカルのポート
     13389
   • リッスン
     127.0.0.1
   • リモート側ホスト
     接続先Windows機のIPアドレス
   • ポート
     3389
2. sshログイン
   上記の設定を施したら、「OK」ボタンで設定を確定し、今まで通りにUbuntu Linux機へsshログインしよう。
3. RDPクライアントでログイン
   端末側でRDP接続を起動して、以下のようにログイン情報を入力する。



• コンピュータ
  127.0.0.1:13389 (sshポートフォワードの設定で入れた「リッスン」と「ローカルのポート」を「:」で繋いだもの）
• ユーザ
  接続先Windows機のユーザアカウント名
これで接続すると、通常のRDP接続と同様、パスワードを聞いてくるダイアログが出てくる。(証明書関連の警告も出てくると思うが、そちらは普段通りにOKしてくれればいい)
また、ここで入力するパスワードは、操作用PC(クライアント)のパスワードではなく、接続先の(自宅内の)Windowsマシンのパスワードだ。



この時のダイアログをよく見てみて欲しい。
「これらの資格情報は、127.0.0.1(RDP接続先のIPとして指定したIP)への接続に使用されます。」となっているはずだ。
このアドレスは、自分自身を示すアドレスのため、「遠隔のWindows機ではなく、自分自身へ接続しようとしている」ことになる。
これが、ローカルポートフォワーディングの基本的な考え方だ。
つまり「ローカル(自分自身)への接続を、他のマシンへ転送する」ということだ。
4. リモートデスクトップ接続に成功する
   成功すれば、リモートデスクトップの画面が出てくるはずだ。
   
   
   
   これで普通に操作が可能だ。
   ウィンドウタイトル部分をよく見てみると、接続先が「127.0.0.1:13389」になっていると思う。これは、RDPクライアントとしては「127.0.0.1:13389」へ接続していると思い込んでいる、ということだ。実際には、sshがパケット転送をしてくれて、自宅内のWindows機へ接続している形になっている。

さてこれでRDP接続が出来るのが確認できた。
そこで、一体どのようなフローで接続できたのかを確認しておきたい。

簡単な図に書いてみたが、先にポートフォワードを有効にしてsshログインを行うことで、作業用PCとUbuntu Linuxの間でポート転送の設定が行われる。
その上で、RDP通信を行うと、上記図のようにRDP通信がsshのコネクション内を通って行く形になる。
そして、そのRDP通信を受けたsshd(sshサーバ)が、指定されたIP:ポートへパケットを転送する、という形だ。
TCP通信のため、当然戻りパケットも発生するが、これは同じ経路を通って流れていく。
ちょうど、sshで作成したコネクションをトンネルにして、他の通信(この場合RDP通信)が流れていくため、「sshトンネル」等と呼ばれている。

この図で記載したが、赤い線で示した区間は、sshによる暗号化通信が行われている。そのため、単純にパケットを読み取られても、それがRDP通信であることは分からない。（ssh暗号を解読して、初めてRDPであることが判明する。）
そのため、非常に強固で安全性の高いRDP通信を行うことが出来る。(当然、sshの暗号アルゴリズムは強固なものを使う前提だ)

更に、ブロードバンドルータ側には、RDPのための設定は一切行っていない。ポート転送はsshのみだ。

最初にsshによる認証が必要になり、こちらは既に公開鍵認証方式のみ利用できる設定にしているため、外部からのパスワード推測系の攻撃を受けても、突破されることは無い。

とまぁこのように、セキュリティレベルをある程度維持したまま、宅内のWindows機へRDP接続が出来るようになった。
以後は必要に応じて、このパターンでRDP接続しよう。

となると、普段電源を落としている or スリープモードにしている or ハイバネーション(休止状態にしている)Windowsマシンを、遠隔で電源入れられるようにしたい。Wake On LANだ。
次はWake On LANに挑戦したい。

今回は以上。

sshトンネルを使ったリモートデスクトップその1

今度は、sshトンネルを使ったリモートデスクトップだ。

その前に、ssh(sshスイート)を何に使っていますか？ってところから整理しよう。
主に以下の3点じゃないだろうか？

• LinuxやUnixへのリモートログイン
  (sloginコマンド)
• 暗号化された通信を用いたファイル転送
  (scp/sftpコマンド)
• 暗号化された通信を用いたリモートコマンド実行
  (sshコマンド)

sshってのは、上記以外にもう一つ、大きな機能がある。それがポートフォワーディングと呼ばれているものだ。

あれ？タイトルには「sshトンネル」って書いてあるよ？
そう。sshトンネルってのは別称で、正しくはsshポートフォワーディングだ。

そして、sshポートフォワーディングには、

• ローカルポートフォワーディング
• リモートポートフォワーディング

の2種類がある。
それぞれ、ざっくりと図解すると、以下のようになる。

ローカルポートフォワーディング

リモートポートフォワーディング

ローカルポートフォワーディングの方は、自分自身の端末(PC)へのアクセスを、遠隔のサーバに転送する仕組みだ。
リモートポートフォワーディングはその逆。

上記図では、自分とssh接続先だけの関係だが、ちょっと手を加えると以下の様なことも可能になる。

ローカルポートフォワーディング例

リモートポートフォワーディング例

この図の通り、2台の機器の間でssh通信を確立しておくことで、別の機器からの通信も出来るようになる。
(但し、通常はセキュリティを考慮して、別の機器からの通信は出来ないようにしますが…)

これには幾つか制約があって、何でもかんでも転送出来るわけではない。
ざっと…

• 転送可能なのはTCPのみ
• サーバ側ポートが変動したり、逆方向接続が発生するものはNG(ftpとか)

だ。
つまり、TCPで固定ポートを用いる通信であれば、転送させることが可能になる。

この機能を使えば、自宅内のWindowsPCに、屋外からリモートデスクトップ接続出来るようになる、というのが今回の趣旨。(やっと目的の話に…)

ちょっと長くなったので、ココで一旦分離。

外部からsshでログインその2

さて、外部からsshログインが出来る環境は作れた。
但し、ユーザID/パスワードのペアを知っているだけでログイン出来てしまう。
それではセキュリティ的に甘いので、外部からのログインは鍵認証方式だけにしよう。

その前に、認証について…。
色々言われているけど、認証は大きく3つのタイプが存在する。

1. 知っていること
   パスワードや生年月日等、「この人なら知っているはず」の情報をベースに認証する行為だ。
2. 持っていること
   USBドングルや、物理的な鍵等、「持っていること」によって認証する行為。コンピュータの世界では、「暗号鍵を格納したUSBデバイスを持っていること」とか「ある特定のファイルを持っていること」が認証に必要な要素になる。
3. 生体認証
   よく知られている「指紋認証」や「静脈認証」「網膜認証」「虹彩認識」等だ。

そして、認証レベルを高めるためには、これら3つのうち2つ以上を組み合わせると良い、と言われている。(と、テレビで見たｗ)
普段良く使われているパスワード形式の認証は1のみでありまた、外部に知られてしまえば完全に意味が無くなってしまう認証レベルだ。

対して、sshの鍵認証は、2の「持っていること」に依存する。鍵ペアのうち、「秘密鍵」を持っているかどうかが重要になり、秘密鍵が無ければ利用することが出来ない。
但し、秘密鍵は単なるファイルであり、電子的にはコピーすることが容易だ。そこで、秘密鍵にパスフレーズを付与しておくべきとなる。
秘密鍵にパスフレーズを付与しておけば、2の「(秘密鍵を)持っていること」と、1の「(パスフレーズを)知っていること」の2つの組み合わせでの認証となり、多少なりともセキュリティが強固になる。​

ちなみに、3の「生体認証」を実現するためには、網膜スキャナとか指紋スキャナが必要になり、それを認証システムと組み合わせる必要が有るため、かなりメンドウだ。

話を戻して、The Internet側からのアクセスを鍵認証のみに絞り込む方法だが…。

アプローチとしては、

• The Internet側からのアクセスでパスワード認証を禁止する

ではなく、

• デフォルトでパスワード認証を禁止し
• ローカル(宅内LAN)からのアクセスのみパスワード認証を許可する

の方針を取りたいと思う。
デフォルトでパスワード認証を禁止しておいた方が、何か設定ミスがあっても乗っ取られる可能性は低く出来るからだ。

では順番に設定していこう。

• デフォルトでパスワード認証を禁止し
  sshdの挙動は、sshd_config(/etc/ssh/sshd_config)に記載する。
  当該ファイルを見てみると、以下の記載が見つかるはずだ。(Ubuntu 16.04の場合)
  
  # Change to no to disable tunnelled clear text passwords
  #PasswordAuthentication yes
  
  コメントを見てみれば分かると思うが、PasswordAuthenticationがデフォルトではyesとなっているため、パスワード認証が有効になっている。
  このエントリを有効に(先頭の#を外)し、yesをnoに書き換えれば、パスワード認証が無効になる。
  以下のように書き換えて、sshdの設定ファイルを再読み込みしてみよう。
  
  # Change to no to disable tunnelled clear text passwords
  #PasswordAuthentication yes
  ↓
  # Change to no to disable tunnelled clear text passwords
  PasswordAuthentication no
  
  sshdの設定再読み込みは以下のコマンドだ。(root権限で実行して欲しい)
  # systemctl reload sshd
  
  これで、パスワード認証が出来なくなったはずだ。実際にログインして試してみて欲しい。
  
• ローカル(宅内LAN)からのアクセスのみパスワード認証を許可する
  続いて、宅内LAN(家の中)からのアクセスはパスワード認証が通る用に設定したい。
  これには、sshd_configにMatch句を追加して対応する。
  
  具体的には、sshd_configに以下のような内容を追記することになる。
  
  Match Address 192.168.??.0/24
          PasswordAuthentication yes
  Match Address 127.0.0.0/8
          PasswordAuthentication yes
  
  実際には 192.168.??.0/24 は、それぞれの宅内IPアドレス設計に合わせて設定して欲しい。
  (宅内が 192.168.1.0～192.168.1.255 なら、Match Address 192.168.1.0/24 という具合に)
  127.0.0.0/8はローカルホスト接続用だ。あまり気にしないでいい。
  
  この状態で設定の再読み込みを行えば、「The Internet側からはパスワード認証出来ない」「宅内からはパスワード認証出来る」という環境が出来上がるはずだ。
  
  # systemctl reload sshd
  
  設定が終わったら、宅外、宅内いずれからもログイン確認してみて欲しい。
  期待した通りに動いているはずだ。(ルータ側のポート転送設定もお忘れなく) 
  

これで、多少なりともセキュリティレベルを維持出来たと思われる。

次は、sshトンネルを使ったWindows Remote Desktopかな？

外部からsshでログインその1

せっかくLinuxマシンを準備しても、外出先から利用できないともったいない。
(常に電源を入れておくのは電気代がもったいない、という意見もあるけど…)
そこで今度は、外部(The Internet)側からsshログイン出来るように設定しよう。

但し、気をつけないといけないことがある。
The Internet側からログイン可能になる、ということは、悪意を持った人物からもそのマシンが利用されてしまう可能性がある、ということだ。
よくここで「大したデータも入ってないから、別に何かあっても問題ないよ」という人がいるが、それは大きな間違いだ。
悪意をもった人物は、個人の、大して面白くもないデータには興味が無い。重要なのは、そのマシンを踏み台にして、別のサーバ(企業のサーバ等)を攻撃する可能性がある、ということだ。
ある企業がネット攻撃を受け、その攻撃元を調べてみたら、実は自分のマシンだった！なんてことがあった場合、自分は被害者ではなく加害者になってしまうのだ。場合によっては損害賠償請求をうけることにもなりかねない。

つまり、The Internet側からのアクセスを許可する、ということは、それ相応の設定・運用を施しておく必要があり、またきちんとチェックしていく必要がある、ということでもある。
上記を踏まえて、ある程度セキュリティレベルを高めておいて、それでいてThe Internet側からのアクセスが可能になるように考える必要がある。

さて、まずはThe Internet側からLinuxマシンへのアクセスだが、これには前提条件が2つほどある。

1. ルータの(外側の)IPアドレスが、グローバルアドレスであること
   これは、各自ルータの設定画面を見てもらえばわかると思う。製品によって、表示させる方法が異なるため、ここでは省略する。
2. 外部からのアクセスをプロバイダ側がシャットアウトしていないこと
   プロバイダによっては、セキュリティ維持を目的として、外部からのアクセスを厳しく制限しているところがあるらしい。
   恐らく、プロバイダの規約等に記載されているはずなので、よく確認してみて欲しい。

これらの条件がクリアできていたら、The InternetからLinuxマシンへのアクセス設定だ。これはルータの機能で実現可能だ。
ルータによって(多分)表現は異なるが、「ポート変換」とか「ポート転送」、「ポートフォワーディング」といった名称で、その機能が用意されているはずだ。詳しくは各自のルータのマニュアルを参照してもらいたい。
簡単なイメージを下に記載する。

ルータ側で特定のTCPポートをOpenしておき、そこにアクセスが来たら、そのパケットをLinuxのsshdポート(22番)へ転送する、という設定だ。

単にこれだけで、The Internet側からのsshアクセスが可能になる。(teraterm等でログインする時に、ブロードバンドルータのIPアドレスとOpenしたポートを指定すること。また、内側からは指定してもログイン出来ないと思う。ノートPC等をポータブルWiFiルータ等に繋いで試してみよう。)
さて、じゃぁ「特定のTCPポート」って何番よ？ということなんだが…。正直なところ、何番でもいい。
「どうせ、Linuxマシンの22番に転送されるんだから、外側も22番にしておいた方が覚えやすくていいや。sshってデフォルト22番だし。」という考えも間違いではない。
ただ、できれば若い番号(1024番以下)は避けたほうがいい。1024番以下は、特にポートスキャンされやすい番号だからだ。
特に22番は、悪意を持っている人物からは、「sshポート開けてるヤツいねぇかな？」ということで、定期的にスキャンされていると思っておいた方がいい。
そのため、開けておくとすぐに「お、22番開けてるヤツいるじゃねぇか。どれ、辞書攻撃でも仕掛けてみるか。突破できれば儲けもの。」と大量のアクセスが来る可能性がある。
1024番より大きな番号であっても、安心できるわけではないが、多少はマシだ。
とは言え、10022とか、22000とか推測されそうな番号はピンポイントでスキャンされると思うから、それも避けよう。

じゃぁ何番がいいんだよ？ってことだけど…。正直なところ、「覚えていられれば何番でもいい」という結論しか出せない。
例えば「10000 + 西暦生年 + (生まれ月 * 生まれ日)」とか。
2000年12月18日生まれだとしたら、10000 + 2000 + (12 * 18) = 12216だ。
こんな感じで決めてしまっていいと思う。

実際に設定が終わったら、アクセス出来ることを確認しておきたいが、もう一つ重要な点を書いておく。

今のsshdは、公開鍵認証方式だけではなく、パスワード認証方式も有効になっているはずだ。
ということは、The Internet側からも、ユーザIDとパスワードの組み合わせでログイン出来てしまう。

ユーザIDとパスワードの組み合わせというのは、結構簡単に突破されてしまう。従って、セキュリティレベルとしては結構低いと考えたほうがいい。

次回は、sshdを「The Intenet側からは公開鍵認証のみ(パスワード認証は禁止)」、「家の中からは、鍵認証もパスワード認証も両方可能」な設定に変更する。

できれば、その設定が終わるまでは、ルータ側のポート転送を停止しておいて欲しい。

以上。

sshで接続＠Agent認証その2

前回で、Pagent用の秘密鍵は作成した。
 
次は、そのPagentを利用する流れだけど…。実はそんなに難しくない。
作成した秘密鍵をダブルクリックすると、パスフレーズを入力するダイアログが出てくるはずだ。そこに、秘密鍵のパスフレーズを入れればいい。


「OK」を押したら、ダイアログが消えて、何も無かったかのような状態になる。
が、タスクトレイ上に、pagentのアイコンが出来ているはずだ。


このアイコンを右クリックして出てくるメニューから、「View Keys」を選んでみよう。そうすると、このPagentが取り込んでいる鍵の情報が出てくる。
これが、先ほどダブルクリックした鍵だ。


Pagent側はこれで準備が整った。
 
今度はteraterm側だ。
teraterm側は、sshログインの認証方式を選択するダイアログで、以下の様な状態にすればいい。


ユーザ名を入力し、認証方式を「Pagentを使う」にすればOKだ。
これで、パスフレーズを入力することなく、鍵認証でログインすることが出来る。
何回ログインしても、パスフレーズを入力しなくていい。
これがAgent認証だ。
本当にPagentを使用しているか疑問に思えたら、タスクトレイからPagentを終了して、再度teratermからログインしてみたらいい。Pagentが無い、と怒られるはずだ。
 
ただし、手元のWindows端末を再起動する等で、常駐しているPagentが終了した場合は、再度秘密鍵をダブルクリックして、Pagentに鍵を読み込ませる必要がある。
この辺りは身体で覚えよう。
 
また、agent方式を使うと、agent転送という機能も利用できる。
上の認証方式を入力する画面でも「エージェント転送する」というチェックボックスがあるので、そういう名前の機能が存在することはわかると思う。
このエージェント転送、複数台のサーバを経由するようなログインには非常に便利なのだが、今はまだそういう機能を使うメリットが無い。いずれ使う機会もあると思うので、その時に書こうと思う。
 

sshで接続＠Agent認証その1

前回で、Ubuntuに対してteratermを使って、パスワード認証と公開鍵認証を用いたsshログインが出来るところまで試した。
ただ、公開鍵認証を用いても、秘密鍵にパスフレーズを付与しているので、毎回ログインのたびにパスフレーズを入力しなければならず、結構手間だ。
今回は、agentを用いて、パスフレーズを一回だけ入力すれば済むような方向で進めていく。
 
agentって？
クライアント側で秘密鍵を保持しておいてくれて、クライアントソフト(teraterm等)と連携して鍵認証を代行してくれるプログラム。
通常の鍵認証だとこんな感じだけど…


エージェントを使うと、このような感じになる。


teratermで、同じサーバに複数のログインセッションを作るなんていうことはよくある話だが、その都度秘密鍵を読み込んでいたら、毎回パスフレーズを入力しなければならない。結構な手間だ。
そこで、事前にSSH Agentソフトウェアを立ち上げ、そちらで秘密鍵を読み込んでおく。(ここで1回、パスフレーズを入力することになる。)
teraterm等は秘密鍵を読み込まずに、秘密鍵が必要な時にSSH Agentに処理を任せる、というような形にすることで、最初の一回(SSH Agentで秘密鍵を読み込む時)、パスフレーズを入力するだけで済むようになる。
 
Ubuntuをクライアントにしている場合は、OpenSSHに含まれているssh-agentというツールで実現が可能だが、クライアントがWindowsの場合、OS標準にはこのようなツールは存在しない。(そもそも、sshクライアントすら存在しないわけだが…)
agent機能は、フリーソフトで幾つか実現されているようなのだが、今回は PuTTY というフリーソフトに含まれている Pagent というツールを使うことにする。
これ、すごく有名らしく、調べればすぐに情報が出てくると思う。
 
PuTTY は簡単にダウンロード、インストール出来るので、先にインストールしておいて欲しい。
 
で、以前 teraterm で作成した秘密鍵を、PuTTY の Pagent に読み込ませればOKなのだが…、実は Pagent は、teraterm で作成した秘密鍵の書式に対応していない。
そのため、書式を変換する必要がある。
変換はそんなに難しいことではない。PuTTYに変換ツールも含まれているからだ。
PuTTYのインストールが完了していたら、PuTTYgenというツールがインストールされているはずだ。スタートメニューから探して、実行してみて欲しい。
以下の様な味気ない画面が出てくるはずだ。


メニューバーに「Conversions」というのがあるのに気付くと思う。
それらしい名前だが、そのものズバリだ。こちらを選ぶと、Import keyというメニューが出てくる。これをクリックする。


Import keyをクリックすると、お約束のファイル指定ダイアログが出てくるので、以前teratermで作成した鍵のうち、秘密鍵(.pubじゃない方)を指定しよう。
パスフレーズを聞いてくると思うので、秘密鍵に付与したパスフレーズを入力する。


パスフレーズを入力して「OK」を押したら、PuTTYgenの画面が少し派手(？)になったと思う。


あとは「Save Private key」を押して、PuTTY用の秘密鍵をローカルに保存すればいい。(拡張子は.ppkになる)
これで、Pagent用の秘密鍵が出来上がりだ。
 
次は、作成した鍵を PuTTY の Pagent に読み込ませて…なんだけど、今日はここまで。また次回。