ssh

1 ：エニグマ ：2000/12/11(月) 10:10

についての情報交換。

2 ：名無しさん＠お腹いっぱい。 ：2000/12/11(月) 10:51

そうだ、前から訊きたかったんだ。

RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication no
TISAuthentication no
PasswordAuthentication yes

だとパスワードは平文なの？
# ソース読め？めんどうだなあ。

3 ：名無しさん＠お腹いっぱい。 ：2000/12/11(月) 12:59

>>2 sshd と ssh 間の通信は基本的に暗号化されているから、
パスワードはネットワーク上を流れるが平文ではない。

4 ：2 ：2000/12/11(月) 20:20

>>3
お互い鍵がわからない状態でも暗号化するんですか？
乱数で作った共有秘密を平文（同然）で交換してそれで暗号化するとか？
# ああ、なんか勘違いしてそうだ

5 ：名無しさん＠お腹いっぱい。 ：2000/12/11(月) 21:40

APOPとかで使ってるワンタイムパスワードと同じ理屈だったと思ったが。

6 ：名無しさん＠お腹いっぱい。 ：2000/12/11(月) 23:33

公開キーを使って秘密キーの交換をするんでしょ？
SSLと同じやり方だと思ったが
２回目以降の接続は、（保存してあれば）手元の公開キーを使う、と

7 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 00:00

>>6
PasswordAuthentication yes の場合だろ。
これには公開鍵云々は関係ない。
>>5 が正解じゃなかったっけ？

8 ：2 ：2000/12/12(火) 00:13

どうも。やっぱソース見るかぁ。

>>5,7
でも /etc/passwd だよねえ？ ←実は RSAAuth しか使ったことないらしい
生パスワードが無いから APOP 方式は使えないのでわ？

9 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 00:15

ホスト公開鍵＆秘密鍵、ユーザ公開鍵＆秘密鍵、
セッション鍵、パスフレーズ、普通のパスワード
の区別をつけないと。

10 ：2 ：2000/12/12(火) 00:18

>>9
そう、だから公開鍵をリモートに置いてない場合、セッション鍵を交換
する前のパスワードはどう保護してるかな？　と思って。
# それが気になってず〜っと RSA 以外使ってない

11 ：5 ：2000/12/12(火) 01:15

いや、だからワンタイムパスワードの理屈で暗号化されたセッション間を
(生パスが)流れるから、結果的に暗号化はされるちゅう事だと思ったが。

12 ：5 ：2000/12/12(火) 01:17

もちろん生パス流す事には変わりないので、なるべく使わない方がいいのは
言うまでもない。
# 最近のsshd_configにもPasswordAuthenticationは「offにしろ」と
# 書かれてるよね

13 ：5 ：2000/12/12(火) 01:18

ごめん書き方が悪かった。
>もちろん生パス流す事には変わりないので
は
>もちろん生パスを打ち込む事には変わりないので
に訂正。

14 ：名無しさん＠腹一杯 ：2000/12/12(火) 03:03

Cygwin でも最近は openssh が入るんだね。
Win なクライアントから slogin とかscp ができて便利便利。
http://sources.redhat.com/cygwin/

あと、PuTTY の pscp も使える。plink も。
http://www.chiark.greenend.org.uk/~sgtatham/putty/
# PuTTY 自身は日本語通さないから辛い。

パスワード/データの通信路を暗号化ってことなら、
既存の ftp クライアントがインターフェースに使える
SafeTP なんてのもあった。
http://www.cs.berkeley.edu/~smcpeak/SafeTP/

15 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 03:20

>>14 CygwinでもOpensshが入るって、ものすごく貴重。特にscp。

16 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 07:40

一応sshdも動くんだけど、まだちょっと動作が変な感じ > Cygwin

Win9xとかFATで使ってる場合、秘密鍵他人に読まれちゃう危険性はある
んで、意図的にPasswordAuthentication使うのもありかも。

17 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 08:55

Cygwinのsshdってちゃんと使えるのかな?
http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=971354040&ls=50

18 ：2 ：2000/12/12(火) 09:10

>>12
> いや、だからワンタイムパスワードの理屈で暗号化されたセッション間を
> (生パスが)流れるから、結果的に暗号化はされるちゅう事だと思ったが。
ごめんなさい、やっぱりわかりません。
「ワンタイムパスワードの理屈」をわかってないのだと思うのですが、
この仕組みは
「両端はあらかじめ共通の秘密を知っていて、両者が同一であることを確認できる」
というものですよね？（少なくとも APOP のはそうですよね）

両端が共通して知っているのは「パスワード」だけですが、こいつはサーバ側では
crypt(3) されてるから使えないのではないか？　と思ったのですが、、、

僕はどこを間違えているのでしょう？？

19 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 11:38

ここを見よ:
http://tanaka-www.cs.titech.ac.jp/%7Eeuske/doc/openssh/man-sshd.html

20 ：14 ：2000/12/12(火) 12:03

>>15-17
えと、クライアントとしての ssh/scp が便利ね。
sshd(って言うのか？) を動かしてwinに入る方は期待してないっす。

>>18
1. (loginするときの)パスワードと、通信路暗号化のための暗号鍵は別物。
暗号可された通信路経由でパスワードを送る。

2. 通信路の暗号可に使うのは、固定鍵暗号（共通鍵暗号）方式。
だって、公開鍵暗号は計算のコストが高くて遅いから。

3. 固定暗号鍵は毎回変わる。
同じ固定鍵を使っていると、そのうち(類推/力尽くで解読)される可能性がある
また、固定暗号鍵は第三者に見られちゃイヤン。

4. てことで、両者の間で同じ固定暗号鍵を共有するために、
　a)鍵交換のテクニックを使う (ElGamal だっけ?)
　b)公開鍵暗号方式を使って、固定暗号鍵について同意を形成するための
　　暗号可れた通信路を作る。
のどっちかを使う。
# ワンタイムパスワードは、a) だと思った。もっと詳しい人説明キボソ。

大筋あってると思うけれど。

21 ：>14 ：2000/12/12(火) 13:19

まぁ大体あってるけど、OTP と a) との話はまったく別だけど。
あと鍵交換アルゴリズムは Diffie-Hellman だ。

22 ：2 ：2000/12/12(火) 13:27

ありがとうございます。
> 1. (loginするときの)パスワードと、通信路暗号化のための暗号鍵は別物。
はい、これはわかってます。

> 暗号可された通信路経由でパスワードを送る。
この通信路を *公開鍵無しで*（authorized_keys が無い状態で）なおかつ
*認証が完了する前に*（クライアントを信用できない状態で） どう確立するか？
がわかってません。あ、サーバの host public key で暗号化するんですか？

> 2. 通信路の暗号可に使うのは、固定鍵暗号（共通鍵暗号）方式。
> だって、公開鍵暗号は計算のコストが高くて遅いから。
これもわかってます。

> 3. 固定暗号鍵は毎回変わる。
> 同じ固定鍵を使っていると、そのうち(類推/力尽くで解読)される可能性がある
> また、固定暗号鍵は第三者に見られちゃイヤン。
はい、これもわかってます。

> 4. てことで、両者の間で同じ固定暗号鍵を共有するために、
>　a)鍵交換のテクニックを使う (ElGamal だっけ?)
これがわかってないのかな？？

>　b)公開鍵暗号方式を使って、固定暗号鍵について同意を形成するための
>　　暗号可れた通信路を作る。
はい。

>>19
すみません。以前から悩んでたのでそれは穴が開くほと読みました。

23 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 16:25

ちがわねえか？
公開鍵暗号ってのは確かに秘密鍵をばらさずにすむから便利だけど、
ある公開鍵がなりすました他人のものではないという保証が難しい。

そこで、鍵交換がでてくるわけだ。といっても、鍵交換自体が公開鍵
暗号の焼き直しみたいなものだが。ElGamalは公開鍵運号系の一つだし、
鍵交換の方法でもあるわけだ。

結局このへんをつきつめると、ゼロ知識証明にたどりつく。ここから
先はちょっとばっかし算数（つーか論理的思考）が必要よ。

24 ：asm ：2000/12/12(火) 19:34

俺も ssh のソースを読んだわけじゃないから偉そうなことは言えないのだが
>>20 に書いてることがおおむね正しいんじゃないか?

俺は ssh のプロトコルを次のように認識している。

1) まず client はあらかじめ何らかの方法で server のRSA(DSA)公開鍵を
　　手に入れ、それを known_hosts(known_hosts2) に書いておく。

2) sshの接続の始めに server は自分のRSA(DSA)公開鍵を client に通知し、
　　client はそれを known_hosts(known_hosts2) の内容と比較する。

3) これで、client は server が別のホストのなりすましでないと確認でき、
　　また client -> server の片方向の暗号化通信路が確立できる。

4) 次に、このあとの通信に使うための共通鍵暗号の鍵を交換する。
　　ssh1 では client が 256 bit のランダムな数を選び、3)の
　　片方向暗号化通信路で送る。
　　ssh2 では Diffie-Hellman アルゴリズムで共通鍵の交換を行う。
# 正確には、ssh1 ではより安全に鍵交換を行うため server は 2)で
# 1時間毎に再生成されるもう一つのRSA公開鍵も client に送っている。
# 区別のため、この鍵をサーバ鍵、1)の鍵をホスト鍵と呼ぶ。

5) これで client <-> server 間の双方向暗号化通信路が確立される。
　　以降、*Authentication の設定に基づいて client の認証が行われる。

この手順だと PasswordAuthentication でも素の password は
暗号化通信路の中でしかやりとりされないから、かなり安全だと思う。
でも、例え暗号化されていても password は送りたくないってのなら
RSAAuthentication を使えばいいわけで。

25 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 22:09

Windowsで使える、日本語の通るまともなsshクライアントないっすか？
ttsshはいまいちバギーだし、RSAで動いてくんないし。

26 ：名無しさん＠お腹いっぱい。 ：2000/12/12(火) 22:46

ホスト間認証って challenge/response じゃないの?
しろうと質問ですまん。

27 ：名無しさん＠お腹いっぱい。 ：2000/12/13(水) 00:15

>>25
今、RSA Authで使ってるぞ。

28 ：20 ：2000/12/13(水) 00:37

>>24
詳細説明感謝
ソースが読めない厨房なので感謝

概要把握したつもりでも説明するとやっぱダメだわ

OTP云々濡ところは大誤り

29 ：名無しさん＠お腹いっぱい。 ：2000/12/13(水) 03:39

>>25
ttssh.exe使わずにTERATERM_EXTENSIONS=1設定してttermpro.exeから
起動した方がいい。ttssh.exeからの起動はなんか変な事が多かった。

30 ：名無しさん＠お腹いっぱい。 ：2000/12/13(水) 20:49

OpenSSH の Anonymous CVS Snapshot が用意された
http://bass.directhit.com/openssh_snap/

31 ：asm ：2000/12/14(木) 01:37

>>26
公開鍵暗号を使った認証も challenge/response 型認証の
一つと言えるでしょう。
普通の一方向性関数を用いた場合との違いは、認証を受ける側だけが
秘密の情報を知っていればよいという点です。

ssh1 の場合は challenge に対する response を返さずにそのまま
共通鍵暗号の鍵にしているようですが。
# つまり、本物の server だけが共通鍵を手に入れられることを認証として
# 使っている。

ssh2 では Diffie-Hellman アルゴリズムでの鍵交換の前に
ホスト認証を行ってるはずですが、man の内容しか読んでないので
具体的にどのような方法で認証を行っているかはわかりません。
# やっぱりsource読むしかない?

32 ：anonymousさん ：2000/12/18(月) 14:46

SolarisにSSH2.3.0を入れたのだが -f を付けて実行するとマシンごとハングしてしまう。
(2.1.0pl2でも同様。ただしSSH1では大丈夫)
どうすりゃいいんでしょうか？
あと、こういうのはどのMLで聞けばいいの？
ちなみに
% uname -a
SunOS ***.***.***.jp 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-1
こういうシステム。

33 ：名無しさん＠お腹いっぱい。 ：2000/12/18(月) 19:32

ssh は仕組みが結構知られてるようで厳密なこと知ってる人って実は少な
いよなー、RFC あるんだっけ？　I-D だけかな。このスレで輪読しません
か。あるいはどなたか解説しませんか。

34 ：名無しさん＠お腹いっぱい。 ：2000/12/18(月) 20:20

こんな記事が届いたよ。
http://securityportal.com/cover/coverstory20001218.html

35 ：名無しさん＠お腹いっぱい。 ：2000/12/18(月) 20:49

>>33
RFCその他に記載なし

36 ：名無しさん＠お腹いっぱい。 ：2000/12/18(月) 20:58

http://www.ssh.fi/drafts/

37 ：anonymousさん ：2000/12/18(月) 21:08

>>36
それちと古い。
http://www.ietf.org/html.charters/secsh-charter.html

38 ：名無しさん＠お腹いっぱい。 ：2000/12/18(月) 21:21

http://www.openssh.com/manual.html

39 ：名無しさん＠お腹いっぱい。 ：2000/12/19(火) 19:42

ssh1とsslが最近簡単にのっとられるように
なっちゃったじゃない。みんなssh2に逝こう

40 ：asm ：2000/12/21(木) 17:08

>>39
たぶん>>34のリンク先のことを言ってるんだろうが、
ちょっと誤解を招きかねない言い方だな。

>>24で書いたようにsshではサーバーが送ってくる公開鍵と
known_hosts に書いてある公開鍵が一致するか確認することで
なりすましを防いでいるわけで、逆に言えば known_hosts に
接続先の公開鍵がない状態では簡単になりすましの餌食となってしまう。
これがsshの最大の弱点であり、ssh1でもssh2でも同じ。
ssh2が安全なのではなく、まだdsniffがssh2に対応してないだけであり、
原理的にはssh2もハイジャック可能だ。

でも、known_hosts の内容さえしっかり管理しておけば
ssh1でもまだ十分安全なはず。
結局、どんなツールも利点・欠点をちゃんと理解して使うべしってことだな。

41 ：名無しさん＠お腹いっぱい。 ：2000/12/21(木) 17:25

結局、ある人のためにあたらしくアカウント作ってあげるときは
「おまえの identity.pub よこせ」と言って
そのユーザの ~/.ssh/authorized_keys に置いたうえで、
当該ホストの ssh_host_key.pub を「おまえの known_hosts に
追加しろ」といって送りかえせばいいのね。

42 ：???????????????B ：2000/12/21(木) 18:04

>>41
>「おまえの identity.pub よこせ」

とは言われたけど、送ったらそれだけでログインできたよ。
でも /etc/passwd の crypt 認証 (て言うのか?)
だったけど。もしかしたら最初から RSA 認証させるには

>「おまえの known_hosts に 追加しろ」

が必要なのかもしれない。

43 ：41 ：2000/12/21(木) 21:08

いやオレが言いたかったのはそういうことじゃなくって…
パスワード打ったってことは、きちんと RSA 認証できてないってことだ (サーバの設定かもしれんが、それも妙な話だ)。
known_hosts はなりすましを防ぐためにあるってことだよ。

44 ：名無しさん＠お腹いっぱい。 ：2000/12/21(木) 21:22

known_hostsには勝手に追加される。なりすまし防止の観点からは、
手動の方がいいけどな。
秘密鍵にパスフレーズを設定しておいたら、それをうちこまなきゃ
いけないので、一概にはいえない。

一番いいのは ssh -v で、ごちゃごちゃでてくるのを読む。
RSAAuth Failed とかなんとかってでてれば失敗してる。

45 ：名無しさん＠お腹いっぱい。 ：2000/12/21(木) 21:29

>44 んでも、秘密鍵のパスフレーズって /etc/passwd の
パスワードとは別モンだろう。42の状況は、PasswordAuthentication
になっちゃってるんじゃないかということよ。

46 ：名無しさん＠お腹いっぱい。 ：2000/12/26(火) 01:17

age

47 ：名無しさん＠お腹いっぱい。 ：2001/01/04(木) 23:07

気がついたら21世紀age

read.cgi ver5.26+ (01/10/21-)