2016年5月30日月曜日

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に、屋外からリモートデスクトップ接続出来るようになる、というのが今回の趣旨。(やっと目的の話に…)

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

2016年5月27日金曜日

ブログ移行

ここまでの記事は、アメブロで書いていたもの。
アメブロはちょっと使いにくい点があったので、こちらに移行してきた。
一個ずつ記事を移行したので、手間がかかった。

IT技術系は、やっぱりこのbloggerやFC2が多いみたいだし、ラベル付け等でもメリットがある。

ので、以降はこのbloggerの方に書き込んでいくことにする。

ちなみに、過去のブログは
http://ameblo.jp/uramocha02/
こちら。

2016年5月6日金曜日

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

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

その前に、認証について…。
色々言われているけど、認証は大きく3つのタイプが存在する。
  1. 知っていること
    パスワードや生年月日等、「この人なら知っているはず」の情報をベースに認証する行為だ。
  2. 持っていること
    USBドングルや、物理的な鍵等、「持っていること」によって認証する行為。コンピュータの世界では、「暗号鍵を格納したUSBデバイスを持っていること」とか「ある特定のファイルを持っていること」が認証に必要な要素になる。
  3. 生体認証
    よく知られている「指紋認証」や「静脈認証」「網膜認証」「虹彩認識」等だ。
そして、認証レベルを高めるためには、これら3つのうち2つ以上を組み合わせると良い、と言われている。(と、テレビで見たw)
普段良く使われているパスワード形式の認証は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側からは公開鍵認証のみ(パスワード認証は禁止)」、「家の中からは、鍵認証もパスワード認証も両方可能」な設定に変更する。

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

以上。

2016年5月5日木曜日

Ubuntu 16.04 導入

というわけで、Ubuntuの新しいバージョン16.04を導入した。(サーバ版)
今までの15.10からアップグレードしてもいいんだけど、今回は真っさらにして入れ直した。完全に素の16.04にしたかったからだ。
 
ホスト名やIPアドレスはそのまま。だけど、LVMのレイアウトだけは変更した。
ざっくり以下の表の通りだ。
ボリューム ファイルシステム マウントポイント 容量 その他メモ
/dev/sda1 vfat /boot/efi 512M EFI System Partition
/dev/sda2 ext2 /boot 512M  
/dev/vg-root/lv-root ext4 / 2048M  
/dev/vg-root/lv-etc-opt ext4 /etc/opt 32M  
/dev/vg-root/lv-home ext4 /home 1024M  
/dev/vg-root/lv-opt ext4 /opt 32M  
/dev/vg-root/lv-srv ext4 /srv 32M  
/dev/vg-root/lv-tmp ext4 /tmp 1024M  
/dev/vg-root/lv-usr ext4 /usr 4096M  
/dev/vg-root/lv-usr-local ext4 /usr/local 32M  
/dev/vg-root/lv-var ext4 /var 2048M  
/dev/vg-root/lv-var-backups ext4 /var/backups 32M  
/dev/vg-root/lv-var-cache ext4 /var/cache 1024M  
/dev/vg-root/lv-var-cache-apt ext4 /var/cache/apt 2048M  
/dev/vg-root/lv-var-crash ext4 /var/crash 20480M  
/dev/vg-root/lv-var-local ext4 /var/local 32M  
/dev/vg-root/lv-var-log ext4 /var/log 1024M  
/dev/vg-root/lv-var-opt ext4 /var/opt 32M  
/dev/vg-root/lv-var-tmp ext4 /var/tmp 1024M  
/dev/vg-root/lv-swap-1 swap (swap) 32768M  
結局、/ と /usr は別領域に分割した。
それに合わせて、/usr/shareは独立させず、/usrと同じ領域にした。
また、/var/cache/aptを別領域に独立させた。
結果的に、lvol数が増えてしまったけど、ま、特に問題はないだろう。
 
後は、15.10の時と同様に、IPアドレスの固定化、ssh鍵の配置、バックアップ設定を施し、バックアップを実行した。
 
これで色々試してみるが、次は2回(の予定)に分けて、外部側(The Internet側)からのsshログインについて記載する予定だ。

2016年5月3日火曜日

システムバックアップその18

今回は、これまで作ったスクリプトとバックアップデータを用いて、実際にリストアするところだ。
実際にリストアするため、これまで作っておいたOS領域が全て吹っ飛ぶ。失敗したら、ゼロから作りなおしだ。
でも、これまでほとんど何もカスタマイズしていないため、失敗してたらまたOSから再インストールすればいい。システム構築初期にOSバックアップリストアを検証しておくのは、十分に意味があるのだ。

さて、実際のリストアの流れは以下の通りになる。
  1. OSインストールメディア(CD/DVD)でブート
  2. Rescueモードを選択
  3. 使用する言語等を入力後、メディアのShellモードに入る
  4. 残っているLVM構成や、ディスクパーティションを削除
    (あくまで、SSD/HDDが生きているけどリストアする場合、だ。SSD/HDDが吹っ飛んだため、新しいSSD/HDDを用意した、という場合は不要だ)
  5. CIFSマウントポイントを用意し、バックアップデータやスクリプトが格納されているCIFSをマウントする
    (CIFSにバックアップしてなくて、USBメモリ等にバックアップしている場合は、ここではUSBメモリをマウントすることになるが…)
  6. リストアスクリプトがあるディレクトリまで移動し、リストアスクリプトを実行
  7. リストアが終わったら、Rescueメニューに戻り、ブートローダの設定(uEFIブートメニューの設定)を行う
  8. メディアを抜いて、システム再起動
  9. 動作を確認する
ちょっと長いが、ざっとこんな形になる。
1つずつ記事にしていくと、見る側も大変だろう。ここでは全て一気に記載することにする。
長いので、頑張って読んで欲しい。(頑張って書かないと…)
  1. OSインストールメディア(CD/DVD)でブート
    まずは、OSを停止(shutdown)させ、インストールメディアをドライブに入れてブートしよう。
    放置していると、内蔵SSDからブートしてしまうかもしれないので、画面をよく見てメディアからブートするようにしよう。(この時、必ずuEFIブートすること。機器によっては、uEFIブートに失敗すると、自動的にレガシーBIOSブートをしてしまうものもあるみたいだ。レガシーBIOSブートしてしまうと、最後の方のブートローダの設定で失敗するぞ)
  2. Rescueモードを選択
    メディアでブートすると、以下のようなメニューが出てくるはずだ。
    ・Install Ubuntu Server
    ・OEM install (for manufacturers)
    ・Multiple server install with MAAS
    ・Check disc for defects
    ・Rescue a broken system
    カーソルキーで、一番最後の「Rescue…」を選んでEnterキーを押せば、Rescueモードに入れるぞ。
  3. 使用する言語等を入力後、メディアのShellモードに入る
    最初に、使用する言語を聞いてくる。英語か日本語にしよう。ここでは日本語(Japanese)を選択する。日本語を選択した場合、「この言語は完全じゃない」と言われるが、気にせず「はい」を選択しよう。
    続いて、場所の選択。特に迷うことは無いだろう。
    キーボードの選択だ。自分が使っているキーボードのタイプを選んでおこう。検出機能もあるが、失敗すると面倒なので、自分で指定しよう。多分、ほとんどの人がJapanese - Japanese (OADG 109A)を選んでおけば問題ないだろう。
    ネットワーク内にDHCPサーバが無い場合は、IPアドレス等の設定画面が出てくると思う。もしその場合は、環境に合わせて入れておこう。(家庭用インターネットルータを使用している場合は、そのインターネットルータがDHCP機能を持っているはずなので、自動設定で完了するはず)
    続いてホスト名。リストア時のみに使用されるホスト名なので、特に制限は無い。まぁ、混乱しそうなら、もともと使用している「aquarius」にしよう。
    次はタイムゾーンの設定。最初の言語設定で日本語を選んでいたら、多分Asia/Tokyoが選ばれるはず。そのまま、「はい」を選択してしまおう。
    この後、ディスクがスキャンされ、今までのファイルシステムが使えるようなら、「マウントするか?」と聞いてくる。リストア作業で全消しするので、「ルートファイルシステムとして使用しない」を選ぼう。(SSD破損等で、新しいSSD/HDDに入れ替えていた場合は、この選択は無いはず)
    ここまで来たら、「レスキュー操作」だ。「インストーラ環境内でシェルを実行」を選ぼう。プロンプトが出てくるはずだ。
  4. 残っているLVM構成や、ディスクパーティションを削除
    新しいSSDに入れ替えたわけじゃなく、今まで使用していたSSDに対してリストアする場合、構成情報(LVM情報等)が残っている。これらを一旦クリアしよう。(新しいSSDに入れ替えた場合は、この作業は不要だ)
    まずはLVM情報から。
    # vgs
    SSDに作ったvg-rootというVGが認識されているはずなので、削除してしまおう。(この時点で、全てのデータが飛ぶぞ)
    # vgchange -a n vg-root
    まずは、vg-rootを非アクティブにする。
    # vgremove -f vg-root
    -fオプションを使用していないと、「本当に削除していいか?」と聞かれる。細かく聞かれるので、-fオプションを使って、綺麗サッパリ削除する。
    VGの削除が終わったら、VGを構成していたPVの削除をしておこう。
    # pvs
    /dev/sda3 がリストアップされるはずだ。こいつを削除する。
    # pvremove /dev/sda3
    これで、LVM情報は綺麗に無くなった。

    次は、ディスクパーティション情報だ。
    # parted /dev/sda
    (parted) print
    1~3の3つのパーティションが表示されるはずだ。全部削除しよう。
    (parted) rm 3
    (parted) rm 2
    (parted) rm 1
    (parted) print
    パーティションが綺麗サッパリ無くなったはずだ。
    (parted) quit

    これで、リストア先のSSDが綺麗になった。
  5. CIFSマウントポイントを用意し、バックアップデータやスクリプトが格納されているCIFSをマウントする
    レスキューモードで立ち上がっている状態(簡易OSで起動している状態)は、メモリの一部をHDDのように使ってOSデータを一時的に配置している。
    レスキュー専用のOSのため、バックアップデータを格納しているCIFS領域をマウントするマウントポイントが無い。作ってしまおう。
    # mkdir /media/backup

    そうしたら、バックアップデータが格納されているCIFS領域をマウントしよう。
    ただ、マウントコマンド及びオプションが少し異なるので注意が必要だ。
    # mount -t cifs -o user=guest //IPアドレス/バックアップ格納先 /media/backup
    # ls /media/backup
    無事にマウント出来たら、バックアップデータ(日付ディレクトリ)が見えるはずだ。
  6. リストアスクリプトがあるディレクトリまで移動し、リストアスクリプトを実行
    ここまで来たら、リストア実行だ。
    リストアしたいデータの日付ディレクトリを確認し、その下のbinディレクトリまで移動しよう。
    # cd /media/backup/YYYYMMDDhhmmss/bin
    # ls
    バックアップスクリプトと一緒に、リストアスクリプトもあるはずだ。
    これを実行しよう。
    # ./1000_restore
    ファイルシステム作成時、「続けていいか?」という問いが発生するみたいだ。ここは気にせず、yを押そう。

    しばらくしたら、プロンプトが戻ってくる。
    これでファイルのリストアは完了だ。
    プロンプトから抜けて、リストアメニューに戻ろう。
    # exit
  7. リストアが終わったら、Rescueメニューに戻り、ブートローダの設定(uEFIブートメニューの設定)を行う
    Resqueメニューに戻ったら、すぐに再起動したくなる気持ちを抑えて、「戻る」からメニュー全体に移動しよう。
    ファイルシステムのマウントのメニューが出てくる。ルートファイルシステムである、/dev/vg-root/lv-root を選択しよう。
    個別の/bootパーティション云々、という画面も出てくる。合わせて「はい」を選択しよう。

    次のメニューでは、一旦「/dev/vg-root/lv-root 内でシェルを実行」を選択しよう。リストアしたファイルシステム一式を、マウントしておきたいからだ。
    コマンドプロンプトに入ったら、mount -a を実行しよう。mountコマンドを使って、/dev/sda1 等がマウントされているのを確認したら、戻っていい。exitしよう。
    (もしかしたら、このブロックの作業は不要かもしれない)

    戻ってきた画面には、「GRUB ブートローダの再インストール」というメニューがあるはずだ。これを実行しよう。(多分コレを実行することで、uEFIメニューが出来る…はず)
    インストール先は/dev/sdaでいいはずだ。
  8. メディアを抜いて、システム再起動
    ここまで行ったら、メディアを抜いて「システムの再起動」を実行しよう。
    Ubuntuが無事に立ち上がってきたら成功だ。
  9. 動作を確認する
    念のため、dmesgや/var/log/syslog等をチェックしておこう。
    最後に、念には念を入れて、再起動一発入れておくのもいいかもしれない。
これでリストア作業は完了だ。
長かったシステムバックアップ・リストアもこれで一区切りついた。

次回からは、OSを16.04にリフレッシュして、いよいよ本格的に実験を始める予定だ。
#今のところ、/ と /usr は分離する方向で考えているので、バックアップ設定ファイルも一部変更が必要だけど…。