2011/03/31

初心者向け、さくらのVPS(CentOS)を借りたらチェックしておきたいサイト集

初心者向け、さくらのVPS(CentOS)を借りたらチェックしておきたいサイト集

レンタルサーバの老舗、さくらインターネットが提供する980円のVPSサービス、さくらのVPS 。

低価格にも関わらず、非常に軽快に動作するという事で結構話題になってるんだけど、借りた状態では通常の共用サーバで提供されているようなFTP・WEBサーバといった機能は利用出来ない。
そこで、初心者さん向けにさくらのVPSについて解説されているサイトや、チェックしておいた方が良いサイトを集めてみる。
（随時更新）
あった方が良いソフトウェア
PuTTY
SSHクライアント。
さくらで用意されているコンソールは確かに便利で凄いと思うけど、やはり専用クライアントの方が…。
WinSCP
SCPクライアント。主にファイル操作に利用。
FTPクライアントとして、FFFTPとかNextFTPとかを使ってる人は、何となくインタフェイス似てる気がするのでとっつきやすい気がする。
ファイル転送にSCPを使えば、通常のWEBサーバの場合、SSHポートとHTTPポートのみをあければ済むことになりFTP設定不要かつセキュアでとっても良い気がする。
チェックしておきたい記事
【さくらのVPS】初期設定をしてみたUntitled Documents.
非常に丁寧にあくまで最低限の設定について解説されている。
初心者でもググりつつ設定すれば比較的容易に「何をしているのか」理解可能な部類。
さくらのVPSを借りたら真っ先にやるべきssh設定-myfinder’s blog
さくらの田中社長のツイッターで紹介されていたブログ。
sudoって何？ってレベルの人はググりつつ…。
CentOSをサーバーとして活用するための基本的な設定
言わずと知れたさくらインターネットの田中社長のブログ。
最低限やって欲しいセキュリティの設定と、不要なサービスの停止（より軽快に動作させるための設定）などが紹介されている。
iptablesの設定についても触れられている。・・・けど、一癖ある系なので、「自分が何をやっているか理解」して作業できる人向け。
さくらの VPS の設定ダダ流し-ゆっくり…して…イってネ！
上で挙げた、最低限のセキュリティ設定～LAMPP環境構築までを非常に親切に解説されている。
iptablesの記述例も公開されていて、そのまま使っても十分使える設定だと思う。
何か追加で「Wordpressのインストール」までのまとめも公開されている。
CentOS5.2にPHP5.2をyumでインストール-つれづれなる備忘録
PHP5.2系をyumでインストール方法が紹介されている。
思う事
あちこちのブログ記事を参考に設定していると、いずれ何が何だかわからなくなって、詰まると思うけど、コントロールパネルからのOS再インストールが可能なので、何度も設定に挑戦している内に設定の意味等も解ってくると思うです。
そういう意味ではさくらのVPS、学習用としても非常にお手軽かもしれない。
動作が軽快だからストレスも少ないし。
自分とこの記事
yumでのインストールにこだわってみた。
あくまで「とりあえず」だけど。

0 コメント

さくらのVPSを借りたら真っ先にやるべきssh設定

MYFINDER'S BLOG

myfinderの技術や周辺的活動のblog

2010年9月23日木曜日

さくらのVPSを借りたら真っ先にやるべきssh設定

遅ればせながらさくらのVPS借りてセットアップしてます。
インターネットに晒すサーバを立てるときはまずセキュリティ設定をしっかりやってからIPを振るべきですが、さくらのVPSではそういうわけにもいきません。

なので、借りて真っ先に設定するべきssh設定について、自分がやっていることをまとめておきます。
今回はデフォルトの CentOS5.5(x86_64) でのやり方です。

1.ログインする

VPSを起動したらまずログインしてください。

2.ユーザ作成

作業用のユーザを作成します。

view plainprint?
  1. # useradd myfinder  
  2. # passwd myfinder  
  3. # usermod -G wheel myfinder  


あとで root になれるユーザを制限するために wheel に所属させておきます。

3.ユーザの公開鍵を登録

作業用ユーザがリモートから入れるようにします。
ノーパスワードの設定はおすすめしません。

view plainprint?
  1. # su - myfinder  
  2. $ ssh-keygen -t rsa  
  3. $ vi ~/.ssh/authorized_keys  


そのうち要ると思うので.sshを作っときます。
作成した authorized_keys に、作業するPCで作成した公開鍵を書いて、パーミッション設定を変えてください。

view plainprint?
  1. $ chmod 600 ~/.ssh/authorized_keys  


4.sshdの設定変更

パスワードでの認証をやめ、公開鍵認証でのログインに限定します。

view plainprint?
  1. # vi /etc/ssh/sshd_config  
  2. // no に設定  
  3. PermitRootLogin no  
  4. PasswordAuthentication no  
  5. UsePAM no  
  6. # /etc/init.d/sshd restart  


※umqさんの指摘でUsePAMの所を追加しました。ありがとうございます。
この時点でコンソール以外からのログインが不可能になります。

ここまでやったら作業用PCからログインして確認してください。

5.sudoの設定

作業用ユーザで sudo ができるよう設定を変更します。

view plainprint?
  1. # visudo  
  2. // コメント外す  
  3. %wheel  ALL=(ALL)       ALL  


wheel に所属しているユーザが sudo できるようにします。
さきほど作業用ユーザは wheel に所属しているので、 sudo できるようになっている筈です。
下記のような感じで root になれるか確認するのがいいと思います。

view plainprint?
  1. $ sudo su -  
  2. #  


6.rootパスワードの無効化

この時点で
・リモートからのパスワード認証不能
・公開鍵に対応する秘密鍵を持ったクライアントからのログイン以外不能
という状況になってます。

現実的にはこれでほぼほぼ問題ないと思いますが、rootのパスワードを管理したくないので、自分はよくこれを無効化しています。

view plainprint?
  1. # passwd -l root  
  2. // とやると、/etc/shadowの内容が  
  3. root:!!hogehogehogehogehoge:xxxxx:0:99999:x:::  
  4. // という感じに無効化される  


こうしておけば
・リモートからのパスワード認証不能
・公開鍵に対応する秘密鍵を持ったクライアントからのログイン以外不能
・コンソールからの root ログイン不能
・作業用ユーザが sudo しない限りは root になることは不能
という感じになります。

ここまでの作業で、ログインして root になれるユーザを制限し、 root になるための手段を一本道にすることができました。

※h2ondaさんの指摘でrootのパスワードを無効化する所を変更しました。ありがとうございます。

7.sudoのログを取る

更に、 sudo した内容を syslog に記録する設定をします。
ここまでやっておけば、誰がいつ sudo したかが記録に残ります。

view plainprint?
  1. # visudo  
  2. // 追記  
  3. # syslog facility  
  4. Defaults syslog=local3  
  5.   
  6. # vi /etc/syslog.conf  
  7. // 追記  
  8. # sudo log  
  9. local3.*                                                /var/log/sudo  


※kamipoさんの指摘でvisudoの所を追加しました。ありがとうございます。

view plainprint?
  1. # touch /var/log/sudo  
  2. chmod 600 /var/log/sudo  


facility を local3 にしているのは、後でbindを立てる予定だからです。
これで /var/log/sudo に sudo した結果が下記のように残ります。

view plainprint?
  1. # cat /var/log/sudo  
  2. Sep 23 20:01:41 hostname sudo: myfinder : TTY=pts/1 ; PWD=/home/myfinder ; USER=root ; COMMAND=/bin/su -  


複数台の環境ならば、このログを外部のsyslogサーバに転送すれば更によいと思います。
このログはこのままだと太っていってしまうので、 /etc/logrotate.d/syslog のローテーションに加えておきましょう。

view plainprint?
  1. /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron /var/log/sudo {  
  2.    sharedscripts  
  3.    postrotate  
  4.    /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true  
  5.    /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true  
  6.    endscript  
  7. }  


8.おわりに

ここまでやれば、割と安心してリモートから作業したり、運用できるかなと。
ただ、6と7については、やりたい人/必要な人がやればいいと思います。

作業用ユーザのパスワード忘れちゃったりした場合、コンソールから再起動してシングルユーザモードで入ればよいでしょう。

では。

0 コメント
登録: コメント (Atom)