さくらのVPS を改めて使いはじめる 10 – Git、Gitolite、GitHub

2012年6月3日 2 開発 , , , , ,

さくらのVPS(v3) 2GB プランへの環境構築メモ 10。今回は Git 関連について書く。

シリーズまとめ – さくらのVPS を改めて使いはじめる

もくじ

Git

後述する作業のため Git 環境を整える。

さくらのVPS(v3) の CentOS だと初めから Git が入っているらしく、このシリーズでも既に何度か利用している。パッケージ版なので yum update により更新されている可能性もあるが、念のためどんなバージョンが入っているか確認。

$ git --version
git version 1.7.1

すこし古いけど現時点の最新版である 1.7.10 と同じ 1.7 系なのでよしとする。

次は Git のリポジトリ ルートを作成する。GitHub や Gitolite のリポジトリからミラーリングしたり Redmine から参照する Git リポジトリはここへ置く。

$ sudo mkdir /var/lib/git

VPS 上で開発しないなら不要かもしれないが Git 自体の設定もおこなう。git config –list で現在の Git 設定が出力される。何もしていないなら以下のようにエラーとなるはず。

$ git config --list
fatal: error processing config file(s)

設定を追加。まずはユーザーと、その識別に使用されるメールアドレス

$ git config --global user.name XXXX
$ git config --global user.email XXXX@example.com

次にカラー設定。VPS 上で Diff を見る場合などに有用。

$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto
$ git config --global color.interactive auto

設定を確認。

$ git config --list
user.name=XXXX
user.email=XXXX@example.com
color.diff=auto
color.status=auto
color.branch=auto

ばっちり。

Gitolite のセットアップ

VPS 上へ Git のリモートリポジトリを構築するために Gitolite を導入する。このツールについては、以下の記事がわかりやすい。

SSH 接続用の鍵と設定ファイル作成

ローカルマシン上で VPS 上の Gitolite へ SSH 接続するための鍵ファイルを作成する。作成方法については前述の記事かこのシリーズ第一回の「SSH 接続用の鍵を作成する」あたりを参考のこと。

ここでは、パスフレーズなしで秘密鍵 gitolite と、公開鍵 gitolite.pub を作成したものとする。

鍵ファイルを作成したらローカルのユーザー HOME 直下にある .ssh ディレクトリ内に移動させる。Windows Vista/7 なら C:\User\ユーザー名.ssh、Mac OS X や Linux なら ~/.ssh になるはず。

.ssh フォルダがなければ作成しておく。Windows の場合、Explorer からだと . で始まるフォルダは作成できないのでコマンドプロンプトから mkdir を実行すること。

鍵ファイルを .ssh フォルダに移動したら同じ場所に config という名前 ( 拡張子はなし ) のテキスト ファイルを作成する。このファイルは Windows なら msysGitGit Extensions、Mac ならターミナルからの SSH で参照される。

ファイルを作成したら以下の内容を記述して保存する。example.com となっている部分は自分の VPS に割り当てているドメイン名か IP アドレス、PORT の XXXX には SSH 接続するときのポート番号を数字で指定する。すでに config ファイルが存在する場合は、その中の末尾に追記しておく。

HOST gitolite.example.com
    HOSTNAME     example.com
    USER         gituser
    PORT         XXXX
    IDENTITYFILE ~/.ssh/gitolite

それぞれの設定項目の意味は以下のようになる。

設定 内容
HOST 接続設定の識別子。次に host という名前が出現するまでが、ひとつの設定となる。git コマンドなどで接続先にこれを指定すると、以降の内容が使用される。複数の接続設定を記述する場合は、重複しないようにすること。
HOSTNAME 接続先となるホスト名。サーバーのドメイン名、または IP アドレスを指定する。
USER 接続先でログインするサーバー上のユーザー名。今回は VPS 上に gituser という Gitolite 管理用ユーザーを作成するので、その名前を指定している。
PORT SSH 接続に使用するポート番号。デフォルトは 22。もしポート番号を変更しているなら、その番号を指定する。
IDENTITYFILE 接続に使用する秘密鍵ファイルへのパス。~ ( チルダ ) はローカルマシン上のユーザー HOME を表す。

詳細は以下を参照のこと。

ここまでの作業で .ssh フォルダには以下のファイルがそろったはず。

ファイル 内容
gitolite 秘密鍵ファイル。ローカルマシンから VPS 上の Gitolite へ接続するために使用する。
gitolite.pub 公開鍵ファイル。VPS 上の Gitolite が使用する。
config SSH 接続用の設定ファイル。

最後に公開鍵ファイルを VPS 上にアップロードする。

Windows なら Tera Term や WinSCP、Mac の場合はターミナルから scp コマンドを実行する。ここではいつも VPS 上でログインしているユーザーの HOME 直下gitolite.pub という公開鍵ファイルを転送したものとする。

Gitolite 管理用ユーザーの作成

VPS 上に Gitolite の管理用ユーザーを作成する。名前は gituser としておく。

$ sudo useradd --shell /bin/bash --home /home/gituser gituser

アップロードしておいた SSH 接続用の公開鍵を gituser の HOME へ移動して所有者とパーミッションを変更。

$ cd
$ sudo mv gitolite.pub /home/gituser
$ sudo chown gituser:gituser /home/gituser/gitolite.pub
$ sudo chmod 644 /home/gituser/gitolite.pub

念のためファイルを確認。

$ sudo ls -l /home/gituser/
合計 4
-rw-r--r-- 1 gituser gituser 390  5月  26 08:43 2012 gitolite.pub

ばっちり。

Gitolite のインストールと初期設定

準備が整ったので Gitolite をセットアップする。まずはインストールから。さくらのVPS(v3) の CentOS なら yum から入れられる。

$ sudo yum install gitolite
... 中略
Running Transaction
  Installing : 4:perl-Time-HiRes-1.9721-119.el6_1.1.x86_64                                                            1/2
  Installing : gitolite-2.3-2.el6.noarch                                                                              2/2

Installed:
  gitolite.noarch 0:2.3-2.el6

Dependency Installed:
  perl-Time-HiRes.x86_64 4:1.9721-119.el6_1.1

Complete!

バージョンは現時点で 2.3.2。依存モジュールとして Perl 用の高精度タイマーもインストールされたようだ。

次は Gitoite の初期化。

ユーザーを gituser に変更してから、gl-setup コマンドに公開鍵ファイルを指定して実行する。途中、hit enter… と表示されたら Enter キーを押す。すると自動的に vi で Gitolite の設定ファイルが開く。特に変更することはないので :q を入力したあと Enter キーを押して、そのまま終了しておく。

$ sudo su - gituser
$ gl-setup gitolite.pub
The default settings in the rc file (/home/gituser/.gitolite.rc) are fine for most
people but if you wish to make any changes, you can do so now.

hit enter...
creating gitolite-admin...
Initialized empty Git repository in /home/gituser/repositories/gitolite-admin.git/
creating testing...
Initialized empty Git repository in /home/gituser/repositories/testing.git/
[master (root-commit) 24eee08] start
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/gitolite.pub

公開鍵はもう必要ないので消しておく。

$ rm gitolite.pub

gituser の HOME 直下に、Gitolite 関連のファイルやディレクトリが作成されているので確認してみる。

$ ls -l -a
合計 44
drwx------  5 gituser gituser 4096  5月 26 10:39 2012 .
drwxr-xr-x. 4 root    root    4096  5月 26 10:17 2012 ..
-rw-------  1 gituser gituser    3  5月 26 10:31 2012 .bash_history
-rw-r--r--  1 gituser gituser   18  5月 11 03:45 2012 .bash_logout
-rw-r--r--  1 gituser gituser  176  5月 11 03:45 2012 .bash_profile
-rw-r--r--  1 gituser gituser  124  5月 11 03:45 2012 .bashrc
drwx------  6 gituser gituser 4096  5月 26 10:34 2012 .gitolite
-rw-r--r--  1 gituser gituser 4217  5月 26 10:33 2012 .gitolite.rc
drwx------  2 gituser gituser 4096  5月 26 10:34 2012 .ssh
-rw-------  1 gituser gituser    0  5月 26 10:34 2012 projects.list
drwx------  4 gituser gituser 4096  5月 26 10:34 2012 repositories

gl-setup で指定した公開鍵ファイルは、自動的に .ssh ディレクトリ内へコピーされている。名前もちゃんと authorized_keys になっている。

Gitolite の設定ファイルは .gitolite.rc となる。あまり変更することはないと思われるが、ファイルの位置だけは覚えておこう。Gitolite を利用してリポジトリを追加した場合は、repositories ディレクトリ内に作成される。デフォルトでは以下の 2 つが用意されているはず。

$ ls -l repositories/
合計 8
drwx------ 8 gituser gituser 4096  5月 26 10:34 2012 gitolite-admin.git
drwx------ 7 gituser gituser 4096  5月 26 10:34 2012 testing.git

Gitolite のリポジトリ設定は gitolite-admin.git に格納される。このツールの特徴でもあるのだがリポジトリやユーザーを設定する場合はリポジトリをローカルに clone して設定ファイルを編集する。変更を反映する場合はそれを Git で push する。リポジトリに対する変更がそのまま Gitolite の操作となるわけだ。実に面白い設計である。

最後に gituser からログアウトしておこう。

$ exit
logout

これで普段 SSH ログインしているユーザーに戻ったはず。

SSH 接続の許可

ローカルから VPS 上の Gitolite へ SSH 接続できるようにするため、設定ファイルを開く。

$ sudo vi /etc/ssh/sshd_config

そして AllowUsers に gituser を追加する。もしこの設定がなければ項目ごと追加しておく。AllowUsers の内容は SSH 接続したいユーザーを半角スペース区切りで列挙する。いつも SSH 接続してログインしているユーザーが XXXX として、gituser を追加した場合は以下のようになる。

# AllowUsers
AllowUsers XXXX gituser

編集が完了したらファイルを保存して、SSH デーモンを再起動する。

$ sudo service sshd restart
sshd を停止中:                                             [  OK  ]
sshd を起動中:                                             [  OK  ]

設定を間違えるとこれまで SSH 接続しているユーザーでログインできなくなるので注意する。念のためもうひとつターミナルを開き、いつものユーザーでログインできることを確認しておいたほうがいい。

もしログインできなくなっていた場合は設定を修正してから SSH デーモンを再起動してログインできることを確認する。

間違えたあとにターミナルを閉じてしまいどうにもならなくなった場合は、さくらのVPS のコントロールパネルにあるリモートコンソールからログインして設定を修正する。ただし、リモートコンソールだと vi で方向キーが効かない ( ダイヤモンドカーソルのみ受け付けるようだ ) ので注意する。

動作チェック

Gitolite のセットアップと SSH 接続の許可が完了したので正常に動作していることを確認するため、はじめから用意されているテスト用リポジトリ testing をローカルマシンへ clone する。

Windows なら msysGit、Mac ならターミナルで適当なフォルダに移動して以下のコマンドを実行する。gitolite.example.com の部分は前述の config ファイルで設定した HOST の名前を指定すること。

$ git clone gitolite.example.com:testing
Cloning into 'testing'...
warning: You appear to have cloned an empty repository.

もし、以下のようなエラーが表示された場合は、config ファイルか、VPS 上の SSH 許可設定が間違っているので、よく見て修正すること。ありがちなのは、config ファイルの USER や ssh_config の AllowUsers 指定ミスである。

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: The remote end hung up unexpectedly

clone できたら、testing フォルダの中に移動して、そこに README.md というテキスト ファイルを作成する、このファイルに適当な内容を記述して保存した後、以下のコマンドで VPS 上のリポジトリへプッシュしてみる。

$ git add .
$ git commit -m 'test commit.'
[master (root-commit) d780560] test commit.
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 221 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitolite.example.com:testing
 * [new branch]      master -> master

成功なら上記のような感じになるはず。実際に push されたことを確認するために、まったく別のフォルダへ移動してから testing リポジトリを clone し直してみよう。

$ git clone gitolite.example.com:testing
Cloning into 'testing'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
$ cd testing
$ ls -l
total 1
-rw-r--r--    1 XXXX  Administ       May  26 11:41 README.md

ばっちり。

ユーザー追加

初期状態の Gitolite には管理者しか存在していないので開発用ユーザーも登録しておく。

前述のSSH 接続用の鍵と設定ファイル作成を参考に新しい鍵と config を追加する。ユーザー名を example とした場合、秘密鍵は gitolite-example、公開鍵は gitolite-example.pub というファイル名にしておく。

.ssh フォルダ内には様々なサービスの鍵ファイルが集約されるので、目的やユーザー名が分かりやすい名前を付けることで混乱を避ける。鍵ファイルを .ssh フォルダに移動した後、config へ以下の内容を追記する。

HOST gitolite.example.com
    HOSTNAME     example.com
    USER         gituser
    PORT         XXXX
    IDENTITYFILE ~/.ssh/gitolite

HOST gitolite-example.example.com
    HOSTNAME     example.com
    USER         gituser
    PORT         XXXX
    IDENTITYFILE ~/.ssh/gitolite-example

HOST と IDENTITYFILE 以外は管理者と同じ設定になる。

次に Gitolite の管理用リポジトリをローカルマシン上に clone する。以降、何度も利用するので clone 先は分かりやすい場所にしておくこと。

$ git clone gitolite.example.com:gitolite-admin
Cloning into 'gitolite-admin'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.

clone されたリポジトリ >gitolite-admin のフォルダ内は以下のような構成になる。

フォルダ 内容
conf リポジトリ設定を格納するディレクトリ。
conf/gitolite.conf リポジトリの設定ファイル。内容はプレーン テキスト。
keydir Gitolite を利用するユーザーの公開鍵を格納するディレクトリ。
keydir/gitolite.pub Gitolite の管理者となるユーザーの公開鍵。VPS 上で gl-setup を実行したときに引数へ指定したファイルになる。

ユーザー登録は keydir に公開鍵を追加することでおこなう。

先ほど作成した鍵のうち gitolite-example.pub を keydir にコピーして、ファイル名を example.pub に変更する。この名前が Gitolite 上のユーザー名となる。.ssh フォルダと異なり keydir は Gitolite ユーザーの公開鍵だけ格納されるので gitolite- という接頭語は不要である。

keydir に鍵を用意したら msysGit の GitBash や Mac のターミナルで gitolite-admin/keydir に移動し、commit してから VPS 上に push する。

$ cd gitolite-admin/keydir/
$ git add .
$ git commit -m 'added example user key.'
[master 0201612] added example user key.
 1 file changed, 1 insertion(+)
 create mode 100644 keydir/example.pub
$ git push
... 中略 ...
remote:
remote:                 ***** WARNING *****
remote:         the following users (pubkey files in parens) do not appear in any access rules:
remote: example(example.pub)
To gitolite.example.com:gitolite-admin
   24eee08..0201612  master -> master

成功すると、上記のような感じになる。このユーザーでリポジトリ操作できることを確認するため testing リポジトリを clone してみる。

$ git clone gitolite-example.example.com:testing
Cloning into 'testing'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.

ばっちり。

リポジトリ作成

ユーザーが作成できたので次はリポジトリを作成してみる。ローカルに clone した >gitolite-admin の中にある conf/gitolite.conf をテキストエディタで開く。すると以下のような状態になっているはず。

repo    gitolite-admin
        RW+     =   gitolite

repo    testing
        RW+     =   @all

repo で始まる行がリポジトリ設定の開始となり repo の後に続くものがレポジトリ名である。次の行にある RW+ がレポジトリの読み書き属性で R が読み取り、W は書き込み、+ を付けると Git の reset コマンドを許可する設定となる。属性とイコールで結ばれた先が属性に関連づけるユーザー名となる。

上記の例で説明すると gitolite-admin は管理者 gitolite によって RW+ が可能、testing は全てのユーザーで RW+ が可能となる。

Gitolite によるリポジトリの増減はこのファイルの設定と push によっておこなう。今回は new-repo という名前のリポジトリを追加し全ユーザーに R、example というユーザーだけに RW を許可してみる。gitolite.conf へ以下のように追記してファイルを保存する。

repo    gitolite-admin
        RW+     =   gitolite

repo    testing
        RW+     =   @all

repo    new-repo
        R      =   @all
        RW     =   example

ファイルを保存したら msysGit の GitBash や Mac のターミナルで gitolite-admin/conf に移動し、commit してから VPS 上に push する。

$ cd gitolite-admin/conf/
$ git add .
$ git commit -m 'added new-repo repository.'
[master 10cbb2e] added new-repo repository.
 1 file changed, 4 insertions(+)
$ git push
... 中略 ...
remote: creating new-repo...
remote: Initialized empty Git repository in /home/gituser/repositories/new-repo.
... 後略

成功すると上記のようになる。push 後のメッセージを読むと new-repo という空のリポジトリが作成されたとあるので、さっそく適当な場所に clone。

$ git clone gitolite-example.example.com:new-repo
Cloning into 'new-repo'...
warning: You appear to have cloned an empty repository.

ばっちり。

レポジトリを削除する場合は gitolite.conf から設定を削除して commit & push する。例えば先ほどの new-repo を削除したあと再び clone を試みると…

$ git clone gitolite-example.example.com:new-repo
Cloning into 'new-repo'...
R access for new-repo DENIED to example
(Or there may be no repository at the given path. Did you spell it correctly?)
fatal: The remote end hung up unexpectedly

といったエラーとなり clone に失敗する。ただし VPS 上に作成されたリポジトリの実体は残っているので不要ならサーバーにログインして完全に削除しておく。

$ sudo su - gituser
$ cd repositories
$ rm -rf new-repo.git
$ exit

Gitolite のリポジトリを Redmine から参照する

Gitolite のリポジトリと Redmine プロジェクトの連携を試してみる。

Gitolite リポジトリに対するにミラー ( bare ) リポジトリを作成し、Redmine からはそれを参照する。今回は Gitolite にデフォルトで用意されている testing リポジトリで試す。

VPS にログインした後、先に用意しておいた Git のリポジトリルートに移動し、ミラーリングリポジトリを生成する。用意できたらリポジトリのディレクトリ所有者を Redmine のユーザー:グループ ( このシリーズの手順 で環境構築しているなら、いつも SSH 接続でログインしているユーザー ) に変更して Redmine から参照できるようにする。

$ cd /var/lib/git
$ sudo git clone --mirror /home/gituser/repositories/testing.git
$ sudo chown -R XXXX:XXXX testing.git

ここからは Redmine 上の作業となる。まず Redmine にログインし、Git リポジトリを関連づけるプロジェクトを開く。そしてメニューから「設定」→「リポジトリ」を表示。

![Redmine の設定画面](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-01.png "Redmine の設定画面")

新しいリポジトリボタンを押してリポジトリ設定を表示する。そして以下のように指定したら作成ボタンを押す。

![新しいリポジトリ](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-02.png "新しいリポジトリ")

これにて関連づけ完了。プロジェクトのメニューからリポジトリを表示してみる。

![Gitolite からのミラーリポジトリ表示](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-03.png "Gitolite からのミラーリポジトリ表示")

ばっちり。もし 404 エラーが出る場合はリポジトリのパスや参照するディレクトリのパーミッション、所有者の設定を見直してみること。

GitHub のリポジトリを Redmine から参照する

GitHub 上のリポジトリを Redmine から参照する場合も Gitolite と同様にミラーリポジトリを作成すればよい。まず GitHub 上のリポジトリページを開きページ上部の Git Read-Only ボタンを押して読み取り専用 URL を得る。

![GitHub](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-04.png "GitHub")

次に VPS へログインし GitHub 上から得た URL を指定してミラーリポジトリを作成。そして所有者を Redmine 用に変更する。

$ cd /var/lib/git
$ sudo git clone --mirror git://github.com/akabekobeko/WP-Nicodo.git
$ sudo chown -R XXXX:XXXX WP-Nicodo.git

Gitolite の時と同様に Redmine 上でリポジトリの作成画面を表示、以下のように設定して作成ボタンを押す。

新しいリポジトリ その 2

リポジトリ画面を開き確認。

GitHub からのミラーリポジトリ表示

Gitolite、GitHub ともに参照だけなら今回の設定でよいが、このままだとリポジトリの push が反映されない。

同期する場合はミラーリポジトリに対して git fetch を実行すればよいのだが手動でおこなうのは面倒である。そのため cron などで定期実行するか push をハンドリングしてオンデマンドに実行されるようにしたい。その方法も書きたかったのだけど、記事があまりにも長くなりすぎたのと GitHub 側の方法を検討中なので次に持ちこす。

というわけで、今回はここまで。次回は Gitolite や GitHub の push をハンドリングして、ミラーリポジトリへ自動反映する方法を検討してみる予定。

さくらのVPS を改めて使いはじめる 2 – sudo と SSH ポート変更

2012年4月16日 13 開発 , , ,

さくらのVPS(v3) 2GB プランへの環境構築メモ 2。今回は sudo 設定、SSH のポート変更をおこなう。

もくじ

sudo を設定する

サーバーで root 権限が必要になったとき su コマンドで root になるのは好ましくない。su を実行すると明示的にログアウトするまで root になる。そのため通常はアクセスできないファイルなどを操作してしまう可能性があり非常に危険である。

このような問題への対応として UNIX 系の OS には sudo コマンドが用意されている。

$ sudo 実行したいコマンド

上記のように指定することで、sudo の後に続けたコマンドを root 権限で実行できる。

sudo の場合、root 権限は一定時間が経つと自動的に失われるため、危険な状態が継続される心配も少ない。さらに実行したコマンドのログが取られるため、root 権限を求めるような重要操作が、いつどのようにおこなわれたのかを後で振り返ることもできる。

というわけで、sudo を設定してみよう。まずはコマンドがインストールされていることを確認する。

$ yum list installed | grep sudo
sudo.x86_64             1.7.4p5-7.el6   @anaconda-CentOS-201112091719.x86_64/6.2

上記のように表示されたら OK。なければ yum install sudo を実行してインストールしておく。

次に、sudo を利用するユーザーを wheel グループに追加する。

wheel とは、root 権限を得られる特別なユーザー グループである。ここにユーザー追加する場合は usermod コマンドを実行する。root 権限が必要なので以下のように実行する。

$ su -
Password:
# usermod -G wheel XXXX

XXXX の部分がユーザー名になる。これで XXXX は wheel に追加されたはず。念のため、id コマンドで所属を確認しておく。下記のように 10(weel) という表記が存在していれば成功。

# id XXXX
uid=500(XXXX) gid=500(XXXX) groups=500(XXXX),10(wheel)

次は、wheel グループに属するユーザに対して sudo コマンドの実行を許可する。root になっている状態で visudo コマンドを実行する。

$ su -
Password:
# visudo

コマンドを実行すると、sudo の設定ファイルを編集するために vi が起動される。その中には、wheel の実行権限がコメントアウトされているので、

## Allows people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL

以下のように解除して、ファイルを保存する。

## Allows people in group wheel to run all commands
%wheel        ALL=(ALL)       ALL

これで sudo が利用できるようになった。

ここままだと root になっているため Ctrl + D を押して root から抜けておくこと。以降、root 権限が必要になった場合は、sudo を通してコマンドを実行するようにする。

コマンドのパスを通す

sudo を通して実行するようなコマンドは /usr/sbin/usr/local/sbin に置かれていることが多い。

一般ユーザーだとこれらのディレクトリにパスが通っていないため、コマンド呼び出しにフルパスの指定が必要で非常に面倒。そこでさきほど sudo を許可したユーザーに対しパスを通しておく。

ユーザーの HOME に移動して .bash_profile というファイルの存在を確認する。

$ cd
$ ls -l -a
合計 28
drwx------  3 XXXX XXXX 4096 Apr  1 01:03 .
drwxr-xr-x. 3 root root 4096 Mar 29 23:50 ..
-rw-------  1 XXXX XXXX  354 Apr  1 01:11 .bash_history
-rw-r--r--  1 XXXX XXXX   18 Dec  2 23:27 .bash_logout
-rw-r--r--  1 XXXX XXXX  176 Dec  2 23:27 .bash_profile
-rw-r--r--  1 XXXX XXXX  124 Dec  2 23:27 .bashrc
drwx------  2 XXXX XXXX 4096 Apr  1 01:03 .ssh

次にこのファイルを vi で開く。

$ vi .bash_profile

ファイルを開いたら以下のようにパス設定を加える。

# User specific environment and startup programs

PATH=$PATH:$HOME/bin
PATH=$PATH:/sbin
PATH=$PATH:/usr/sbin
PATH=$PATH:/usr/local/sbin

4 ~ 6 行目が追加した部分となる。編集が完了したらファイルを保存する。設定は再ログインするか以下のコマンドを実行することで反映される。

$ source ~/.bash_profile

SSH のポート変更

sudo を設定できたので、実際に root 権限が必要な操作をおこなってみる。

いままで SSH 接続にポート 22 番を使用してきたが、これは一般的なポートとしてよく知られているため、そのままにしておくと攻撃対象になる。攻撃者は 22 番が空いていることがわかると、ユーザーとパスワードを総当たりで侵入を試みるので、初歩的な対処としてポート番号を変更する。

以下のコマンドで sshd ( SSH デーモン ) の設定ファイルを vi で開く。さっそく sudo の出番がきた。

$ sudo vi /etc/ssh/sshd_config

/etc/ssh の直下には、今回の編集対象となる sshd_config とよく似た ssh_config というファイルがあるので、間違わないように注意する。正しいものは sshd_config である。

ファイルを開くと Port 22 という設定があるので、適当な数値を設定する。値は 0 ~ 65535 を指定できる。攻撃者がポート検索を早々に諦めるよう、あるていど大きな数値にしておくとよい。

#       $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
Port XXXXX

13 行目が元の設定で、14 行目が新しい値。XXXXX の部分に数値を入れる。この例では元の設定をコメントアウトして残しているが、不要なら消してもよい。

設定してファイルを保存したら、sshd を再起動する。成功すれば、以下のように OK と表示される。

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

設定が適切に反映されているなら TeraTerm や WinSCP などでポート 22 番を指定して SSH 接続するとエラーになるはず。その場合は新しいポート番号を指定することで従来どおり接続できる。

Mac や Linux から SSH コマンドで接続する場合は以下のようにポート指定する。

$ ssh XXX@YYY.YYY.YYY.YYY -p ZZZZZ

XXX がユーザー名、YYY.YYY.YYY.YYY が接続先の IP アドレス ( またはドメイン )、-p パラメータの ZZZZZ がポート番号の指定となる。いままでは -p を省略するか 22 番にしていたが、今後は新しいポート番号を指定すること。

…今回はここまで。次回は iptables と logwatch などを設定する。

さくらのVPS を改めて使いはじめる 1 – 使用準備、SSH 公開鍵認証

2012年4月15日 26 開発 , , , ,

これまで運用してきたブログと趣味の開発用サーバーを、この春はじまった「さくらのVPS 2GB」プランに集約することにしたので環境構築の手順を記録してゆく。

ブログは既に移行しており本記事は新サーバー上で公開している。開発用サーバーについては Ruby 1.9 系に対応するという Redmine 1.4 待ちだったが 4/14 にリリースされたようなので、これから構築する予定。

基本的な構築の流れは 2 年ほど前に書いたさくらのVPS を使いはじめるシリーズを踏襲する。ただしデフォルトの OS が CentOS 5.x から 6.2 へ更新されていたり WordPress ブログを移管するため、差分は多くなるかもしれない。

もくじ

さくらのVPS 2GB を契約した動機

これまでブログをさくらのレンタルサーバ スタンダード、開発用サーバーはさくらのVPS 512MB で運用していた。

管理するサーバーが複数あるのは面倒で金銭的にもったいないため、以前からこれらを VPS 側へ集約したいと思っていた。しかし VPS のスペックがいまひとつなのとブログで利用してきたドメイン akabeko.sakura.ne.jp を維持できないが気になり、二の足を踏み続けてた。

そんなこんなで迎えた 2012 年の春、「さくらのVPS」リニューアルのお知らせが発表された。

新プランの 2GB はこれまで利用してきた環境と比較して総合的にスペックが上である。そのうえ金額は 1,480 円。これはちょうど、さくらのレンタルサーバ スタンダード 500 円 と旧さくらの VPS 512MB の 980 円を足した額になる。

まさに移行にうってつけではないか!というわけでサービス受付初日となる 2012/3/29 に即、契約。

私が利用しているプランのスペックを比較すると以下のようになる。さくらのレンタルサーバについては 1 台のサーバーを複数ユーザーが共有するので実際のスペックはもっと下がるはず。

VPS 2GB VPS 512MB レンタルサーバ スタンダード
初期費用 1,980 円 0 円 1,000 円
月額料金 1,480 円 980 円 500 円
メモリ 2GB 512MB 3.25GB
CPU 仮想 3 コア 仮想 2 コア 2 コア
HDD 200GB 20GB 10 GB

ブログ移転でドメインを維持できなくなる点については目をつぶることにした。

そもそも akabeko.sakura.ne.jp は、さくらのインターネットの提供するサブドメインなので固執する意義が薄い。むしろこのままリンクが集まり続けたら移行の枷は重くなるばかりである。

というわけで akabeko.sakura.ne.jp はあきらめて新たに akabeko.me という独自ドメインを取得することにした。

余談だが、私のハンドル名であるアカベコは偶蹄目なので本当は .mo ドメインにして akabeko.mo にしたかったのだけど .mo は維持費がけっこう高いため .me で妥協。

用意するもの

サーバー上で作業をおこなうため、まずは SSH クライアントを用意する。Windows なら TeraTerm、Mac の場合は標準のターミナルを利用する。

ファイルの送受信については SSH クライアントを利用してもよいのだが SFTP をサポートした GUI クライアントがあると便利。Windows だと WinSCP、Mac では Cyberduck あたりが定番か。どちらもツリー ビューをサポートしているので、ファイラーとしても扱いやすい。

WinSCP にはインストーラ版とポータブル版が用意されている。インストーラー版の場合、PuTTYgen という便利ツールも一緒に入れてくれるので選ぶならこちらを推奨。

サーバーの起動とコントロールパネル

VPS を契約すると「[さくらのVPS] 仮登録完了のお知らせ」というメールが送られてくる。その中には以下のような部分がある。

《VPSコントロールパネル ログイン情報》 VPSコントロールパネルでは、仮想サーバのリセットやリモート コンソールでの接続、OSの再インストールなどを行うことができます。 URL : https://secure.sakura.ad.jp/vpscontrol/ IPアドレス: XXX.XXX.XXX.XXX パスワード: XXXXXXXXXXXXXXXXXXXXXXXX

URL は VPS のコントロールパネルにログインするためのページ。アクセスすると IP アドレスとパスワードの入力欄がある。入力してログインするとコントロールパネルに移動するので「起動」ボタンを押す。

少し待ちステータス欄の「更新」ボタンを押すと欄内の表示が稼働中に変わる。これでサーバーが起動した。サーバーの停止と再起動もこのページからおこなえる。

VPS コントロールパネル

コントロールパネルには他にもリモートコンソールや OS 再インストール機能が用意されている。

リモートコンソールリモートコンソールは JavaScript で作られたブラウザ上のコンソールで、TeraTerm などを用意しなくてもここからサーバーにログインしてコマンド実行をおこなえる。

リモートコンソール

コンソール上部のタイトル右にあるアイコンからクリップボードの内容も貼りつけられる。応答性もよい。

このコンソールは SSH でパスワードによるログインを禁止していても関係なくログインできるので注意が必要である。ただし iptables などの Firewall で自分の作業しているネットワーク環境の IP アドレスを間違って遮断してしまったとか、そういうトラブルのときは役立つ。

サーバーの設定をいじっている内に不安定になったり起動不能になったときは OS 再インストール を利用することで、サーバーを初期状態に戻せる。

OS再インストール

root のパスワードを入力して「確認」ボタンを押すと再インストールできる。前に試してみたところ 5 分もかからずに完了した。どのような仕組みになっているのか謎なのだが root のパスワードを変更していた場合、再インストール後の環境にも引き継がれる。

OS 再インストール画面からカスタム OS インストールを選ぶと標準の CentOS 以外でセットアップ可能。OS だけで 6 種、さらにバージョンやプラットフォームの違いを含めると 14 種類ものパターンがある。

カスタム OS インストール

root のパスワード変更とユーザー作成

サーバーを起動できたら、さっそくログインしてみよう。初期状態では root ユーザーだけが存在し、さくらインターネットから送られてきたメールに書かれていた初期パスワードが設定されている。しかしメールにも警告されているよう、これは危険なので真っ先に変更する。

TeraTerm を起動して「新しい接続」ダイアログに IP アドレスを入力し、OK ボタンを押す。次の「SSH 認証」ダイアログではユーザー名に root、パスフレーズへ初期パスワードを入力して OK ボタンを押す。入力内容が適切なら、これでログインがおこなえる。

passwd コマンドを実行すると、新しいパスワードと確認の計 2 回、入力を求められる。成功すると以下のようになる。

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

私は以前このブログで紹介したサービスでパスワード生成している。しかし複雑なパスワードは入力難度が高いためクリップボードにコピーして貼りつけている。TeraTerm の貼り付けは Alt + V か、メニューから「編集」→「貼り付け」で実行可能。パスワードは KeePass で管理しており必要なときだけコピペするようにしている。

root のパスワードを変更したが管理的に考えて、通常の操作は root 以外のユーザーでおこない必要なときだけ特権を委譲してもらうのが好ましい。

というわけで次は作業用のユーザーを用意する。useradd コマンドでユーザー作成して passwd コマンドでパスワードを設定する。成功すると以下のようになる。

# useradd test
# passwd test
Changing password for user test.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

ここで TeraTerm のメニューから「ファイル」→「新しい接続」を選び、いま作成したユーザーでログインできることを確認しておく。

Mac の場合

Mac で SSH 接続する場合は、ターミナル.app を起動し、ssh コマンドを実行する。

$ ssh root@XXX.XXX.XXX.XXX -p 22

@ の前がユーザー名、後の XXX.XXX.XXX.XXX が接続先の IP アドレスとなる。既に IP アドレスと関連づけたドメインがあればそれを指定してもよい。

-p パラメータに指定された数字は接続するポート番号である。省略時は既定の 22 が選ばれる。いずれ安全のためにポート番号を変える予定なので、この形式で変更可能なことを覚えておこう。

接続後の作業は VPS 上でおこなうため、手順は Windows と一緒。

SSH 接続用の鍵を作成する

さきほど root と作業用ユーザーにパスワードを設定したが、これは最低限のセキュリティ対策である。

そもそもパスワードでログインすることが好ましくない。いくらパスワードを複雑にしても、それが割れたらどこからでもログインされてしまう。

そこで SSH 接続には公開鍵認証を利用する。

これはサーバーに公開鍵を置きクライアントはそれに対応した秘密鍵で接続を認証する、というものである。認証に鍵を用いるため秘密鍵ファイルを参照可能な環境からしかログインできない。

鍵を使用するユーザーの限定とパスフレーズ設定により、秘密鍵ファイルが漏洩したときの対策もおこなえる。さっそく鍵を作成してみよう。

前に作成したときは PuTTYgen を利用したが今回は TeraTerm ( Windows )ターミナル ( Mac ) を使用する。

TeraTerm による鍵の生成

TeraTerm を起動すると「新しい接続」ダイアログが表示されるのでキャンセル ボタンを押してダイアログを閉じる。

次にメイン メニューから「設定」→「SSH鍵生成…」を選ぶ。すると以下のダイアログが表示される。生成ボタンを押して鍵を生成する。

SSH 鍵生成

鍵が生成されたら、それを保護するためのパスフレーズを設定する。入力欄は設定と確認用のふたつ。ある程度、複雑なパスフレーズを指定すること。

パスフレーズの入力

パスフレーズを入力したら「公開鍵の保存」と「秘密鍵の保存」ボタンを押して鍵ファイルをローカルに保存する。公開鍵は id_rsa.pub、秘密鍵は id_rsa というファイル名にしておく。

Mac の場合

ターミナルを起動して ssh-keygen コマンドを実行。

$ ssh-keygen

コマンドを実行すると鍵ファイルの名前とパスフレーズをたずねられる。ファイル名は id_rsa、パスフレーズはある程度、複雑なもの ( 4 文字以下だとエラーになる ) を入力しておく。

生成に成功すると以下のような出力がおこなわれるはず。

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/XXXXXXXX/.ssh/id_rsa): id_rsa              
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
6a:47:23:9c:e4:33:1f:7d:4b:0f:87:d7:66:8b:68:b1 XXXXXXXX@XXXXXXXX-MacBookAir.local
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|      .          |
|     + . .   . . |
|      B S ..= o +|
|       B o o+*.o.|
|      o o  E.... |
|     . .  .      |
|                 |
+-----------------+

これで /Users/XXXXXXXX/.ssh に 公開鍵 id_rsa.pub と秘密鍵 id_rsa が作成された。秘密鍵のほうは他のユーザーに見られないよう、パーミッションも変更しておく。ターミナルから以下のコマンドを実行する。

$ cd
$ cd .ssh
$ chmod 600 id_rsa

サーバーの SSH 設定を変更

はじめに公開鍵認証でログインしたいユーザーの HOMEへ公開鍵ファイルとなる id_rsa.pub を送信する。TeraTerm ならサーバーにログインした状態でウィンドウにファイルをドロップすれば、そのユーザーの HOME にコピーされる。

Mac では scp コマンドで転送する。id_rsa.pub が Mac 側のユーザー HOME 以下の .ssh ディレクトリにある場合、実行するコマンドは以下のようになる。

$ cd
$ cd .ssh
$ scp -P 22 id_rsa.pub XXXX@XXX.XXX.XXX.XXX:

-P パラメータでポート番号を指定、@ の前後にユーザー接続先。そのあとに : を付けてサーバー上の転送先ディレクトリを指定する。未指定の場合は HOME に転送される。転送できたらサーバーにログインし、以下のようにコマンドを実行してゆく。

$ cd
$ mkdir .ssh
$ chmod 700 .ssh
$ mv id_rsa.pub .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys

ユーザーの HOME に .ssh ディレクトリを作成し、その中に公開鍵を authorized_keys という名前で配置している。他のユーザーから読み取られないよう、ディレクトリのパーミッションを 700、公開鍵ファイルは 600 としている。これで公開鍵の準備は完了。

次はいよいよ、SSH の設定変更である。

変更には管理者権限が必要なので、su コマンドで root になる。ちなみに通常のユーザーと管理者は、プロンプト先頭の文字で見分けられるようになっている ( シェルによるのかもしれないが )。プロンプトが $ なら通常ユーザー、# は管理者となる。

$ su -
Password:
#

次に /etc/ssh/sshd_config を編集する。vi コマンドで設定ファイルを開く。

# vi /etc/ssh/sshd_config

vi エディタの使い方については、以下のページあたりが参考になる。

ファイルを開いたらPermitRootLogin ( root のログイン )PasswordAuthentication ( パスワードによるログイン )no に設定する。書式は設定名の後に yes で有効、no で無効、行頭に # でコメントアウトとなる。例えば、以下のように書く。

#PermitRootLogin yes
PermitRootLogin no

... 中略 ....

#PasswordAuthentication yes
PasswordAuthentication no

編集して保存したら SSH デーモンを再起動する。

# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]

設定に誤りがあればエラーメッセージが表示されるので修正する。ここまでの手順がすべて適切ならば以降はパスワードログインが禁止され、秘密鍵の参照が必須となる。例えば TeraTerm の SSH 認証なら以下のようになる。

TeraTerm の SSH 公開鍵認証

コンソールの日本語化

初期設定の一環としてコンソールを日本語化しておく。この設定を格納している /etc/sysconfig/i18n を vi で開く。

$ su -
Password:
# vi /etc/sysconfig/i18n

すると以下のような内容になっているので、

LANG="C"
SYSFONT="latarcyrheb-sun16"

LANG の内容を以下のように編集する。

LANG="ja_JP.UTF-8"
SYSFONT="latarcyrheb-sun16"

編集したら保存して、再ログインするとメッセージが日本語化される。例えば ls -l を実行したときの内容を比べると、初期状態では、

$ ls -l
total 36
-rw-r--r-- 1 root root 33726  9月 15 22:30 httpd.conf

となっているが、日本語化されると以下のように「total」という表記が「合計」に変わる。

$ ls -l
合計 36
-rw-r--r-- 1 root root 33726  9月 15 22:30 httpd.conf

日本語版のマニュアルが用意されているコマンドなら、man コマンドによる表示も日本語化されるので便利だと思う。

システムの更新

今回の仕上げとしてシステムの状態を最新へ更新しておく。これはいわば Windows Update のようなもので定期的に実行することになるだろう。

更新には yum というコマンドを使用する。実行は root になるか sudo を利用する。今はまだ sudo を設定していない ( 次回におこなう予定 ) ので root からおこなう。

yum コマンドを実行すると、はじめにダウンロードするパッケージ一覧とサイズが表示される。ダウンロードの実行を問い合わせられるので、y と入力して Enter。初回なら GPG キーをインポートするという問い合わせがあるので、これも y と答えて Enter を押す。

yum に -y オプションを指定すると問い合わせに y と答えたことにしてスキップできる。N を選ぶことは滅多にないが、キャンセルしたいことがあるかもしれないので私はスキップさせず常に問い合わせを受けるようにしている。

$ su -
Password:
# yum update

...
Install       2 Package(s)
Upgrade      16 Package(s)

Total download size: 34 M
Is this ok [y/N]: y

しばらく待ってアップデート完了。

…今回はここまで。次回は SSH のポート変更と sudo の指定について書く予定。