SSH その5

**名無しさん＠お腹いっぱい。** · 2006/04/20(木) 07:09:00

SSHに関する情報交換のスレッドです。
FAQ、リンク集は >>2-5 あたり。

過去ログ
　Part1：http://pc.2ch.net/unix/kako/976/976497035.html
　Part2：http://pc.2ch.net/unix/kako/1028/10281/1028157825.html
　Part3：http://pc5.2ch.net/unix/kako/1058/10582/1058202104.html
Part4：http://pc8.2ch.net/test/read.cgi/unix/1102242908/

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 19:29:48

SSHH シシハハ

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 19:33:31

>>120
よく読め。

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 20:52:11

>>116
denyhostsしてるし…

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 18:08:38

RSAとDSAってどっちが良いの？

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 18:55:40

DSAならキーボードからの打ち間違えが少ない

**124** · 2006/06/13(火) 19:24:12

すまんせん意味分からんス

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 19:34:48

どっちでもいいんじゃね？

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 19:41:12

w
qwertyみたいにホームポジションから動かなくても打てるからかヨw

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 12:09:12

ちょっと質問というか相談なのですが、↓のサイトの
ttp://www.banana-fish.com/~piro/20040609.html#p06
結論として、「自動運転のためにssh-agent常駐させるなら、パスフレーズ無しの自動運転専用鍵を作り、
その鍵を使ってできるコマンドを必要最小限に制限する」がベストということですが、そうなんですか？
＞パスフレーズはいざという時の時間稼ぎでしかない。
というのには同意ですが、でもそれはそれで意味はありますよね。
なんかこのページの趣旨が分からないっす。というかコマンドごとに鍵作るなんて面倒すぎる…

よりセキュアにってことだと思いますが、セキュアにするならそもそも自動運転など…と思ってしまうわけで。
みなさんはどう思われますか＆自動運転はどういうふうにやってますか？

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 12:20:05

>>129
パスフレーズはどうするのがいいと思うの?
expect で自動化? 平文でどっかに書いとくの?

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 13:47:08

セキュアにしたいなら毎回パスワードを入力した方が良いんじゃないの。
セキュリティを犠牲にしてでも手間を省きたいならssh-agentを使えばいいじゃん

**129** · 2006/06/14(水) 21:55:03

>>130
いや、パスフレーズは適当に（できれば通常のログインパスワードより長めに）
expectはありえないのでは？平文で書くなんて恐ろしすぎる…
自分はssh-agent＋ssh-addで自動運転、が普通だと思ってました。

>>131
パスワード認証ってことですか？それだとパスワードを相手ホストに送ってることになりますよね（まぁ暗号化はしてますが）
普通、セキュアな順に公開鍵認証、ホストベース認証、パスワード認証で、sshも認証の優先順位はこの順だったと思いますが

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 22:39:23

パスワード認証の話ですけど

暗号化されたパスワードであっても盗聴は出来るんだから

それをそのまま突っ込まれればやばくないですか？

**ヽ(´ー`)ノ** ◆.ogCuANUcE · 2006/06/15(木) 00:19:41

>>129
概ね同意できると思うが。

1. ssh-agent常駐させるなら、パスフレーズ無しの自動運転専用鍵を作る

パスフレーズなんて飾り。一方で、再起動の度にパスフレーズが必要という
手間がある。従って、手間に見合った効果がない(と思われる)。

2. その鍵を使ってできるコマンドを必要最小限に制限する

至極当たり前の考え。

自動運転 → コマンド内容も自動 → 実行されるコマンドは常に一定
→ 他のコマンドは使えないようにしてしまえ

パスワード認証は駄目だな。
自動運転が前提なんだから、ssh-agent みたいに毎回手入力するか、
expect のように平文でどこかに置いておく必要がある。まったく意味がない。

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 01:16:50

>>132
> 自分はssh-agent＋ssh-addで自動運転、が普通だと思ってました。

ssh-agentの乗っ取りにはどう対処する?

ssh-agentの開いたソケット(/tmp/ssh-xxx/agent.1234みたいなの)にアクセスできれば、
そのagentが記憶している全ての鍵は使い放題だし、
デバッガ等でssh-agentプロセスのメモリ空間を覗くことができれば生の秘密鍵が手に入る。

ssh-agentを乗っ取られないようにアクセス制限をかけることと、
パスフレーズ無しの秘密鍵を盗まれないようにアクセス制限をかけることに
どれだけの違いがある?
パスフレーズを毎回手入力しなきゃならないデメリットにも勝るものか?

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 02:10:24

公開鍵認証なんて秘密鍵を盗まれればおしまいだよ。

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 02:22:02

盗まれたら速攻でrevokeっしょ。

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 02:49:36

確認せずに yes 連発するやつらばっかりだから MITM でいいよ。

**ヽ(´ー`)ノ** ◆.ogCuANUcE · 2006/06/15(木) 05:40:32

>>136
鍵を盗まれてから trust な鍵のペアに交換するまでの時間が稼げる分、
パスフレーズ付きが若干有利ってだけで、結局それに尽きる。

「正規のユーザしか秘密鍵を持っていない」ってのが鍵交換認証の肝なんで、
これが破られるとどうしようもない。

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 06:36:30

Theoみたいな奴がそう簡単に秘密鍵を盗まれるのか？

**132** · 2006/06/15(木) 15:01:11

>>135
＞ssh-agentの乗っ取りにはどう対処する?
もちろんお手上げですよ。だからある程度安全だと確信できるホスト以外では使わない。
自分の考えは>>139と同じです。パスフレーズはないよりあったほうがマシ。秘密鍵盗られたらｵﾜﾘ。

このへんは各々の前提や考え方（と好み）などによるってことですね。
自分はリモートログインにコマンド制限は一切かけたくない、というのが第一の前提で、
その上で秘密鍵盗難の危険が高いなら自動運転しない、低いならする、という考えです。

まぁいずれにせよ、自動運転なんて軽々しくやるもんじゃないと…

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 15:43:17

すべてのマシンで同じ鍵を使用しているのですが、マシンごとにそれぞれ鍵を作る
のが一般的なのでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 21:03:39

そう。

**名無しさん＠お腹いっぱい。** · 2006/06/16(金) 19:27:23

認証転送使えばssh-agent乗っ取りのリスクも少しは軽減されるんすか？
ttp://www.h7.dion.ne.jp/~matsu/feature/uzumi/tool_memo/ssh.html#1

**名無しさん＠お腹いっぱい。** · 2006/06/17(土) 13:33:24

>>144
いや、認証転送に使うソケット(agent単体のときと同じく/tmp以下に作られる)に
アクセスされるとマズいのは変わらん。
まあ、便利さの裏側には何らかのセキュリティリスクがつきまとうものだ、っていう
至極あたりまえのことですな。

**名無しさん＠お腹いっぱい。** · 2006/06/24(土) 16:40:02

いくつもある UNIX 鯖に Windows マシンからトンネル張るために
毎度毎度 ssh クライアントでログインしなくてもいいように、
Windows のダイヤルアップアダプタか VPN アダプタのように扱える
SSH ポートフォワーディング用のソフトってないですかね・・・

ore.no.host.example.com 宛に接続が必要になると
自動的にあらかじめ登録した鍵を使ってあらかじめ決めた
ポートだけトンネルされた状態で接続してくれるような・・

**名無しさん＠お腹いっぱい。** · 2006/06/24(土) 17:08:25

plink

**名無しさん＠お腹いっぱい。** · 2006/06/24(土) 18:49:25

PortForwarder
http://www.fuji-climb.org/pf/JP/

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 06:01:33

顧客がsshのポートフォワーディングであることを意識せずに
使えるように、Windowsのネットワークアダプターのユーザーインターフェースに
統合されているようなsshクライアント製品ってありませんか？

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 06:27:57

otp でいいじゃん

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 10:18:13

なんでもかんでもsshで解決しようとするのか

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 10:21:20

>>151 他の方法での通信を組織がポリシーとして許してくれない。

**名無しさん＠お腹いっぱい。** · 2006/06/26(月) 20:58:55

[1] 入門OpenSSH
　　http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1348-X

キタァ！　ヽ(ﾟ∀ﾟ)ノ　ヽ(ﾟ∀ﾟ)ノ　ヽ(ﾟ∀ﾟ)ノ　ヽ(ﾟ∀ﾟ)ノ

from
　コンピュータ関連書籍新刊一覧
　http://pc.watch.impress.co.jp/docs/2006/market/i_nbook.htm

参考までに、既刊書籍：

[2] 入門SSH
　　http://www.ascii.co.jp/books/books/detail/4-7561-4553-1.shtml

[3] (絶版)OpenSSH セキュリティ管理ガイド
　　http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-0129-5

**名無しさん＠お腹いっぱい。** · 2006/06/27(火) 18:42:57

どんな時に、sshのhost-keyは変わりますか？

#Fedora Core 5 の初期設定中にトラブルがいろいろと発生して、X-windowとかが飛んだのでまた再インストールorz

**名無しさん＠お腹いっぱい。** · 2006/06/27(火) 20:10:54

>>154
host-keyを変えたとき

**名無しさん＠お腹いっぱい。** · 2006/06/27(火) 20:40:30

「入門OpenSSH」買ってきた。
巻末の「著者紹介」がなくなってた。まあ、どうでもいい(DDI)けど。

**名無しさん＠お腹いっぱい。** · 2006/06/28(水) 02:12:41

>>154
ホストをクラックされて host key を変えられたとき
MITM されてるとき

**名無しさん＠お腹いっぱい。** · 2006/06/30(金) 00:59:53

[3]は持ってるんだけど、
[1]はその改訂版なの？
あと対応バージョンはいくつなんだろう

**名無しさん＠お腹いっぱい。** · 2006/06/30(金) 14:35:30

あげ

**名無しさん＠お腹いっぱい。** · 2006/07/05(水) 22:53:49

bit数ってみんなどれくらいにしてまつか？
2048じゃ今時足りない？

**名無しさん＠お腹いっぱい。** · 2006/07/06(木) 15:38:34

http://www.atmarkit.co.jp/flinux/rensai/linuxtips/363rbashuser.html
@ITのこの記事読んで特定のコマンドしか実行できないユーザ作ったんですが。

これってそのrestrictedユーザ@hostががfoo@barとすると

ssh foo@bar bash -i

で簡単に回避されてしまうんですが。
これを回避して/bin/rbash以外起動できないようにする方法はありませんか？

いじるファイルによってはスレ違いかもしれませんが、一応fooはssh経由でしか入ってこないので。

**名無しさん＠お腹いっぱい。** · 2006/07/06(木) 15:46:56

>>161
man sshd
AUTHORIZED_KEYS FILE FORMAT
...
command="command"
Specifies that the command is executed whenever this key is used
for authentication. The command supplied by the user (if any) is
ignored. The command is run on a pty if the client requests a
pty; otherwise it is run without a tty. If an 8-bit clean chan-
nel is required, one must not request a pty or should specify
no-pty. A quote may be included in the command by quoting it
with a backslash. This option might be useful to restrict cer-
tain public keys to perform just a specific operation. An exam-
ple might be a key that permits remote backups but nothing else.
Note that the client may specify TCP and/or X11 forwarding unless
they are explicitly prohibited. Note that this option applies to
shell, command or subsystem execution.

**161** · 2006/07/06(木) 15:54:49

>>162
ありがとうございます。…やっぱそれしかありませんかね？
今の環境がパスワード認証なのでそれを維持したままの方法がないかと模索していたのですが。

**名無しさん＠お腹いっぱい。** · 2006/07/06(木) 16:33:08

>>161
これってフルパスでコマンド実行できない？？

**名無しさん＠お腹いっぱい。** · 2006/07/06(木) 16:50:41

/etc/exportsの(の前にスペース入れちゃう人だからねえ

**161** · 2006/07/06(木) 16:59:06

>>164
記事にも書いていますが、実際にフルパスでコマンドを起動しようとするとrestricedとしてエラーになります。
なので必要最低限のコマンドだけ与え、PATHを制限したうえで、.bashrcと.bash_profileを編集不可にしてしまえばそれ以外のコマンドは起動できなくなります。

後はログイン時にrbash以外起動できなくすれば良いのですが、>>162の方法だけかな。

>>165
怖っ！ｗ

スレ違い気味になってきましたね、すみません。

**名無しさん＠お腹いっぱい。** · 2006/07/08(土) 07:03:30

もしrootの人に秘密鍵を盗まれてしまったら、そのrootの人は、公開鍵を置いてあるサーバに自由にアクセスできるようになってしまうのでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/07/08(土) 08:47:47

>>167
つパスフレーズ

**名無しさん＠お腹いっぱい。** · 2006/07/08(土) 14:59:02

linux debian スレから来ました。クライアントCから
sshで同じローカルネットのサーバーA,Bに入って、kterm&
すると、Aは窓が開くのにBは窓が開かない現象に出くわしています。
ABともに、/etc/ssh/sshd_configのX11ForwardingはYesなのに、
sshでBに入ると$DIAPLAYが設定されておらず、無理やり-display :10.0
とやっても、Can't open displayでけられます。

Bのsshd -d -d -dで出力のこの辺みろとか、なにかアドバイスいただけ
ると助かります。

**169** · 2006/07/08(土) 19:02:51

すみません。自己解決できました。Bはxserverなしの鯖で、xtermだけ
いれてやってたんですが、xauthが入っていないとsshのX11Forwarding
は機能しないんですね。勉強になりました。

**167** · 2006/07/08(土) 19:33:43

パスフレーズは設定していません

**名無しさん＠お腹いっぱい。** · 2006/07/08(土) 19:46:34

おわた

**名無しさん＠お腹いっぱい。** · 2006/07/09(日) 00:21:28

>>171
それはもうだめかもわからんね。

**名無しさん＠お腹いっぱい。** · 2006/07/09(日) 12:03:52

公開鍵を換えなさい

**名無しさん＠お腹いっぱい。** · 2006/07/09(日) 14:20:05

/etc/sshのconfigファイル、ほとんど#がかかってるけど一体どれがデフォになってるのかﾜｹﾜｶﾒ

**名無しさん＠お腹いっぱい。** · 2006/07/09(日) 15:03:56

環境を書かないとはこれいかに。

**名無しさん＠お腹いっぱい。** · 2006/07/09(日) 19:19:46

#がデフォルトだろ

**名無しさん＠お腹いっぱい。** · 2006/07/10(月) 15:02:24

入門OpenSSH
ttp://www.amazon.co.jp/gp/product/479801348X/

**名無しさん＠お腹いっぱい。** · 2006/07/10(月) 21:42:14

>>177
そうとはかぎらんよ

**名無しさん＠お腹いっぱい。** · 2006/07/10(月) 21:58:16

# 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.

**名無しさん＠お腹いっぱい。** · 2006/07/11(火) 03:31:36

----修正前
# PasswordAuthentication yes

...

# PermitRootLogin yes
----修正前

----修正後
# PasswordAuthentication yes
PasswordAuthentication no

...

# PermitRootLogin yes
PermitRootLogin no
----修正後

**名無しさん＠お腹いっぱい。** · 2006/07/11(火) 12:17:03

opensshでサーバ証明書じゃなくて個人証明書で認証を行わせることってできるでしょうか。

**名無しさん＠お腹いっぱい。** · 2006/07/11(火) 17:00:13

>>179
どっちなのよ？

#がデフォとするなら、変えるときは>>181のように行を追加して、元に戻すときは削除するってことかい？

**名無しさん＠お腹いっぱい。** · 2006/07/11(火) 23:39:34

デフォルトの値を知りたきゃmanすれ。

**名無しさん＠お腹いっぱい。** · 2006/07/12(水) 09:36:33

manはたまに信用ならんからソース嫁

**名無しさん＠お腹いっぱい。** · 2006/07/12(水) 10:40:49

ﾒﾝﾄﾞｸｾ

**名無しさん＠お腹いっぱい。** · 2006/07/12(水) 12:16:23

>>186
んじゃ2chで聞け

(>>175にﾓﾄﾞﾙ)

**名無しさん＠お腹いっぱい。** · 2006/07/12(水) 12:52:11

なんでずっと環境隠してるんだろう。

**名無しさん＠お腹いっぱい。** · 2006/07/12(水) 22:32:07

>>186
じゃあ、デフォ使わないで明示的に指定
した方が早い気ガス

**名無しさん＠お腹いっぱい。** · 2006/07/12(水) 23:04:47

parent_domain_matches_subdomainsがけしからん！

**名無しさん＠お腹いっぱい。** · 2006/07/13(木) 22:40:06

man sshd_configにRhostsRSAAuthenticationとHostbasedAuthentication は似てるってあるけど、全く同じなんじゃないの？
クライアントの公開鍵がsshサーバの~/.ssh/known_hostsに入ってるかどうか、ってことでそ？
誰か教えてください

**名無しさん＠お腹いっぱい。** · 2006/07/14(金) 00:07:49

>>191
SSHプロトコルのバージョンの違い。前者（RhostsRSAAuthentication）はバージ
ョン1のみで、後者（HostbasedAuthentication）はバージョン2のみで使われる。

内容が同じなのか、また両者を１つの項目に統合してしまっても問題ないのかまで
は分からない。（※個人的には、何らかの理由があって分けたのではないかと思っ
ているけど。）

**名無しさん＠お腹いっぱい。** · 2006/07/14(金) 17:15:35

クライアントの公開鍵じゃなくて、クライアントで動いているsshdの公開鍵。
だからsshdの秘密鍵にアクセスできる必要がある。

RhostsRSAAuthenticationとHostbasedAuthenticationはssh1とssh2のそれぞれで
設定が可能になっている。
でも、今どきはssh1は普通無効なのでRhostsRSAAuthenticationは使わない。

**191** · 2006/07/14(金) 17:28:48

あ、そうか
「ホスト」単位で認証するんだから、クライアントのホスト鍵＝sshdの公開鍵＝/etc/ssd/ssh_***.pubっすね
ありがとうございますた

**191** · 2006/07/14(金) 22:36:26

何度もすいません。追加質問お願いします。家のマシンでテストしていたんですが
Hostbased認証にはssh-keysignをsetuidする必要があるそうですが、setuidしてないのにログインできるマシンがあります。
よく見ると「Have a lot of fun...」の直後に「Agent pid 566」とか出て、ssh-agentが走っているようです。
ssh-agentって公開鍵認証（sshd_configでPubkeyAuthentication yes)で使うものですよね？
なぜこれが起動するんでしょうか？
他のマシンでは正常にホストベース認証でログインできました（もちろんssh-keysignにsetuidを立てないとエラー）

ちなみに問題のマシンのsshバージョんはOpenSSH_3.7.1p2,です

**名無しさん＠お腹いっぱい。** · 2006/07/16(日) 03:18:40

ssh-agentが起動するのはシェルのスタートアップファイルがそのように書いてあるから。

**名無しさん＠お腹いっぱい。** · 2006/07/16(日) 05:39:18

ホストで認証するのは危険ですか？

**名無しさん＠お腹いっぱい。** · 2006/07/16(日) 20:16:45

>>197
いいえ、それはトムです。

**195** · 2006/07/17(月) 16:04:58

>>196
ほんとだアホすぎる・・・orz
thxです

**名無しさん＠お腹いっぱい。** · 2006/07/22(土) 18:21:43

RSAAuthentication　と　RhostsRSAAuthentication の違いを教えてください。manだと、
　RSAAuthentication・・・RSA認証
　RhostsRSAAuthentication ・・・RSA ホスト認証を使った Rhosts ベースの認証
のようですが、つまり後者は前者のRSA認証にrhosts、shostsファイルによる認証を加えたもの、ということですか？

**名無しさん＠お腹いっぱい。** · 2006/07/22(土) 19:57:12

>>200
10 レス前も読まないのか

**名無しさん＠お腹いっぱい。** · 2006/07/22(土) 19:58:20

>>200
違ったねごめんね

**名無しさん＠お腹いっぱい。** · 2006/07/23(日) 10:03:49

最近中国とか台湾とか韓国方面からの ssh password アタックが多いので…

同じIP address から短時間に 10回以上
アクセスがあったら(login error 回数だと尚良い)
そのアドレスにたいしては sshd を1時間 shutout する、
なんていう設定ができないかと思っているんですが
sshd の機能だけでは出来ないんですよね?
似たような話でも良いのですが、なにか方法はあるのでしょうか?

環境: OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1

(できれば公開鍵 only ではなく password 認証は生かしておきたいです)

**名無しさん＠お腹いっぱい。** · 2006/07/23(日) 10:49:25

>>203
普通に、ssh接続する接続元のIP以外はFWではじくのがベスト。
でなければ、中国とか台湾とか韓国のIPを根刮ぎDeny汁

**名無しさん＠お腹いっぱい。** · 2006/07/23(日) 12:24:22

http://www.itmedia.co.jp/help/tips/linux/l0541.html
http://www.bsp.brain.riken.jp/~washizawa/ssh.html
http://yoosee.net/d/archives/2005/11/08/002.html
このへんを参考に。

**名無しさん＠お腹いっぱい。** · 2006/07/23(日) 16:21:03

>205
thx. MaxStartups の 3:30:20 みたいな表記がほぼズバリでした

>204
出張その他でいろいろな所から接続するので接続元は特定できないのと、
家族のアカウントのことは証明書ベースにするのはちょっと
面倒だったんで...

まあ CKT 方面は ssh に関しては deny したいところですけどね...

**名無しさん＠お腹いっぱい。** · 2006/07/23(日) 19:41:13

>>203＝>>206
sshdを別のポート番号で動かすのが手っ取り早いんじゃないかと思う。
そのマシンにログインする人全員にそのことを知らせる必要があるけれども。

# >>205の３つめのwebページからもリンクされている、
# 　http://www.unixuser.org/~haruyama/security/openssh/20051108.html
# を参照ってことで

**153** · 2006/07/23(日) 19:50:55

>>153
> [1] 入門OpenSSH
> 　　http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1348-X
>
> キタァ！　ヽ(ﾟ∀ﾟ)ノ　ヽ(ﾟ∀ﾟ)ノ　ヽ(ﾟ∀ﾟ)ノ　ヽ(ﾟ∀ﾟ)ノ

某大学の図書館に入ったヽ(ﾟ∀ﾟ)ノので、さっそく借りてきた。
# [3]は、リクエストしたのになんだかんだ言って入らないまま時間が過ぎてついに
# 絶版になっちまってｺﾝﾁｸｼｮｰだったので、よかったYO

以上、チラシの裏ｗ

>>158
> [3]は持ってるんだけど、
> [1]はその改訂版なの？
> あと対応バージョンはいくつなんだろう

[1]では4.3を対象として書かれているようですね。

**200** · 2006/07/24(月) 12:16:45

何か勘違いしてますね自分・・・↓を見たのですが
ttp://www.unixuser.org/~euske/doc/openssh/jman/sshd_config.html
RSAAuthenticationは「純粋なRSA認証」とありますが、これはいわゆるパスワード認証のことですか？
通信の通路はRSAで暗号化するのだから、パスワード認証もホストベース認証もみんなRSAは使ってるわけですよね？

ss1の話で今更あまり意味ないかもしれませんが、いちおう理解しておきたくて・・・

**名無しさん＠お腹いっぱい。** · 2006/07/24(月) 17:13:15

>>209
> RSAAuthenticationは「純粋なRSA認証」とありますが、これはいわゆるパスワ
> ード認証のことですか？

違います！
SSHプロトコル1.xでの公開鍵認証、です。RSAを使うんで、「RSA認証」と呼ばれて
いるわけだ。

sshd_configでの設定項目：
　公開鍵認証：RSAAuthentication（1.x），PubkeyAuthentication（2.0）
　パスワード認証：PasswordAuthentication（1.x,2.0共通）

**名無しさん＠お腹いっぱい。** · 2006/07/24(月) 18:10:04

>通信の通路はRSAで暗号化するのだから、

いや通信経路は RSA 使わないよ?
経路の暗号化は共通鍵方式。
いろいろとキホンを勉強してから個別資料のほうがいいと思うぞ

**209** · 2006/07/25(火) 03:59:39

>>210
公開鍵認証だったんですかー！ありがとうございました。
でもどっちも公開鍵認証なんなら
RSAAuthentication→PubkeyAuthentication1
PubkeyAuthentication→PubkeyAuthentication2
みたいにしてくれれば分かりやすいのに。"RSAを使ったAuthentication"は他にもいろいろあるのだし・・・
歴史の流れでそうなってるってことでしょうかね？

>>211
通信コストを下げるために公開鍵暗号は最初の認証のみで、後は共通鍵みたいですね。知らなかった
でも、使う共通鍵はホストとクライアントどちらのものなんでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/07/25(火) 06:16:42

sshでサーバに繋ぐときに、GlobalKnownHostsFile(/etc/ssh/ssh_known_hosts)で
許可していないホストを、勝手にユーザの~/.ssh/known_hostsにそのホスト認証鍵を
追加させたくないのですが、どうすればいいでしょうか。
とりあえず、/etc/ssh/ssh_configに
StrictHostKeyChecking yes
としておけば、未知のホストに接続した場合のfingerprintを聞いてこないので、抑止
にはなるかと思うのですが、ユーザが
% ssh -o StrictHostKeyChecking=no remote-address
とした場合、ssh_configの設定が上書きされるので、どうしたものかと思っています。
何か良い方法がありますでしょうか。

sshd_configの場合、IgnoreUserKnownHostsオプションがあるので良いのですが。。。

環境は、FreeBSD 5.3R OpenSSH_3.8.1p1です。

**名無しさん＠お腹いっぱい。** · 2006/07/25(火) 10:14:08

>>213
なんでそんなことしたいんだろう。
ファイアウォールで閉じるとかじゃだめなん?

**名無しさん＠お腹いっぱい。** · 2006/07/25(火) 10:52:24

理由はわからないが、ソースが公開されているのだから、修正して
そのオプションを削れば済むこと。

**名無しさん＠お腹いっぱい。** · 2006/07/25(火) 10:53:21

~/.ssh/known_hosts をルート所有のリードオンリーにする。

**名無しさん＠お腹いっぱい。** · 2006/07/25(火) 10:58:11

>>216
それじゃファイル消して新しく作られて終わりじゃね?

**名無しさん＠お腹いっぱい。** · 2006/07/25(火) 11:12:53

>>215
自力でコンパイルされたら終わりじゃね?

**名無しさん＠お腹いっぱい。** · 2006/07/25(火) 11:27:05

結局ファイアヲールで防ぐしかないんじゃね？

**213** · 2006/07/25(火) 12:41:59

>>214-219
サンクス。
ファイアウォールで制限する事にしました。妙な方向に考えていたようです。
そもそもの理由は、sshのクライアントとサーバ間でホスト認証＆相互認証を
しようとして、sshd側は、クライアントのホスト公開鍵を/etc/ssh/ssh_known_hostsに
設定し、sshd_configのIgnoreUserKnownHosts,IgnoreRhostsの設定でユーザが故意・事故で
~/.ssh/に変なクライアントからの接続の許可を無視できればＯＫと考えた。
でも、ssh側は、/etc/ssh/ssh_known_hostsにサーバのホスト公開鍵を設定しても、
ユーザの設定（コマンドラインの-o指定や~/.ssh/config）で上書きされてしまったら、
意味がないかな？と思っていた次第です。
（たとえば、鍵指紋を何も考えずにEnter押すようなユーザや、サーバホスト鍵が変更されてる
というワーニングがでたら~/.ssh/known_hostsの該当部分を削除してしまうようなユーザを制限
できたらと考えていたのですが。）

>>216
ちなみに該当ファイルをReadOnlyにしても接続時に「ファイルに書き込むのに失敗した」という
旨のエラーがでるだけで接続自体は行うようです。