とあるエンジニアの備忘log

2013年1月20日日曜日

Shared Object 入門

最近の gcc だとシンボル解決がうまくいかないといかないことがあったので、ちょっと調べました。

次のような 3つのソースファイルがあったとして、ダイナミックリンクで作ってみましょう。

`main.c`

int foo(void);
    int main(void)
    {
            return foo() + 1;
    }

`foo.c`

int bar(void);
    int foo(void)
    {
            return bar() + 1;
    }

`bar.c`

int bar(void)
    {
            return 0;
    }

shared object を作るのに必要なのは、コンパイル時に `-fPIC` オプションをつけることと、リンク時に `-shared` オプションをつけることの 2点です。

$ gcc -fPIC -c -o bar.o bar.c
    $ gcc -shared -o libbar.so bar.o

のように中間オブジェクト `bar.o` を作ってもいいですし

$ gcc -shared -fPIC -o libbar.so bar.c

のように一度にやってもよいです。いずれにせよ `libbar.so` が作られます。

では、最後までやってみます。

$ gcc -shared -fPIC -o libbar.so bar.c
    $ gcc -shared -fPIC -o libfoo.so foo.c
    $ gcc -L . -lfoo -lbar main.c
    /tmp/ccqQv8uv.o: In function `main':
    main.c:(.text+0x5): undefined reference to `foo'
    collect2: ld returned 1 exit status

あれれ、 `foo` が見つからないと言われました。。。
gcc のバージョンによっては、上記のやり方でもエラーなしにリンクできる場合もあるかもしれません。
gcc のバージョンが新しいとうまくいかないようです。
私の手元の gcc のバージョンは 4.6.3 です。

ちなみに、

$ gcc -L . main.c -lfoo -lbar

のようにすればうまくいきました。

関数が `main()` ->　`foo()` -> `bar()` のようにコールしているならば、
リンク時にも `main.c -lfoo -lbar` の順に並べないと、リンク解決できないようです。

とは言うものの、リンク時に順番をいちいち考えるのも面倒です。

順番を気にせずうまくやってくれるためには、リンカーに、 `-no-as-needed` を渡せばよいようです。

$ gcc -Wl,-no-as-needed -L. -lfoo -lbar main.c

でも

$ gcc -Wl,-no-as-needed -L. -lfoo main.c -lbar

でもうまくいきます。

実行してみます。
`libfoo.so` と `libbar.so` は検索パスに置いてないので、 `LD_LIBRARY_PATH` を指定します。

$ LD_LIBRARY_PATH=$PWD ./a.out
    $ echo $?
    2

うまくいきました。

ちなみに、リンク時に `-R`  または `-rpath` でライブラリ検索パスを指定しておけば、実行時に `LD_LIBRARY_PATH` は指定しなくてもいいです。

$ gcc -Wl,-no-as-needed -Wl,-R$PWD -L . -lfoo -lbar main.c

または

$ gcc -Wl,-no-as-needed -Wl,-rpath $PWD -L . -lfoo -lbar main.c

まだよくない点があります。

関数 `main()` から直接的にコールしているのは `foo()` だけであって、 `bar()` を直接的にコールしているわけではないです。

なので、関数 `foo()` をコールするために

$ gcc -Wl,-no-as-needed -L. -lfoo -lbar main.c

のように `-lfoo` も `-lbar` もリンクしないといけないのは変な話です。

関数 `foo()` は関数 `bar()` をコールしているので、 `libfoo.so` は `libbar.so` に依存していることになります。

そこで、shared object 間の依存関係を考慮することにします。

`libfoo.so` を作るときにも `-Wl,-no-as-needed` を指定すればうまくいきます。

$ gcc -shared -fPIC -o libbar.so bar.c
    $ gcc -shared -fPIC -Wl,-no-as-needed -L . -lbar -o libfoo.so foo.c
    $ gcc -Wl,-no-as-needed -Wl,-rpath $PWD -Wl,-rpath-link $PWD -L . -lfoo main.c

最終行で、 `-lbar` は不要になっています。 ただし、 `-rpath-link` オプションがいります。

`ldd` コマンドで依存関係を見ると、 libfoo.so は libbar.so を必要としています。

$ ldd libfoo.so
     linux-vdso.so.1 =>  (0x00007fff1fbff000)
     libbar.so => not found
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5141d0d000)
     /lib64/ld-linux-x86-64.so.2 (0x00007f51422ea000)

ちなみに、shared object の勉強は
[共有ライブラリーを解剖する](http://www.ibm.com/developerworks/jp/linux/library/l-shlibs/)
というページがわかりやすかったです。

2013年1月10日木曜日

GitHub 覚え書き

clone / push / pull の仕方のメモ。

https を使うか ssh を使うかがあるようだ。

### https ###

$ git clone https://github.com/user_account/project_name.git

アカウントとパスワードの入力を求められます。 pull,  push もできます。

既にあるリポジトリを push するときは

git remote add origin https://github.com/user_account/project_name.git
    git push -u origin master

### ssh 公開鍵暗号の場合 ###

$ ssh-keygen -t rsa

秘密鍵 `~/.ssh/id_rsa` および公開鍵 `~/.ssh/id_rsa.pub` が生成される。

`~/.ssh/id_rsa.pub` の中身を

GitHubのページで 「account settings」 -> 「SSH Keys」
のページを開いて、貼り付けます。
タイトルは何でもいいのですが、わかりやすいように、鍵が対応するホスト名を入れておけばよいでしょう。

あとは以下のようにやればよい。

$ git clone git@github.com:user_account/project_name.git

既にあるリポジトリを push するときは

git remote add origin git@github.com:user_account/project_name.git
    git push -u origin master

とすればよいです。

会社などで HTTPプロキシの使用が強制されている場合など、

$ git clone git@github.com:user_account/project_name.git
    Cloning into 'projectname'...
    ssh: Could not resolve hostname github.com: No such file or directory
    fatal: Could not read from remote repository.

Please make sure you have the correct access rights
    and the repository exists.

みたいな感じでエラーになることがある。

このような場合は、 corkscrew で乗り越える。

`~/.ssh/config` に以下のような感じで設定を書いておく。

Host github.com
    ProxyCommand /usr/bin/corkscrew your.proxy.server.co.jp 8080 %h %p

`your.proxy.server.co.jp` のところは自分の環境にあわせて書き直してください。

2013年1月9日水曜日

perl の eval 〜 if 0 ってなんだ？

perl で書かれたスクリプトの先頭によくある、以下のようなもの。
最初、いったいなんだろう？と思った。

#! /usr/bin/perl -w

eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S "$0" "$@";; esac'
    if 0;

ここでの eval というのは perl の関数ではなくて、シェルのコマンドであるというのがポイント。
どうもこれは #! を解釈してくれないような環境用の回避策らしい。

もし、このスクリプトが perl で実行されているのなら、
〜 if 0; という形なので（後置のif）

eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S "$0" "$@";; esac'

の部分はまるまる無視され、何も起きない。そのまま残りのスクリプトを実行します。

一方、このスクリプトがシェルで実行されているのなら、

eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S "$0" "$@";; esac'

がシェルによって実行されて、 /usr/bin/perl でこのスクリプトを実行し直すことになる。

    if 0;

にはたどり着きません。

perl の文は「;」区切り、シェルスクリプトは「改行」区切りというのをうまく利用しています。
よくもまあこんなことを考えた人がいたもんだ。

2012年12月19日水曜日

zfs のNFS機能を使ってみた

ZFS は NFS をサポートしているので、一応使えることを確認しました。

zfs-fuse ではなくて、以前「zfsを使ってみた」で説明したように ZFS on Linux をインストールしています。

NFSサーバー側の設定

例えば、 tank/home パーティションを作り、 /export/home にマウントし、さらに NFS で共有という例でやってみます。

パーティションを作る。
# zfs create tank/home

マウントポイントを変更
# zfs set mountpoint=/export/home tank/home

RHEL/CentOS の場合、NFS server は標準でインストールされていると思いますが、もしインストールされていなければ、
# yum install nfs-utils
でインストールします。

nfs サービスが起動していることを確認しておきます。

ただし、設定自体は ZFS のプロパティで行うので、 /etc/exports の編集は不要です。

あとは、以下のような感じで sharenfs オプションを指定します。
# zfs set sharenfs="rw=@192.168.11.2,root_squash"

192.1681.11.2 の部分はクライアント側のIPアドレスに置きかえてください。/etc/hostsのホスト名でもOKです。
どうも no_root_squash がデフォルトになっているらしく、
root_squash の指定をしておかないと、クライアントのroot がサーバー側でもroot扱いになってしまう。
したがって sharenfs=on はセキュリティ上脆弱なので、やめておいた方がよいでしょう。

あとはクライアント側からは、以下のような感じでマウントできます。
# mount -t nfs 192.168.11.1:/export/home /mnt/

一応やってはみましたが、自分は NFSv4 を使いたいので、zfs の NFS機能は使わないかも。

Kerberos の ticket lifetime を変更する

Kerberos のチケットのlifetime を短くするのは簡単にできるのに、長くするのはできないなぁと思っていたら、チケットの有効期限は以下の４つの minimum 値で決まるらしい。

(1) サーバー側(KDC) のkdc.conf
RHEL/CentOSなら
/var/kerberos/krb5kdc/kdc.conf の
[realms]セクションのmax_life 設定。
Ubuntuなら
/etc/krb5kdc/kdc.conf にあります。

(2)クライアント側の /etc/krb5.conf
[libdefaults] セクションの ticket_lifetime 設定

(3)ユーザープリンシパルの maxlife
kadmin: modprinc -maxlife 3day user01
などで変更

(4)サービスプリンシパルの maxlife
kadmin: modpronc -maxlife 3day krbtgt/MYDOMAIN.COM
などで変更します。

なお、addprinc で新しくプリンシパルを作成した時の maxlife の初期値は
kdc.conf の max_life 設定で決まるようです。

NFSv4 + Kerberos でセキュリティとユーザーマッピングを解決

NFSv4 と Kerberos を組み合わせることで、NFSのセキュリティとユーザーマッピングの課題を解決してみました。

これまで、自分が NFS を使う際の懸念事項がセキュリティの問題とユーザーマッピングの問題でした。

#### セキュリティについて ####

`/etc/exports` でマウントを許可するクライアントを指定することはできるものの、IPアドレスは基本的に自己申告ですから、LAN内にある全てのマシンが信用できるという場合を除いては、かなり危険だと思います。

ある程度規模の大きい LAN につないでいる場合、中には悪い人がいるかもしれません。

例えば、サーバー側が `/etc/exports` に

/home    192.168.11.30(rw,sync)

と書いて、公開したとします。

他のマシンから

$ showmount -e NFS_SERVER_NAME

で問い合わせると

/home 192.168.11.30

と表示されます。

つまりどのホストに対して、どのディレクトリを公開しているかは一目瞭然です。
その IPアドレスになりすまされると、悪意のある人に簡単にマウントされてしまいます。

#### ユーザーマッピングの問題について ####

NFSv3 までは、パーミッションについては クライアント側の UID と GID がサーバー側でも利用されるので、サーバー/クライアント間で UID と GID  の同期が取れていない場合、別ユーザーになってしまうという問題があります。

例えば、サーバー側では taro が UID 500 だったとします。
もし、クライアント側で taro が UID 600 になっていたとすると、 taro は サーバー上のファイルへアクセスできなくなってしまいます。
しかも、クライアント側で、もし hanako が UID 500 に割り当たっていたとすると、 hanako は サーバー上の taro のファイルにアクセスできてしまうことになる。

ディストリビューションによって、一般ユーザーの UID に使われる範囲が違います。
RedHat系は 500～、Ubuntuなどでは 1000～ が使われるようです。

ですから、 NIS や LDAP などでユーザー情報を一元管理しているか、気をつけてユーザーID を設定している場合を除いては、サーバー/クライアント間で UID や GID は一致しないことが多いです。

そもそも「サーバー/クライアント間でユーザーに同じ UID/GID が使われている」という前提は期待されるべきものでもないと思うのです。

exports の古い man ページを見るとかつて `map_static` というオプションがあって、 サーバー/クライアント間で UID と GID を再マッピングできたみたいなのですが、すでに廃止されていているみたいです。

そこで、NFSv4 + Kerberos version5 をセットアップし、上記の「セキュリティの問題」と「ユーザーマッピングの問題」を解決してみました。

ユーザーマッピングについては NFSv4 で idmapd デーモンがやってくれるので、Kerberos までは必要ないようにも思えます。
ところが、NFSv4 単独だと、ユーザーマッピングがうまく動きませんでした。
検索してみたところ、 「idmapd が期待通り動かない」という書き込みが多かったですし、私も実際試してみたのですが、結局やり方がわかりませんでした。

一方、認証を Kerberos に任せた場合は、ユーザーマッピングもうまく動作しました。

最初、 RHEL/CentOS での設定をまとめます。その後、 Ubuntu での設定も簡単に説明します。

前提として、すでに Kerberos の基本的な設定は済んでいるものとします。
この部分は、前回 [Kerberos を使ってみる(RHEL/CentOS/Ubuntu編)](/2012/12/kerberos-v5.html)の記事で説明しました。

### RHEL/CentOS編 ###

RHEL6.3/CentOS6.3で確認しています。

ここでは説明上、

- NFSサーバーのホスト名: `nfsserver.mydomain.com`
- NFSクライアントのホスト名: `nfsclient.mydomain.com`

とする。

NFSサーバー/NFSクライアント両方とも `/etc/sysconfig/nfs` で

SECURE_NFS="yes"

の行を有効にしておきます。

さらに、どのホストからでもいいですけど、

kadmin: addprinc -randkey nfs/nfsserver.mydomain.com
    kadmin: addprinc -randkey nfs/nfsclient.mydomain.com

として、サーバー側、クライアント側の両方のサービスプリンシパルを作成する。

通常のサービスではサーバー側だけサービスプリンシパルを作成するのですが、NFS については サーバー/クライアント両方とも必要です。

`ktadd` はおのおののホスト上で行わないといけません。

NFSサーバー (`nfsserver.mydomain.com`)上で

kadmin: ktadd nfs/nfsserver.mydomain.com

NFSクライアント(`nfsclient.mydomain.com`)上で

kadmin: ktadd nfs/nfsclient.mydomain.com

とする。

それぞれのホストの `/etc/krb5.keytab` にキーが保存されるはず。

ちゃんと保存されているか念のために確認してみます。

NFSサーバー側の結果：

[root@nfsserver] # klist -e -k /etc/krb5.keytab
    Keytab name: WRFILE:/etc/krb5.keytab
    KVNO Principal
    ---- --------------------------------------------------------------------------
       2 nfs/nfsserver.mydomain.com@MYDOMAIN.COM (aes256-cts-hmac-sha1-96)
       2 nfs/nfsserver.mydomain.com@MYDOMAIN.COM (aes128-cts-hmac-sha1-96)
       2 nfs/nfsserver.mydomain.com@MYDOMAIN.COM (des3-cbc-sha1)
       2 nfs/nfsserver.mydomain.com@MYDOMAIN.COM (arcfour-hmac)
       2 nfs/nfsserver.mydomain.com@MYDOMAIN.COM (des-hmac-sha1)
       2 nfs/nfsserver.mydomain.com@MYDOMAIN.COM (des-cbc-md5)

NFSクライアント側の結果：

[root@nfsclient]# klist -e -k /etc/krb5.keytab
    Keytab name: WRFILE:/etc/krb5.keytab
    KVNO Principal
    ---- --------------------------------------------------------------------------
       3 nfs/nfsclient.mydomain.com@MYDOMAIN.COM (aes256-cts-hmac-sha1-96)
       3 nfs/nfsclient.mydomain.com@MYDOMAIN.COM (aes128-cts-hmac-sha1-96)
       3 nfs/nfsclient.mydomain.com@MYDOMAIN.COM (des3-cbc-sha1)
       3 nfs/nfsclient.mydomain.com@MYDOMAIN.COM (arcfour-hmac)
       3 nfs/nfsclient.mydomain.com@MYDOMAIN.COM (des-hmac-sha1)
       3 nfs/nfsclient.mydomain.com@MYDOMAIN.COM (des-cbc-md5)

また、NFSサーバー側の `/etc/exports` の書き方は

/home    gss/krb5(fsid=0,crossmnt,rw,sync)

などとなります。公開先のホスト名の部分を `gss/krb5` とする部分がポイントです。

あとはクライアント側から

# mount -t nfs4 -o sec=krb5 nfsserver:/  hogehoge

といった感じでマウントができます。 (実は `-t nfs4` の部分はなくてもよい。)

マウントはこれでできますが、実際にアクセスするには、ユーザーは Kerberos 認証を済ませないといけません。

$ kinit

でTGT を入手しておけば、アクセス可能になります。

なお、NFSv4 + Kerberos を解説したページで `ktadd` するときに `-e des-cbc-crc:normal` オプションを付けると説明しているページもありますが、現在はこのオプションは不要ですので、このオプションは付けないでください。
`dec-cbc-crc` 自体が廃止で、エラーになります。

### Ubuntu編 ###

Ubuntu 12.04 LTS で確認しました。

やり方は、RHEL/CentOS とほとんど同じなので、差分だけ説明します。

NFSサーバーは `nfs-kernel-server` パッケージ、NFSクライアントは `nfs-common` パッケージのインストールが必要です。

RHEL/CentOS で `/etc/sysconfig/nfs` で

SECURE_NFS="yes"

を設定するとなっている部分は Ubuntu では不要です。

その代わり、Ubuntu では、NFSサーバーの `/etc/default/nfs-kernel-server` に

NEED_SVCGSSD=yes

NFSクライアントの `/etc/default/nfs-common` に

NEED_GSSD=yes

を追加します。

あとは、同じやり方でできます。

### RHEL/CentOS と Ubuntu の組み合わせ ###

RHEL/CentOS 同士、 Ubuntu 同士の組み合わせで説明しましたが、もちろん、 CentOSのNFSサーバー と Ubuntu クライアントといった組み合わせでも動きました。
CentOS では UID は 500～ から使われていて、Ubuntuでは UID は 1000～ なので、当然ながら UID/GID はまったくバラバラなのですが、うまくユーザーマッピングして動いてくれています。

Kerberos を使ってみる (RHEL/CentOS/Ubuntu編)

NFSv4 と Kerberos を組み合わせて、 NFS のセキュリティの弱さをカバーしてみたいと思います。

長いので 2回に分けました。

今回は Kerberos の初期設定の部分までやってみます。

まずは RHEL/CentOS の場合のやり方を説明し、最後に Ubuntu でやる場合の差分情報をまとめておきます。

### RHEL/CentOS編 ###

RHEL 6.3/CentOS 6.3で確認しました。

Kerberos サーバー側は `krb5-server` パッケージをインストールします。
クライアント側については `krb5-workstation` がデフォルトでインストールされているので、特にインストールする必要はないです。

Kerberos サーバーのことを KDC (Key Distribution Center) と言います。

主に設定変更するファイルは3点です。

- `/etc/krb5.conf` : Kerberos 認証を利用する全ホストで設定必要
- `/var/kerberos/krb5kdc/kdc.conf`: KDCのみ設定する
- `/var/kerberos/krb5kdc/kadm5.acl`: KDCのみ設定する

以下、説明の都合上、

- KDCのホスト名 : `mykdc.mydomain.com`
- サービスサーバーのホスト名: `myserver.mydomain.com`
- サービスクライアントのホスト名: `myclient.mydomain.com`

として説明します。

`mykdc` と `myserver` は同一ホストであってもいいですが、一応、別々として説明しています。

Kerberos のシングルサインオンで、 `myclient` から `myserver` へ ssh ログインするところまでやってみます。

#### krb5.conf の修正 ####

各ホストの `/etc/krb5.conf` を以下のように修正します。

[logging]
     default = FILE:/var/log/krb5libs.log
     kdc = FILE:/var/log/krb5kdc.log
     admin_server = FILE:/var/log/kadmind.log
    
    [libdefaults]
    # default_realm = EXAMPLE.COM              ←コメントアウト
     default_realm = MYDOMAIN.COM              ←追加
     dns_lookup_realm = false
     dns_lookup_kdc = false
     ticket_lifetime = 24h
     renew_lifetime = 7d
     forwardable = true
    
    [realms]
     EXAMPLE.COM = {
      kdc = kerberos.example.com
      admin_server = kerberos.example.com
     }
    
     MYDOMAIN.COM = {                            ←追加
      kdc = mykdc.mydomain.com                   ←追加
      admin_server = mykdc.mydomain.com          ←追加
     }                                           ←追加
    
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM

レルム名 (Kerberos が管理する範囲のこと) が `EXAMPLE.COM` になっているので、 `MYDOMAIN.COM` に変更しました。
ドメイン名を大文字にしたものをレルム名にするのが慣例です。

#### kdc.conf の修正 ####

KDCホストの `/var/kerberos/krb5kdc/kdc.conf` を以下のように修正。

[kdcdefaults]
     kdc_ports = 88
     kdc_tcp_ports = 88
    
    [realms]
    # EXAMPLE.COM = {    ← コメントアウト
     MYDOMAIN.COM = {     ← 追加
      #master_key_type = aes256-cts
      acl_file = /var/kerberos/krb5kdc/kadm5.acl
      dict_file = /usr/share/dict/words
      admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
      supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
     }

#### kadm5.acl の修正 ####

KDCホストの `/var/kerberos/krb5kdc/kadm5.acl` を以下のように修正。

# */admin@EXAMPLE.COM *   ← コメントアウト
    */admin@MYDOMAIN.COM *    ← 追加

これは `kadmin` 中で実行可能なコマンドを設定しています。

`*/admin` のユーザーに全コマンドを許可するのが慣習です。

#### データベース設定 ####

3種類のファイルの修正ができたら KDC上で

root@mykdc # kdb5_util create -s

でデータベースを作成する。

途中で KDC database master key を入力するように言われるので、パスワードを設定します。

さらにサーバー側で `kadmin.local` で `root/admin` プリンシパルを作成する。
`kadmin.local` はどんなコマンドでもパーミッションを無視して、成功します。

root@mykdc # kadmin.local
       ...
    kadmin.local:  addprinc  root/admin
       ...
    kadmin.local:  exit

kadmin サービスと krb5kdc サービスを開始する。

root@mykdc # chkconfig kadmin on
    root@mykdc # service kadmin start
    root@mykdc # chkconfig krb5kdc on
    root@mykdc # service krb5kdc start

ファイアウォールを設定している場合、

- `88/tcp, 88/udp` (krb5kdc サービス)
- `749/tcp` (kadminサービス)

を開けておきます。

これ以降は、どのホストからでも

$ kadmin -p root/admin

とすれば、KDC database のメンテができるようになります。

どのホストからでもいいのですが、以下のようにユーザープリンシパルやホストプリンシパルを作ります。

$ kadmin -p root/admin
    kadmin: addprinc user01
    kadmin: addprinc -randkey host/myserver.mydomain.com
    kadmin: exit

とします。 `user01` は使うユーザー名で適宜置き換えてください。

最後、ホストプリンシパルのパスワードを `ktadd` する。これは必ずサービスサーバー上で行わないといけない。

root@myserver # kadmin -p root/admin
    kadmin: ktadd host/myserver.mydomain.com
    kadmin: exit

キーはサービスサーバーの `/etc/krb5keytab` へ保存されます。

試しに、以下のようにするとキーが保存されているのがわかります。

myserver # klist -e -k /etc/krb5.keytab 
    Keytab name: WRFILE:/etc/krb5.keytab
    KVNO Principal
    ---- --------------------------------------------------------------------------
       2 host/myserver.mydomain.com@MYDOMAIN.COM (aes256-cts-hmac-sha1-96) 
       2 host/myserver.mydomain.com@MYDOMAIN.COM (aes128-cts-hmac-sha1-96) 
       2 host/myserver.mydomain.com@MYDOMAIN.COM (des3-cbc-sha1) 
       2 host/myserver.mydomain.com@MYDOMAIN.COM (arcfour-hmac) 
       2 host/myserver.mydomain.com@MYDOMAIN.COM (des-hmac-sha1) 
       2 host/myserver.mydomain.com@MYDOMAIN.COM (des-cbc-md5)

以上でセットアップ完了です。

クライアント側で

user01@myclient $ kinit

で認証します。

user01@myclient $ ssh myserver

で `myserver` のログインパスワードを入力せずに、ssh 接続できます。
Kerberos で認証できているためです。シングルサインオンが実現しました！

user01@myclient $ klist

でキャッシュされているチケットが表示されます。

Valid starting     Expires            Service principal
    12/17/12 16:26:33  12/18/12 16:26:33  krbtgt/MYDOMAIN.COM@MYDOMAIN.COM
     renew until 12/17/12 16:26:33
    12/17/12 16:27:17  12/18/12 16:26:33  host/myserver.mydomain.com@MYDOMAIN.COM
     renew until 12/17/12 16:26:33

なお、 ホストプリンシパルのサービスチケットの取得がうまく行かない場合、 `/etc/hosts` を確認してみてください。

192.168.10.xx    myserver.mydomain.com myserver

のように Fully Qualified Domain Name が先にくるように書いておかないと、ホストの逆引きで失敗します。

192.168.10.xx    myserver myserver.mydomain.com

のように書くとうまくいきません。

### Ubuntu編 ###

Ubuntu 12.04 LTS で確認しました。

KDC側は

$ sudo apt-get install krb5-kdc krb5-admin-server

KDC以外のホストは

$ sudo apt-get install krb5-user

をインストールします。

インストールの途中で

- レルム
- あなたのレルムのケルベロスサーバー (`/etc/krb5.conf` の `kdc` に設定される)
- あなたのレルムのケルベロス管理サーバー (`/etc/krb5.conf` の `admin_server` に設定される)

を質問されるので、答えます。

これに基づき、`/etc/krb5.conf` と `/etc/krb5kdc/kdc.conf` (KDCのみ)を作ってくれるので、とりあえずそのまま使えます。

ちなみに、RHEL/Ubuntu で `/var/kerberos/krb5kdc/` にあったディレクトリは Ubuntu では `/etc/krb5kdc/` にあります。

mykdc $ sudo krb5_newrealm

でデータベースを作成する。この時に `/etc/krb5kdc/kadmin.acl` も作成されます。

`/etc/krb5kdc/kadmin.acl` の

# */admin *

のコメントを外す。

あとは

mykdc $ sudo kadmin.local
    kadmin.local: addprinc user01/admin

などとし、RHEL/CentOS と同様にプリンシパルを追加していきます。

なお、Kerberos による ssh シングルサインオンをするには
ssh サーバー側の `/etc/ssh/sshd_config` の

GSSAPIAuthentication no

を

GSSAPIAuthentication yes

に変更する必要があります。

登録: 投稿 (Atom)