FreeBSDを語ろう
330 ：名無しさん＠お腹いっぱい。：
>>325
ログイン時に入力したパスワードでSSHの秘密鍵を復号化し、
成功した場合自動的にssh-agentを起動してくれるpamモジュール。
passphraseの入力が面倒臭いと感じている人には朗報。
こんな感じで使う。
1. ssh-keygen でSSHの公開鍵認証に使う鍵を作成。
このときpassphraseにはUNIXパスワードと同じものを用いる。
(鍵の種類はSSH1でもSSH2のDSA鍵のどちらでもいい。ただ、
現在の4-stableではバグのためSSH2のRSA鍵は使えない。)
2. /etc/pam.conf を編集する。xdmだとこんな感じかな。
(pam.confの編集ミスに注意。簡単にログイン不能になってしまうぞ。)
----
xdm auth required pam_unix.so
xdm auth optional pam_ssh.so use_first_pass
xdm account required pam_unix.so
xdm session required pam_ssh.so
xdm password required pam_deny.so
----
3. ~/.ssh/identity(id_dsa) を他のマシンの ~/.ssh/authorized_keys(2) に追加。
4. ~/.ssh/config を以下のように設定しておくとさらに便利かも。
----
Host *
ForwardAgent yes
# SSH2の場合
# Protocol 2,1
----
5. ログインしなおした後、ssh-agentプロセスが起動していたら成功。
ログイン時に入力したパスワードでSSHの秘密鍵を復号化し、
成功した場合自動的にssh-agentを起動してくれるpamモジュール。
passphraseの入力が面倒臭いと感じている人には朗報。
こんな感じで使う。
1. ssh-keygen でSSHの公開鍵認証に使う鍵を作成。
このときpassphraseにはUNIXパスワードと同じものを用いる。
(鍵の種類はSSH1でもSSH2のDSA鍵のどちらでもいい。ただ、
現在の4-stableではバグのためSSH2のRSA鍵は使えない。)
2. /etc/pam.conf を編集する。xdmだとこんな感じかな。
(pam.confの編集ミスに注意。簡単にログイン不能になってしまうぞ。)
----
xdm auth required pam_unix.so
xdm auth optional pam_ssh.so use_first_pass
xdm account required pam_unix.so
xdm session required pam_ssh.so
xdm password required pam_deny.so
----
3. ~/.ssh/identity(id_dsa) を他のマシンの ~/.ssh/authorized_keys(2) に追加。
4. ~/.ssh/config を以下のように設定しておくとさらに便利かも。
----
Host *
ForwardAgent yes
# SSH2の場合
# Protocol 2,1
----
5. ログインしなおした後、ssh-agentプロセスが起動していたら成功。
|
|
|
331 ：名無しさん＠お腹いっぱい。：02/05/18 00:09
kinput2でrxvtやktermに日本語入力をするときに、
漢字の選択中など 確定前の日本語のフォントが明らかに変なので
他のものに直したいのですが、どうすればいいでしょうか？
漢字の選択中など 確定前の日本語のフォントが明らかに変なので
他のものに直したいのですが、どうすればいいでしょうか？
332 ：名無しさん＠お腹いっぱい。：02/05/18 00:10
質問スレと間違えました。
向こうに書き直して逝ってきます。
向こうに書き直して逝ってきます。
334 ：名無しさん＠お腹いっぱい。：02/05/18 01:12
>>330
それだと passphrase は UNIX password と同じにしないといけないね。
俺はこうしてる。これだと passphrase でも UNIX password でも
xdm で認証できて、かつ passphrase の場合は ssh-agent が起動する。
xdm auth sufficient pam_ssh.so
xdm auth required pam_unix.so try_first_pass
xdm account required pam_unix.so try_first_pass
xdm session optional pam_ssh.so
xdm session required pam_deny.so
xdm password required pam_deny.so
それだと passphrase は UNIX password と同じにしないといけないね。
俺はこうしてる。これだと passphrase でも UNIX password でも
xdm で認証できて、かつ passphrase の場合は ssh-agent が起動する。
xdm auth sufficient pam_ssh.so
xdm auth required pam_unix.so try_first_pass
xdm account required pam_unix.so try_first_pass
xdm session optional pam_ssh.so
xdm session required pam_deny.so
xdm password required pam_deny.so
>>334
> これだと passphrase でも UNIX password でも
> xdm で認証できて、かつ passphrase の場合は ssh-agent が起動する。
>
> xdm auth sufficient pam_ssh.so
> xdm auth required pam_unix.so try_first_pass
うん、確かに大抵のサイトではこっちのやり方で紹介してるね。
でも、SSHの公開鍵のpassphraseはユーザが勝手に設定できる(空にもできる)から、
それだけでログイン可能にするとセキュリティ的に問題がありそうなんで
紹介しなかった。(もちろんユーザが自分一人だけなら問題ないんだけど。)
ユーザが多数いるような場合は、>>330のやり方のほうが良いと
思うんだけど、どう?
> これだと passphrase でも UNIX password でも
> xdm で認証できて、かつ passphrase の場合は ssh-agent が起動する。
>
> xdm auth sufficient pam_ssh.so
> xdm auth required pam_unix.so try_first_pass
うん、確かに大抵のサイトではこっちのやり方で紹介してるね。
でも、SSHの公開鍵のpassphraseはユーザが勝手に設定できる(空にもできる)から、
それだけでログイン可能にするとセキュリティ的に問題がありそうなんで
紹介しなかった。(もちろんユーザが自分一人だけなら問題ないんだけど。)
ユーザが多数いるような場合は、>>330のやり方のほうが良いと
思うんだけど、どう?
336 ：名無しさん＠Ｅｍａｃｓ：02/05/18 10:01
FreeBSD-current の /etc/pam.d/xdm だと，
auth required pam_nologin.so no_warn
#auth sufficient pam_ssh.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass
account required pam_unix.so
#session required pam_ssh.so
password required pam_deny.so
こんな感じ．理解してまへん．
あと，sshd のほうで null passwd ってはじけなかったっけ？
auth required pam_nologin.so no_warn
#auth sufficient pam_ssh.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass
account required pam_unix.so
#session required pam_ssh.so
password required pam_deny.so
こんな感じ．理解してまへん．
あと，sshd のほうで null passwd ってはじけなかったっけ？
>>336
-currentでもそうなんだよねー。
[email protected]あたりでネタふりしてみたいんだけど、
英語のメールなんて書けないし。
> あと，sshd のほうで null passwd ってはじけなかったっけ？
SSHのpassphraseは ~/.ssh/identity(id_dsa) を暗号化するための
ものでsshdは全く関係ないっす。
passphraseの変更も ssh-keygen -p で簡単に行なえるよ。
-currentでもそうなんだよねー。
[email protected]あたりでネタふりしてみたいんだけど、
英語のメールなんて書けないし。
> あと，sshd のほうで null passwd ってはじけなかったっけ？
SSHのpassphraseは ~/.ssh/identity(id_dsa) を暗号化するための
ものでsshdは全く関係ないっす。
passphraseの変更も ssh-keygen -p で簡単に行なえるよ。
339 ：名無しさん＠お腹いっぱい。：02/05/18 23:08
>>339
いや、スレの流れからいって、xdm の認証に SSH の passphrase を使用した場合、
という観点からの考察になるんじゃないかな。
例えば 330 は passphrase に空を設定するユーザが現れるケースを考えて
passpharase は UNIX password と同じにすべし、というわけだ。
で、俺は passphrase に空を設定するユーザが現れるケースを考慮するというのは
推測されやすい UNIX password を設定するユーザが現れるケースと本質的に
同種の問題ではないだろうか、というわけだ。
いや、スレの流れからいって、xdm の認証に SSH の passphrase を使用した場合、
という観点からの考察になるんじゃないかな。
例えば 330 は passphrase に空を設定するユーザが現れるケースを考えて
passpharase は UNIX password と同じにすべし、というわけだ。
で、俺は passphrase に空を設定するユーザが現れるケースを考慮するというのは
推測されやすい UNIX password を設定するユーザが現れるケースと本質的に
同種の問題ではないだろうか、というわけだ。
ｺﾞﾒｿ
漏れ pam いまいち理解していないんだけど，
http://www.jp.redhat.com/manual/Doc71/RHDOCS/rhl-rg-ja-7.1/s1-pam-config-files.html
ここに pam_cracklib についての記述があるけど，
これって cracklib ひっかけて password に制限かけれるんじゃないの？
よそで空パスワード設定されちゃうと駄目？
PermitEmptyPasswords は password 認証に対してしか使えないのね．
http://www.jp.redhat.com/manual/Doc71/RHDOCS/rhl-rg-ja-7.1/s1-pam-config-files.html
ここに pam_cracklib についての記述があるけど，
これって cracklib ひっかけて password に制限かけれるんじゃないの？
よそで空パスワード設定されちゃうと駄目？
PermitEmptyPasswords は password 認証に対してしか使えないのね．
343 ：330：02/05/19 00:23
>>340
いや、俺が言いたいのは、>>339も言ってるように
本来 ~/.ssh/identity が漏れたときの保険として設定するものである
SSHのpassphraseを認証に用いるのは変じゃない? ってこと。
あくまで保険だからpassphraseを空にするのも許されているし、
実際に空のpassphraseを使っている人も少なくないと思う。
# どこかのメーリングリストで、「ホームディレクトリをNFSで
# 共有しているのにSSHのpassphraseを空にする人が多くて
# 困っています。passphraseを付けることを強制する方法は
# ありませんか?」って質問があった記憶が。
最初から認証目的で作られたS/keyやKerberosと同列に扱うのはどうもねえ…
あと、SSHのpassphraseをUNIXパスワードと同じにすることによる
デメリットが思いつかないのも理由のひとつ。
いや、俺が言いたいのは、>>339も言ってるように
本来 ~/.ssh/identity が漏れたときの保険として設定するものである
SSHのpassphraseを認証に用いるのは変じゃない? ってこと。
あくまで保険だからpassphraseを空にするのも許されているし、
実際に空のpassphraseを使っている人も少なくないと思う。
# どこかのメーリングリストで、「ホームディレクトリをNFSで
# 共有しているのにSSHのpassphraseを空にする人が多くて
# 困っています。passphraseを付けることを強制する方法は
# ありませんか?」って質問があった記憶が。
最初から認証目的で作られたS/keyやKerberosと同列に扱うのはどうもねえ…
あと、SSHのpassphraseをUNIXパスワードと同じにすることによる
デメリットが思いつかないのも理由のひとつ。
344 ：2chBSD：02/05/19 02:27
久しぶりに make world したら 4.6-RC だった。
345 ：名無しさん＠お腹いっぱい。：02/05/19 02:29
>345
Apache付属のabでみるかぎり、ほとんど変化は無いね。
まあ、2時間弱で答えだすのもどうかと思うが。
>mergeするのがめんどい
4.5-STABLE からだと mergemaster -svir
で m を押す機会もそれほど多く無かったよ。
Apache付属のabでみるかぎり、ほとんど変化は無いね。
まあ、2時間弱で答えだすのもどうかと思うが。
>mergeするのがめんどい
4.5-STABLE からだと mergemaster -svir
で m を押す機会もそれほど多く無かったよ。
347 ：名無しさん＠お腹いっぱい。：02/05/19 03:02
>>346
> 4.5-STABLE からだと mergemaster -svir
> で m を押す機会もそれほど多く無かったよ。
いや、4.5R-p4からなんだ。
mergeするのが面倒でRELENG_4_5を追っているわけで。
> 4.5-STABLE からだと mergemaster -svir
> で m を押す機会もそれほど多く無かったよ。
いや、4.5R-p4からなんだ。
mergeするのが面倒でRELENG_4_5を追っているわけで。
348 ：名無しさん＠お腹いっぱい。：02/05/19 10:30
>>347
mergemasterに-sを付けなきゃもっと楽だと思うぞ
mergemasterに-sを付けなきゃもっと楽だと思うぞ
>>343
そうか? やっぱり変だよ。ていうか矛盾してるだろ。
> 本来 ~/.ssh/identity が漏れたときの保険として設定するものである
> SSHのpassphraseを認証に用いるのは変じゃない? ってこと。
これを主張するなら、passphrase を UNIX password と同じに「しないといけない」
という条件をつけるのだって変じゃない?
空 passphrase を設定するユーザがいる、という以外での懸念事項はある?
なければ pam_ssh では空 passphrase での認証を拒否するようにする、
というのが正しい道だと思う。
> あと、SSHのpassphraseをUNIXパスワードと同じにすることによる
> デメリットが思いつかないのも理由のひとつ。
passphrase を空にするようなユーザだったら passphrase の管理だって
甘そうだから、結果的に UNIX passwaord の漏洩につながるわな。
というのがコジツケだと感じたら、>>343 にもそういう箇所がないかどうか
読み返してみてくれ。
そうか? やっぱり変だよ。ていうか矛盾してるだろ。
> 本来 ~/.ssh/identity が漏れたときの保険として設定するものである
> SSHのpassphraseを認証に用いるのは変じゃない? ってこと。
これを主張するなら、passphrase を UNIX password と同じに「しないといけない」
という条件をつけるのだって変じゃない?
空 passphrase を設定するユーザがいる、という以外での懸念事項はある?
なければ pam_ssh では空 passphrase での認証を拒否するようにする、
というのが正しい道だと思う。
> あと、SSHのpassphraseをUNIXパスワードと同じにすることによる
> デメリットが思いつかないのも理由のひとつ。
passphrase を空にするようなユーザだったら passphrase の管理だって
甘そうだから、結果的に UNIX passwaord の漏洩につながるわな。
というのがコジツケだと感じたら、>>343 にもそういう箇所がないかどうか
読み返してみてくれ。
350 ：名無しさん＠お腹いっぱい。：02/05/19 19:11
>>348
うむ、俺も mergemaster に -s はつけないな。
# mergemaster -ai
# mergemaster -r
ってやってる。
ちょっと前の users-jp で同じ話題があったから検索しる。
うむ、俺も mergemaster に -s はつけないな。
# mergemaster -ai
# mergemaster -r
ってやってる。
ちょっと前の users-jp で同じ話題があったから検索しる。
351 ：名無しさん＠お腹いっぱい。：02/05/20 00:05
5月19日現在
4.5-RELEASE-p5
4.5-RELEASE-p5
352 ：名無しさん＠お腹いっぱい。：02/05/20 01:36
>>349
うーん、矛盾してるとは思えないんだけどなー。
> passphrase を UNIX password と同じに「しないといけない」
って言い方がまずいのかな。こう言い替えるとどう?
「>>330の設定を行なっても、ログインの方法は
UNIX passwordだけで変わりなし。
ただ、~/.ssh/ 以下にそのUNIX passwordと同じpassphraseで
暗号化された認証鍵があった場合は、自動的にdecryptして
ssh-agentを起動させることができる。」
だから、空のpassphraseを設定しているユーザがいるかもしれない
という状況でも気兼ねなく導入できる。
あと、
> passphrase を空にするようなユーザだったら passphrase の管理だって
> 甘そうだから、結果的に UNIX passwaord の漏洩につながるわな。
の意味がよくわからん。
SSHのpassphraseは簡単に空にできるけど、
UNIX passwordを空にすることは一般ユーザにはできないでしょ。
うーん、矛盾してるとは思えないんだけどなー。
> passphrase を UNIX password と同じに「しないといけない」
って言い方がまずいのかな。こう言い替えるとどう?
「>>330の設定を行なっても、ログインの方法は
UNIX passwordだけで変わりなし。
ただ、~/.ssh/ 以下にそのUNIX passwordと同じpassphraseで
暗号化された認証鍵があった場合は、自動的にdecryptして
ssh-agentを起動させることができる。」
だから、空のpassphraseを設定しているユーザがいるかもしれない
という状況でも気兼ねなく導入できる。
あと、
> passphrase を空にするようなユーザだったら passphrase の管理だって
> 甘そうだから、結果的に UNIX passwaord の漏洩につながるわな。
の意味がよくわからん。
SSHのpassphraseは簡単に空にできるけど、
UNIX passwordを空にすることは一般ユーザにはできないでしょ。