わかったつもりになってない?

日常で学んだことをもう少し深堀したいブログ

【AWS】EBSでRAID1+0をやってみたメモ ~前編:そもそもRAIDって何?~

ども、昔合格したはずのLPIC201について再度学習中ですが、5年以上前に学んだこととか全然覚えてませんね。

 

というわけで、LPIC201の試験範囲であるLinuxのRAIDについて学んでいきます。前はたしかVMwareにCentOSとか入れてガチャガチャ弄った記憶がありますのが、今回はAWS使って学びますよ。

そもそもRAIDって何?についておさらい

まぁ、なんというか「ディスク管理の基礎」的な扱いのRAIDについてですが、改めて自分の言葉で書いたりすると理解が深まったり、間違ってたら指摘頂けるかもしれない感じもするので、おさらいも兼ねて書いてみます。このブログの趣旨でもありますしね。

 

ちゃんとした情報が知りたい人はQiita先生Google先生にでも聞きましょう。

 

RAIDの目的

 RAIDの目的は大きく分けて「ディスクへのアクセス高速化」と「ディスク障害の耐性強化」の2つあります。んで、そのどちらか、又は両方のパフォーマンスを上げるために色々な方法が考えられていて、方法ごとに0から始まる番号が振られています。

 

尚、「0」が「ディスクへのアクセス高速化」の為の方法で、「1」以降の番号は「ハード障害の耐性強化」の方法になります。「0」だけ特殊。

 

ちなみに今、RAIDの番号って「0」から始まって…何まであるんですかね。少なくとも2017/11/22現在のWikipediaだと「6」についてまで記載がありました。Google先生に「RAID7」とか聞いてみても30万件以上Hitします。僕のお仕事上触ったことあるのは「0」,「1」,「5」だけで、「6」も割と使われているらしい。

 

RAID0(ストライピング)

では、具体的なRAIDについてざっくり書いていきます。RAID0だけ他の番号と違って「ディスクへのアクセス高速化」のみの役割を担っています。

 

高速化についてそもそもの話で「ディスクめちゃくちゃ遅い」問題があります。SSDとかディスクの高速化が目覚しい昨今でありながら、Qiita先生によると2016年時点でディスクはメモリより1000倍は遅いらしい。

 

1000倍って言われるとよくわからないので単純な距離に例えると、ディスクが東京から名古屋まで行ってる間に、メモリは月面に到着しています。余計わかりません。とにかく、ディスクめっちゃ遅い。 

f:id:gattsu09:20171122225641p:plain 

なので、メモリが高速で書き込もうとしても、ディスクが遅すぎるせいで待ちになっちゃうんですね。その問題を解決…というかマシにする為に生まれたのがRAID0です。

 

その方法というのが、「ディスクを増やしてアクセスを分散させる」です。遅いのなら数を増やして仕事を分割させればいいじゃない…ということですね。感覚的にもイメージしやすいかと思います。

f:id:gattsu09:20171123111219p:plain

メリット

というわけで、メモリが早すぎるおかげでディスクを増やせば増やすほどアクセスが早くなります。後、こちらは副次的な効果だと思うんですが、上図でいうと3本のディスクを1本のディスクとして扱えるため、容量の少ないディスクしかなくてもRAID0で合わせれば、大容量のディスクを作れます

 

デメリット

当然デメリットもあって一言で言うと「壊れやすくなる」です。複数のディスクを一つのディスクとして見なすRAID0ですが、そのディスクの内どれか一つでも壊れると使用不可になります。

f:id:gattsu09:20171123113034p:plain

なので、早くなるメリットは大きいんですが、なかなかRAID0単体で使うことはないんじゃないかなぁと思います。

 

RAID1(ミーラーリング)

 続いてRAID1のミラーリングについて書いていきます。こちらはRAID0とは違って、「ディスク障害の耐性強化」が目的になります。

 

そもそもの話で「ディスクはいつか絶対に壊れる」問題があります。まぁ、ディスクだけに限らずハード全般に言える話ですが…。なので、いつかディスクが壊れてもシステムに影響出ないようになんとかしよう…というのがRAID1以降(0以外)の考えとなります。 

 

んで、RAID1はミラーリングって言うくらいなので、ディスクに書き込む際、同じ情報2つ以上のディスクに書き込むことで、ミラーディスクを作成します。

 

f:id:gattsu09:20171123120040p:plain

メリット

RAID1で構成するディスクは2本以上で可能なので、RAID0とは逆に「ディスクを増やせば増やすほどディスク障害の耐性が増す」になります。3本で構成すれば2本まで壊れてもシステムに影響はでませんね。

 

デメリット

デメリットですがミラーを作るわけなので、「いくらディスクを増やしても1台分の容量しか使えない」です。100GBのディスクを3本用意したとして、RAID0なら300GB使えますが、RAID1だと1台分の100GBしか使えません。

 

また、複数のディスクに書き込みに行くわけなので、その分のリソースが余計にかかり、アクセス速度が低下します。(少なくとも早くはなりません)

 

RAID1+0について

ようやく今回やりたいRAID1+0についてですが、端的に言うとRAID0と1をかけ合わせて、「ディスクへのアクセス高速化」と「ディスク障害の耐性強化」の両方を実現したいというのが今回の目的です。実際の手順は後編で…。

 

f:id:gattsu09:20171123122643p:plain

 

雑なイメージですいません。以下の記事が分かりやすかったです。

 

https://note.cman.jp/server/raid/raid01/

 

後、細かいですが、RAID0+1とRAID1+0とでは、「ストライピングのグループをミラーする」のか「ミラーのグループをストライピングする」のかとで意味が異なるみたいです。同人誌の掛け算(カップリング表示)みたいですね。

その他のRAIDについて

書き始めの頃はRAID5についても書こうかと思っていたのですが、長くなったのと疲れたのと(おい)、AWSではRAID5,6は非推奨みたいなのでここでの記述は割愛します。

 

Linux での RAID 構成 - Amazon Elastic Compute Cloud

 

そもそも、AWSのハードウェアは内部で障害に強い造りになっているので、RAIDは書き込みを高速化させるために「0」が選ばれることが多いとのこと。「Amazon Web Services 実践入門」に書いてました。

 

SSDの障害について

余談ですが、SSDはフラッシュメモリを使用しているため、中で円盤が回っているHDDより壊れにくい印象がありますがググってみると結構壊れた事例が出てきますね。

 

パソコンのSSDが故障した顛末 - 迎え角30deg.

Intel製SSDのX25-M(80GB)が壊れた、その前兆と修理までの軌跡 - consbiol のエコ日記

 

壊れ方(予兆)もHDDとは少し異なるよう。仕事ではHDDのサーバしか扱ったことがないので、SSDが主流になってきたら切り分けに難儀しそうだなぁと思いました。後、RAIDコントローラーは上手いこと自動対応してくれるんだろうか…。こちらは今後の課題とします。

Linuxブートローダ チートシート

どうも。寒いですね。

 

以前「LPI Level2 Exam 202」の試験に合格した記事を書いたのですが、なんと過去に合格した201以下の期限が切れていたみたいなので、再度勉強中な昨今です。

 

んで、201のブートローダについて勉強しているのですが、残念ながら僕的にはあまり興味を惹かれず、全然頭に入ってこない上に、GRUB LegacyとGRUB2の差異がややこしすぎるので、Googleスプレッドシートにてチートシート的なものを作ったので公開します。

 

随時更新予定。間違とか指摘いただけると嬉しいです。

 

Linux ブートローダ

 

参考にしたサイト

http://www2.it-shikaku.jp/top30.php?hidari=101-02-02.php&migi=km101-02.php&bk=1

http://www.turbolinux.co.jp/products/server/11s/user_guide/x395.html

http://www.turbolinux.co.jp/support/document/knowledge/277.html

続・AWSで無料枠内利用しているつもりなのに料金が発生した件の原因と対応

以前の記事で、普段使っている東京リージョンとは別リージョンでElastic IPを開放していなかったために料金が発生したことを書きましたが、また別の理由で料金が発生してしまったので残しておきます。

gattsu09.hatenadiary.com

 

というわけで、請求項目は以下になります。10月に3$程請求がきました。

 

$0.12 per GB-month of General Purpose SSD (gp2) provisioned storage - Asia Pacific (Tokyo)

 

原因

EC2インスタンスを複数作成したことにより、Amazon EBS汎用SSD(gp2)ボリュームの利用が月間で30GBを超えていたため。

 

今回、LPIC 202の学習にあたりAWSでWebサーバやDHCPサーバ等を、プロダクト毎にEC2インスタンスを作成して遊んでいたのですが、そちらがアダになりました。

 

EC2インスタンスをAmazon Linuxで作成した場合、SSDはデフォルトで8GBが割り当てられます。今回EC2インスタンスを未使用時は基本停止していたのですが、5つ程作成して放置していたため、SSDの使用量が月40GB(5×8GB)となり、無料枠を超えてしまいました。

 

対応

不要なEC2インスタンスを削除する。

 

というわけで、不要なインスタンスを全て削除しました。いまのところ11月は無料枠内の使用で収まっています。今後、SSDをデフォルト(8GB)で割り当てる場合は、EC2インスタンスの総数を3つまでに納める。3つ以上作るときはSSDの割当量を少なくするを心掛けたいと思います。

 

 

まぁ、分かってしまえば、なんとも間抜けな話なのですが、EC2インスタンスを複数作っていても、稼働さえさせていなければ良いと勝手に思ってしまってました。。。

 

他にも利用を進めると無料枠を超えることが起こり得ると思うので、上記対応に加えて、請求を細かくチェックするのも大事かなぁと思います。

 

以上。

合格体験記 LPIC202 (ver4.5)

どうも。お久しぶりな更新となります。

時間が経つのは早い早い。

 

というわけで唐突ですが、ここしばらくお勉強していたLPIC202 ver4.5(LPI Level2 Exam 202)に合格したので、誰かの参考になればと体験記的なものを残しておきます。

 

受験日

2017/11/5

 

取得点

500点(合格ライン500点。超超ギリギリ合格…)

 

勉強期間

3週間(一日平均2~3時間くらいなので5,60時間くらい)

 

使用テキスト

あずき本

黒本

 

※ 勉強開始時点では黒本、あずき本はLPICレベル2 Ver4.0のものしか出ていなかったので、そちらを使用。Ping-tがあれば黒本は購入する必要は無いと思います。

 

参考にしたサイト

Pint-t

 

勉強方法

あずき本の内容をざっくり一読。黒本の問題を一通り解く。その後、Ping-tのWeb問題をひたすら解き続ける。

 

休日は上記に加え、Amazon Web Serviceの無料枠を利用して、以下プロダクトをLinux上に実際に導入し設定を色々イジってみて動きを確認する。(加えてNFS接続も)

 

・Apatch(Webサーバ)

・Squid(プロキシサーバ)

・Samba(Windowsとのファイル共有サーバ)

・OpenLDAP(ディレクトリサーバ)

 

その他のプロダクトについては机上での勉強のみ。

 

所感

黒本、及びPing-tのWeb問題集についてはほぼ100%解ける状態で挑みましたが、超ギリギリ合格となりました。

 

LPICレベル2は2017/2/13にver4.0からver4.5に変わりました。今までは十分にver4.5に対応した参考書、問題集が無い状態だったのですが、ようやく10/24にPing-tがver4.5に対応したとのことで、そちらをガッツリ取り組みました。が、正直これだけだと確実に合格するレベルまで持っていくのは厳しいと思います。

 

ver4.0時代に評判のよかったスピードマスター問題集が10/30に発売されたみたいなので、そちらと合わせればなんとかなるかもしれません…が、こちらは使用していないのでなんとも。

 

後、選択問題以外にも、コマンドや設定項目を記述式(タイピング)で問われる問題が7問程度出題されていたので、問題で出てくるコマンド、設定項目は記述できるレベルまで覚えて挑んだほうがよいです。選択式なら確実に解るんだけど、スペルが怪しくてたぶん何問か落としました。

 

今後

実機で触れなかったBIND(DNS)とDovecot(メールサービス)が、分かりやすく点数取れてなかったので少し復習と、やはり実機に入れてみて触ってみようと思います。

AWSで無料枠を利用し「Elastic IP」も全て解放済みのはずなのに料金が発生した件の原因と対応

先月からAWSを利用し、Linuxの勉強を行っているのですが、無料枠内の使用におさめているつもりが3月分の請求が3$程発生しました。

 

明細の詳細を見ると下記項目に料金が発生していたため調査したところ、EC2に紐づいていないElastic IPは解放しないと料金が発生してしまうとのこと。

 

$0.005 per Elastic IP address not attached to a running instance per hour (prorated)

 

この事象結構いろんな人が引っかかってるみたいです。

 

AWSで無料枠を利用していたつもりなのに請求が来ていた件 | Bamboo lath 日々の記録

【AWS学習記】無料枠なのに請求が発生してた。 - My Tracking

 

即座にElastic IPを開放し一安心と思っていたのですが、4月の請求にまたもや同様の項目に料金が発生していました。解放し忘れがあったかなと思い、EC2のダッシュボードを確認したがElastic IPの利用数は0。

 

f:id:gattsu09:20170428203436p:plain

 

<原因と対応>

結局いろいろ調べても同様の事態は見つからなかったので、AWSコンソール上でサポートに問い合わせたところ、以下回答がありました。

 

4月ご利用分に関しましては、 米国西部オレゴンリージョン(以下オレゴンリージョン)にお持ちのElastic IPアドレス(以下EIP)が 稼働中のインスタンスに紐付けられていないことが原因で料金が発生しておりました。 お送りいただきましたキャプチャ画像よりアジアパシフィック東京リージョンの EIPは解放済みであると存じますので、EIP料金の発生を停止いただくには、 以下手順で該当(オレゴンリージョン)EIPの解放をお願いいたします。

 

ダッシュボード上で確認できるのは、あくまで選択中のリージョン(自分の場合は東京リージョン)の利用状況が表示されるのみで、他リージョンでサービスを利用している場合はそのリージョンを選択しないと確認できない模様。(当たり前といえば当たり前ですが。。。)

 

AWSコンソール右上のリージョンからオレゴンリージョンを選択したところ、利用中のElastic IPを発見。そういや、最初のころは分からずにオレゴンリージョン利用してたなぁ。。。

 

f:id:gattsu09:20170428204016p:plain

 

あとはElestic IPの管理画面に移動し、解放。来月以降は料金発生しないはず。まぁ、少額だったし良い勉強料だったと思うことにします。

 

f:id:gattsu09:20170428204322p:plain

 

というわけで、なかなか無いかもしれませんが複数リージョンを利用している場合は、特に注意して利用しているサービスを管理する必要ありそうですね。

 

あと、正直無料で利用している身なのでAWSのサポートあまり期待していなかったのですが、迅速(Web上で問い合わせて1日後)で的確且つ丁寧な日本語で回答が来たことに驚きました。

 

サンキューAmazon。

DNSサーバの種類と特性

ども、前の記事が書きかけですが、別の記事を書いていきます。

 

AWS触ってLinuxの勉強するにあたり、基礎知識の再学習と並行してLPIC Level2の資格勉強も行っていたりします。で、資格範囲にDNS(主にBIND)の設定が含まれているのですが、学ぶ前に各種DNSソフトウェアについてザックリとどのような物があって特性は何なのかを調べたので自分用にメモしておきます。

 

 

djbdns

・D.J.Bernsteinさんが作ったDNSソフトウェアだからdjbdns。

・キャッシュサーバの機能を担うデーモンと、コンテンツサーバとしての機能を担うデーモンとに分かれている。
(BINDでは両機能はnamedデーモンが担っている。)
・BINDと比較し設定が用意で安全とされている。
・パッケージは http://cr.yp.to/djbdns/install.html から入手可能。

<参考>
http://cr.yp.to/djbdns.html (公式)
http://djbdns.qmail.jp/
https://ja.wikipedia.org/wiki/Djbdns
http://www.asahi-net.or.jp/~AA4T-NNGK/djbdns.html

 

PowerDNS

・オランダ企業の「PowerDNS.COM BV」が中心の開発コミュニティに生み出された。

・djbdnsと同様、キャッシュサーバと、コンテンツサーバのプロセスが分かれている。
・MySQLやOracle等のRDBをバックエンドデータベースとして使用できる。
・BINDと比較し設定が用意で安全で高機能とされている。
・yumコマンドで「pdns」を指定することでインストール可能。

<参考>
https://www.designet.co.jp/faq/term/?id=UG93ZXJETlM
http://takuya-1st.hatenablog.jp/entry/2016/07/14/202554

 

dnsmasq

・simon kelleyさんが作ったDNSソフトウェア。

・DNSキャッシュサーバ、およびDHCPサーバの機能をもつソフトウェア。
・単体ではDNSコンテンツサーバとしては使えない。
・軽量で設定が容易。
・小規模なネットワークでの使用を想定して作られている。
・yumコマンドで「dnsmasq」を指定することでインストール可能。

<参考>
https://wiki.archlinuxjp.org/index.php/Dnsmasq
http://server.etutsplus.com/dnsmasq-setup-internal-dns/

 

BIND

・Paul Vixieさんが作ったDNSソフトウェア。

・世界でもっとも利用されている。
・そのため、他DNSソフトウェアから色々比較の槍玉にあげられている。
・LPIC 202ではBINDの設定が試験範囲。
・yumコマンドで「bind」を指定することでインストール可能。

<参考>
https://ja.wikipedia.org/wiki/BIND

 

他にもいろいろあるんでしょうか。とりあえずこの辺で。

AWSにおけるある程度セキュリティ強度の強いサーバの構築について

というわけで、AWSでサーバを立てて、まずはユーザ認証周りのセキュリティについて学んでいきたいと思います。標準的なLinuxの設定について触りたいので、AWS特有のセキュリティ機能(IAMやVPC)については今後にまわします。

 

とりあえず、パッと思いつくユーザ認証のセキュリティ周りは以下くらいかなと思うので、実際に手を動かして設定していきます。

1.root直ログイン禁止/パスワードログイン禁止

rootユーザというのは、WindowsにおけるAdministratorみたいなもの(当然いろいろ違う)で、いわゆる何でもできてしまうユーザです。仮に悪意のある第三者にこのユーザを乗っ取られると詰みます。将棋でいうところの王にあたり、何が何でも死守する必要があります。

 

そのため、rootユーザの直接なログインは禁止してしまって、rootユーザ権限が必要な場合は、後述する「sudo」や「su」コマンドで間接的に使用するのが一般的です。

 

あと、パスワードログインを許可していると総当たり攻撃というパスワード解読攻撃の的になるため禁止し、後述する公開鍵認証によりログインするのが一般的です。総当たり攻撃、英語で言うとブルートフォースアタックと言うらしいです。ロボアニメとかの必殺技っぽいですね。

 

尚、AWSはデフォルト(初期設定)でrootユーザへの直ログインとパスワードログインは禁止されているので、今回はその設定をわざわざ解除したり、再度設定したりしてみます。

 

AWSを利用するまでの手順とかはまた今度書きたいと思います。結構公式ヘルプがしっかりしていて、登録からEC2インスタンス作成・ログインまで1時間もかかりませんでした。すごい時代ですね。余談ですが、AWSへの登録にはクレジットカードが必要になります。持ってない学生さんとかはVプリカとかを利用しましょう。今のところ(2017/4/16現在)Vプリカで登録可能みたいです。

 

前置きが長くなりましたが、EC2インスタンス(仮想サーバ)を作成しteratermというツールで自分のPCからログインしました。初期ログイン可能なユーザは「ec2-user」となります。

 

f:id:gattsu09:20170416181626p:plain

 

SSHログインの設定は「/etc/ssh/sshd_config」ファイルが担っているので、こちらの設定を以下の通りに変更していきます。

 

<sshd_config変更前>
 PermitRootLogin forced-commands-only

  ⇒特定のコマンド実行時のみrootへのログインを許可
 PasswordAuthentication no

  ⇒パスワードログインを禁止

 

<sshd_config変更後>

 PermitRootLogin yes

  ⇒rootへのログインを許可

 PasswordAuthentication yes

  ⇒パスワードログインを許可

 

 <実行コマンド>

①.sshd_configをバックアップしviエディタで編集

$ cd /etc/ssh
$ sudo cp -ip sshd_config sshd_config.20170416
$ sudo vi sshd_config 

 ②.編集結果をdiffコマンドで確認

$ diff sshd_config sshd_config.20170416
51c51
< PermitRootLogin yes
---
> PermitRootLogin forced-commands-only
82c82
< PasswordAuthentication yes
---
> PasswordAuthentication no
158c158
< # ForceCommand cvs server
---
> # ForceCommand cvs server
No newline at end of file

 ③.sshdを再起動

sudo /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]

 ④.rootユーザのパスワードを適当に変更

$ sudo passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully. 

 

再度teratarmで今度はrootユーザでパスワードを入力しログインしたところ、正常にログインできました。セキュリティ強度がグンと下がったことになります。やりましたね!

f:id:gattsu09:20170416182502p:plain

 

怖いので、バックアップを戻して再度sshdを再起動します。 

$ sudo mv sshd_config.20170416 sshd_config
$ sudo /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]

 

f:id:gattsu09:20170416184112p:plain

再度rootで同様にパスワードログインを試みたところ、上記エラーがにより失敗しました。よかったですね。

 

 

2.SSHによる公開鍵認証ログイン設定

引き続き、SSHによる公開鍵認証のログイン方法について学んでいきます。1つめの項目で該当サーバへのパスワードログイン禁止方法について書きましたが、ではどうやってログインするかというと公開鍵認証という方式をつかって、事前に作成・配布した鍵を持っているユーザ(PC)からのみログインを許可してあげます。

 

AWSはEC2インスタンス作成時、その鍵が生成され自動でダウンロードされ、初期ユーザであるec2-userはその鍵を使ってログインすることができます。

 

今回はEC2インスタンス作成・ログイン後、Linuxサーバ内でコマンド実行により、SSH鍵生成・配布し、その鍵を使ってログインできるか試していこうと思います。

 

とりあえず、1と同様にec2-userでログインし、ホームディレクトリ「/home/ec2-user」配下に「.ssh」ディレクトリが存在することを確認します。

 

$ ls -l .ssh
total 4
-rw------- 1 ec2-user ec2-user 388 May 1 10:58 authorized_keys

 

ec2-userは既にSSHの鍵設定が行われているので「.ssh」ディレクトリが存在します。新規ユーザ等で存在しない場合は作成しましょう。

 

「.ssh」ディレクトリが存在するので、次に「ssh-keygen」コマンドを使用して、SSH鍵を作成します。

 

$ ssh-keygen -t rsa   ←鍵タイプに「rsa」を指定
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa): ←「Enter」
Enter passphrase (empty for no passphrase): ←「パスフレーズを入力」(今回は省略)
Enter same passphrase again: ←「パスフレーズを入力」(今回は省略)
Your identification has been saved in /home/ec2-user/.ssh/id_rsa.
Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub.
The key fingerprint is:
2c:8d:29:ef:ee:9b:ee:0c:e2:0f:fb:cb:9f:85:4c:d9 ec2-user@ip-172-31-31-51
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| B |
| . * E |
| = o |
| o . + . |
| . = + + |
| oo=B%. |
+-----------------+

 

すると、「.ssh」配下に、秘密鍵(id_rsa)と公開鍵(id_rsa.pub)の2ファイルが作成されます。接続する側は秘密鍵を使って対象のサーバに接続します。接続される側は、アクセスがあると公開鍵を使って認証を行います。細かくいうと長くなるので、どこかであらためてまとめたいと思います。

 

$ ls -l .ssh
total 12
-rw------- 1 ec2-user ec2-user 388 May 1 10:58 authorized_keys
-rw------- 1 ec2-user ec2-user 1679 May 1 11:07 id_rsa
-rw-r--r-- 1 ec2-user ec2-user 406 May 1 11:07 id_rsa.pub

 

続いて、公開鍵の情報を「authorized_keys」に格納します。先述したとおり、「ec2-user」はすでにSSH鍵設定済みなので、すでに「authorized_keys」ファイルが存在します。その場合は、以下の通りに公開鍵情報を追記します。

 

$ cd .ssh

$ cat id_rsa.pub >> authorized_keys 

 

既存の情報を消したりすると、先ほどまでログインできた既存の秘密鍵でもログインできなくなるので注意が必要です。

 

ちなみに「authorized_keys」が既に存在する場合は、以下の通りに設定します。

 権限までしっかり設定してあげないとログインできません。

 

$ cd .ssh

$ mv id_rsa.pub authorized_keys

$ chmod 600 authorized_keys

 

公開鍵の設定は済んだので、接続する端末(この場合自分のPC)に秘密鍵を転送します。今回はteratermのSCP機能を使って転送しました。

 

[ファイル]-[SSH SCP]を選択

f:id:gattsu09:20170501205007p:plain

 

下枠の「From」に秘密鍵をフルパスで記入。取得先に任意のフォルダを指定し、[Receive]ボタンをクリック。

f:id:gattsu09:20170501205036p:plain

 

指定したフォルダに「id_rsa」ファイルが存在することを確認します。その後、再度teratermを起動し、「ec2-user」ユーザを入力し、今回転送した秘密鍵を選択し[OK]ボタンをクリック。

f:id:gattsu09:20170501205233p:plain

 

無事ログインできました。エラーになる場合は権限設定などを見直しましょう。

f:id:gattsu09:20170501205343p:plain

 

公開鍵認証ログインの設定は以上です。余談ですが、SSH鍵はLinuxサーバ内だけでなくクライアント側でも作ることができます。

 

teratermの場合[設定]-[SSH鍵の設定から作成可能で、その場合は逆に公開鍵を接続先のサーバに配布し、同様に「authorized_keys」に公開鍵情報を登録すると、作成した秘密鍵で接続可能になります。どちらかというと、クライアント側で鍵を生成した方がセキュリティ的には良いみたいですね。

 

f:id:gattsu09:20170501205750p:plain

 

というわけで、公開鍵認証によるログイン設定について書きました。細かい認証の流れとか勉強してると、すごく複雑に見えて(実際複雑)うんざりするのですが、とりあえず動かしてみて、感じをつかんだ後に詳細について学ぶのも一つじゃないかなぁと思います。

 

3.SSH接続用のポート番号変更

ではSSH接続用のポート番号を変更していきます。

 

その前に、ポート番号とは何か?について自分自身のおさらいもかねて学んでいきたいと思います。軽くWebで調べたところ、個人的に以下の記事がしっくり分かりやすかったです。

 

ポート番号とは、TCP/IP通信において、 コンピュータが通信に使用するプログラムを識別するための番号です。
ポート番号は16ビットの整数であり、 0番~65535番まであります。

TCP/IP通信においては、 IPアドレスがあればネットワーク上のコンピュータを一意に識別することができますが、 該当コンピュータのどのプログラムに通信パケットを届けるかは、 IPアドレスだけでは決定できません。 どのプログラムに通信パケットを渡すのかを決定するために、 ポート番号を使用します。

 

引用元:日本ネットワークインフォーメーションセンター

 

IPアドレスは、よく住所にたとえられる(アドレスっていうくらいだし)のですが、PCやサーバが「家」でIPアドレスが「住所」だとすると、ポート番号は「郵便ポストの番号」というのが個人的にはしっくりくる例えになります。ただ、この郵便ポストめちゃくちゃ数が多く65536個(0~65535)あります。

 

送り元は手紙(データ)を送る際、どの住所(IPアドレス)のどの郵便ポスト番号(ポート番号)に手紙(データ)を送るかを指定する必要があるわけです。

 

そして、データを受け取る側(PC、サーバ)は、例えば「22」番の郵便ポスト(ポート番号)からの(データ)しか受け取らない設定もできます。これによって、他の郵便ポスト番号(ポート番号)経由の手紙(データ)は不審な手紙(データ)として破棄できたりします。

 

また、ポート番号は0番~1023番まではよく使うポート番号として予約されています。その内、今回話の対象とするSSHは「22」番を使って通信するとあらかじめ決まっています。

 

ここからが本題です。ポート番号は規約を統一することによって他PCやサーバとの通信を容易にするという役割が強いのですが、上記にあげたように受け付けるポート番号を絞ることでセキュリティ強度を上げる役割があります。

 

ただ、SSHの通信はデフォルトでは「22」番を使うということは全世界に知れ渡っているため、悪意のある第3者から攻撃を受けた場合、デフォルトのままだと受け付けるポート番号を絞ったところで無意味となってしまいます。

 

というわけで、SSHが使用するポート番号をデフォルト「22」から別のポート番号変えることで、セキュリティ強度を増そうという狙いになります。少なくとも、とりあえずポート番号「22」に対して攻撃してくる輩を弾くことができます。

 

果てしなく前置きが長くなりましたが、具体的な設定方法について触りながら書いていきます。

 

①ログインしrootユーザにスイッチする

$ id
uid=500(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel)
$
$ sudo -s
# id
uid=0(root) gid=0(root) groups=0(root)

 

②sshd_configファイルを編集する

# cd /etc/ssh

# cp -ip sshd_config sshd_config.20170502

# vi sshd_config

※ 「# Port 22」の「#」を外し数字部分を「12345」に変更

# diff sshd_config sshd_config.20170502

17c17
< Port 12345
---
> #Port 22
158c158
< # ForceCommand cvs server
---
> # ForceCommand cvs server 

 

③sshdを再起動する

 # /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ] 

 

④AWS上で通信許可のポート番号変更

AWSでは「セキュリティグループ」というサービスで上記に記載した、「受け付けるポート番号を絞る」等の設定がされており、デフォルトで「22」ポート番号の通信のみ許可するようになっています。そのため、許可するポート番号を「22」から「12345」に変更します。

 

[EC2ダッシュボード]-[インスタンス]にて対象のインスタンスを選択。下枠のセキュリティグループをクリック。

f:id:gattsu09:20170502195038p:plain

 

[インバウンド]タブを選択し、[編集]をクリック

f:id:gattsu09:20170502195059p:plain

 

タイプに「カスタムTCPルール」を選択し、ポート番号に「12345」を入力し「保存」をクリック

f:id:gattsu09:20170502195107p:plain

以上で、SSHポート番号変更作業は完了しました。 

ログインできるか試します。teratermでポート番号12345を指定しログイン。

f:id:gattsu09:20170502195343p:plain

 

f:id:gattsu09:20170502195402p:plain

ポート番号12345でログインできました。よかった。

ちなみに、元のポート番号22番を指定するとログイン画面すらでず以下のエラーが返ってきます。

 

f:id:gattsu09:20170502195447p:plain

 

これで、「SSHのデフォルトポート22番をとりあえずアタックする」輩からの脅威からは逃れることができるようになりました。

 

4.ログイン用ユーザ設定

 

じゅんびちゅう

5.適切なsudo設定

じゅんびちゅう