ssh

■掲示板に戻る■ 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50

レス数が1000を超えています。残念ながら全部は表示しません。

ssh

1 ：エニグマ ：2000/12/11(月) 10:10: についての情報交換。
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
48 ：42 ：2001/01/05(金) 00:32: >>42
>>「おまえの identity.pub よこせ」
> とは言われたけど、送ったらそれだけでログインできたよ。
ごめん。大嘘。identity.pub よこすか、/etc/master.passwd にある
crypted passwd よこせ、って言われたんだった。で、当時は何の
こっちゃかわからず、後者を選択したの。
49 ：sendmail.org ：2001/01/12(金) 13:54: http://openssh.org
50 ：名無しさん＠お腹いっぱい。 ：2001/01/12(金) 13:56: http://openssh.com
51 ：名無しさん＠お腹いっぱい。 ：2001/01/14(日) 15:43: >>48
普通､identity.pub渡すだろ。
52 ：42 ：2001/01/14(日) 17:02: >>51
だから当時は ssh のことを全くわかってなかったんだってば。
53 ：名無しさん＠お腹いっぱい。 ：2001/01/14(日) 18:16: >>52
そういう事ね。
54 ：名無しさん＠お腹いっぱい。 ：2001/01/21(日) 10:05: age
55 ：名無しさん＠お腹いっぱい。 ：2001/01/22(月) 11:41: ふん。
所詮、公開鍵暗号なんて量子コンピュータができるまでの命。
56 ：名無しさん＠お腹いっぱい。 ：2001/01/22(月) 11:55: >>55
ネタにしても面白くなさすぎ。
57 ：名無しさん＠お腹いっぱい。 ：2001/01/22(月) 12:54: ゼロ知識証明ってどういう概念? 本は難しすぎてわからんし、
検索エンジンでもあまりいい説明がなかった。
公開鍵暗号系で鍵交換をすることはゼロ知識証明に入る?
58 ：名無しさん＠お腹いっぱい。 ：2001/01/22(月) 13:33: 培風館「暗号と認証」に平易な説明が載ってるよ

英語で良ければ「Applied Cryptography」の 102-104 ページくらいがいい

つーか数学板で訊けば教えてくれる人いるのでは？
59 ：名無しさん＠お腹いっぱい。 ：2001/01/23(火) 03:02: >>55 >>56
でも、本当だよな・・・
やっぱり機密情報は暗号化しようとしまいと
ネットワークに流さない方がいいのかな?
60 ：名無しさん＠お腹いっぱい。 ：2001/01/23(火) 03:19: 我々がどんな機密を持っているのいうのだ。
61 ：名無しさん＠お腹いっぱい。 ：2001/01/23(火) 16:26: 18禁エロゲーとロリ画像
62 ：まつらー ：2001/01/23(火) 16:34: >>59
ssh と関係ないけど企業秘密と言えば、NEC がイヤン♪な
メールフィルタアプリを発表（売？）したとか。
（Linux アプリだけど。）
http://www.necsoft.co.jp/soft/mailguardian/

N.G. ワードや、添付ファイルをチェックするみたい。
暗号化されてるのは、どーするんだろ？

給料泥棒してる我が身にとっては、嫌なシステムねぇ。(笑)
63 ：まつらー ：2001/01/23(火) 16:34: 更に関係ないが、Web ページのソースを見たら、Kondara で作ってた。
<meta name="GENERATOR" content="Mozilla/4.7 [Kondara-ja]
(X11; I; Linux 2.2.14-0.8k1 i586) [Netscape]">
ふーん。。。
64 ：名無しさん＠お腹いっぱい。 ：2001/02/14(水) 18:00: なんだか今更になって、SSH の元作者 (いまは SSH Communication Security の社長) が OpenSSH チームに「SSH という名前はうちのトレードマークだ、名前変えろ」っていってるみたいよ。
65 ：名無しさん＠お腹いっぱい。 ：2001/02/14(水) 18:52: じゃ変えよう。シェルでも無い奴に sh 付いてて欝だったところだ。
66 ：名無しさん＠お腹いっぱい。 ：2001/02/14(水) 21:52: >>64
最近の流行ですな。そういうの。
67 ：名無しさん＠お腹いっぱい。 ：2001/02/14(水) 23:02: >>65
rsh (remoteの方ね) はどうする？
68 ：65 ：2001/02/15(木) 00:45: >>67
一緒にあぼーんじゃ、と思ったが
その存在忘れてた自分が欝なんで逝ってくるよ。
69 ：名無しさん＠お腹いっぱい。 ：2001/02/15(木) 05:19: ssh-1.2.31age

また入れ替えっかよー... (ﾌﾞﾂｸｻ
70 ：名無しさん＠お腹いっぱい。 ：2001/02/15(木) 15:32: ssh 1.2.31 もやばいよ。
SSH1 を使うなら OpenSSH 2.3.0p1 でどうぞ。
71 ：名無しさん＠お腹いっぱい。 ：2001/02/15(木) 21:05: >>64
ネタ元きぼん。
72 ：64 ：2001/02/15(木) 21:34: >>71
See the openssh-unix-dev ml archive:
http://marc.theaimsgroup.com/?t=98211717600006&w=2&r=1
73 ：名無しさん＠お腹いっぱい。 ：2001/02/15(木) 23:29: 最近のＳＳＨデーモン(1.2.x)は全部root取られちゃうよ～
http://www.securityfocus.com/
74 ：71 ：2001/02/15(木) 23:41: >>72
thanks!
75 ：名無しさん＠Ｅｍａｃｓ ：2001/02/16(金) 02:34: opensshはroot権限だけじゃなく、名前まで取られそう(W
76 ：名無しさん＠お腹いっぱい。 ：2001/02/16(金) 19:45: TTSSH 1.5.3 age
77 ：名無しさん＠お腹いっぱい。 ：2001/02/16(金) 21:49: FreSSH-0.8.1 age (よーわからんが)
http://www.fressh.org/
78 ：ロッソ ：2001/02/16(金) 22:55: 　〃
（中」中）ノ　へぇ、FreSSH おもしろそうだね～
79 ：名無しさん＠お腹いっぱい。 ：2001/02/18(日) 05:08: OpenSSH 2.5.0 age
80 ：名無しさん＠お腹いっぱい。 ：2001/02/18(日) 06:02: PortForwarderを使って普通のTelnetクライアントで
sshを使いたいのですが、この場合パスワード認証なしに
接続することは可能でしょうか？
現在はssh経由でTelnetdにパスワード認証で接続しています。
（暗号化されたパスワードが流れている状態です）
81 ：名無しさん＠お腹いっぱい。 ：2001/02/18(日) 11:42: 23を潰して、RSAかDSAでしかログインできないように設定して
ユーザのパスワードを空にすればお望みどおりでは？
82 ：名無しさん＠お腹いっぱい。 ：2001/02/19(月) 15:01: 早くこいこい2.5.0p1
83 ：80 ：2001/02/19(月) 22:25: レスありがとうございます。やっぱりそれしかないですかねー。
空パスワードはちょっとまずいんです。
ところで、ssh経由でTelnetdにパスワード認証で接続という
使い方で実際に外部から会社のマシンなどに
アクセスするのはセキュリティ的にどうなんでしょう？
Telnetdは走ってますが、ポート23はFWで閉じてます。
暗号化されているとはいえ、パスワードが流れるというのが
ちょっと不安かも？と思うんですが・・・
84 ：名無しさん＠お腹いっぱい。 ：2001/02/19(月) 22:50: 2.5.0p1 は飛び越したようですね。
2.5.1p1 あげ。
ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/
85 ：ロッソ ：2001/02/19(月) 23:06: 　〃
（π」π）ノ　早速 make & install だーっ！
86 ：名無しさん＠ちょっとへこんでる ：2001/02/20(火) 01:33: >>83=80
パスワード認証なし、の場合は別にして、パスワードが流れるのを嫌う
のでしたら、ssh 上で opie や s/key を使うのはどうでしょう

# 使ったことはないんですが、可能かと思われます... 間違ってます？
87 ：名無しさん＠お腹いっぱい。 ：2001/02/22(木) 19:59: TTSSH 1.5.4 age
88 ：>>87 ：2001/02/23(金) 06:06: なんで What's New が更新されてないんだろ？
89 ：某所の管理者 ：2001/02/27(火) 22:38: うちの学生が、ssh のパスフレーズは空でもOK
だよという余計な事を広めてしまったので、空の
パスフレーズを付ける人が増えてしまいました。
こともあろうに教官までが。

で、各ユーザの秘密鍵にパスフレーズが設定され
ているか確認する簡単な方法はありませんか?
ファイル
~/.ssh/identity
のパスフレーズです。
90 ：名無しさん＠お腹いっぱい。 ：2001/02/27(火) 22:42: (echo;echo;echo)|ssh-keygen -p -f $HOME/.ssh/identity
とやって、終了コードが 0 ならそいつのパスフレーズは空。
どうでしょ?
91 ：某所の管理者 ：2001/02/27(火) 23:11: >>90
Thank you!
うまくいきそうです。ありがとうございました。
92 ：名無しさん＠お腹いっぱい。 ：2001/02/27(火) 23:52: >>88
不気味ですね。
ソースもないね。
93 ：名無しさん＠お腹いっぱい。 ：2001/02/28(水) 00:42: 「SSH」はオープンソースにあらず？
http://www.zdnet.co.jp/news/0102/27/e_ssh.html

見習うに値しないオープンソース事業モデル――SSHをめぐる論争
http://www.zdnet.co.jp/news/0102/27/e_leibovitch.html

OpenSSH開発プロジェクトから学ぶ教訓
http://www.zdnet.co.jp/news/0007/13/somogyi.html
94 ：名無しさん＠お腹いっぱい。 ：2001/02/28(水) 03:31: >>92
同じところにソースあるよ。ttssh154.zip
95 ：94 ：2001/02/28(水) 06:14: う、間違えた。ttssh154src.zip
96 ：名無しさん＠お腹いっぱい。 ：2001/02/28(水) 23:57: 何でリンク張らないんだろ　> ttssh154src.zip
97 ：名無しさん ：2001/03/01(木) 00:34: 単に忘れたんでしょ
98 ：名無しさん＠お腹いっぱい。 ：2001/03/02(金) 04:26: OpenSSH 1.5.1p2 age
99 ：名無しさん＠お腹いっぱい。 ：2001/03/02(金) 04:26: 2.5.1p2 だ。鬱。
100 ：名無しさん＠お腹いっぱい。 ：2001/03/16(金) 21:38: ssh2とopen sshのコンパチ問題はどうにかならんのかage
101 ：名無しさん＠お腹いっぱい。 ：2001/03/16(金) 22:17: コンパチ問題って?
102 ：名無しさん＠お腹いっぱい。 ：2001/03/17(土) 00:01: OpenSSHデーモンうごかしてるサーバーに
ssh2では入れないでしょ?

[nanasi@2ch]~% ssh host.somewhere.com
warning: Authentication failed.
Disconnected; MAC error (Message authentication check fails.).

[nanasi@2ch]~% ssh1 host.somewhere.com
Last login: Fri Mar 16 11:50:43 2001 from 2ch
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.

Welcome to 2ch...

う、こういうの書くの緊張するなあ。個人・ホストを特定できる情報は
変更してあります。

次100 最新50 (10:00PM - 03:00AM の間一気に全部は読めません)

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