SSH その4

**名無しさん＠お腹いっぱい。** · NG

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

過去ログ
　Part1：http://pc.2ch.net/unix/kako/976/976497035.html
　Part2：http://pc.2ch.net/test/read.cgi/unix/1028157825/ (dat落ち)
　　春山さんのとこ→ http://www.unixuser.org/%7Eharuyama/security/openssh/dat/pc.2ch.net_80__unix_dat_1028157825.html
　Part3：http://pc5.2ch.net/test/read.cgi/unix/1058202104/

**（ ﾟдﾟ）ﾎﾟｶｰﾝ** · 2005/04/15(金) 18:32:37

From: [180] 名無しさん＠お腹いっぱい。 <sage>
Date: 2005/04/15(金) 18:23:10

# vi /etc/ssh/ssh_config
に、デフォルトで
PasswordAuthentication no
PermitEmptyPasswords no
RhostsRSAAuthentication no
X11Forwarding no
Subsystem sftp /usr/libexec/openssh/sftp-server
これらの記述があったと思うんだけど
なぜかほとんどない・・・再インストール後ってこんなもの？
_______________________________________________________________

**名無しさん＠お腹いっぱい。** · 2005/04/15(金) 18:40:10

/etc/ssh/sshd_config

だったのか・・・orz

**初期不良** · 2005/04/15(金) 19:10:41

>>182
たいしたことじゃない気に病むな
イキロ

**名無しさん＠お腹いっぱい。** · 2005/04/15(金) 19:30:49

ま、そんなもんだ。

**名無しさん＠お腹いっぱい。** · 2005/04/15(金) 21:34:02

人間だもの
生きてるだけで恥さらし

みつを

**名無しさん＠お腹いっぱい。** · 2005/04/16(土) 21:30:20

うちの会社のリモート認証が
1. IDカードに表示されている数字列(時間で変わる)を見る
2. その数字列をあるプログラムに食わせると、ワンタイムパスワードが生成される。
3. sshでそのパスワードを使ってログインする。
というものなんですが、2.から3.へコピペするのが面倒なんで、自動化
したいんです(ちなみにそれだけなら構わないと会社に言われています)
ssh-agentとssh-add使ってスクリプトでなんとかなるかと思いましたが、
パスワードには対応してないみたいですね。SSH_ASKPASSも無視されるし。
(OpenSSH 3.9p1です)

で、sshはパスワードをどうも標準入力ではなく、/dev/ttyからしか
取ってくれないみたいなんで困っています。
なんかいい方法はないでしょうか。ファイルに書き出すとか、psで
見えてしまうのはまずいです。一時的にシェル変数に格納される
くらいならいいですけど。

**名無しさん＠お腹いっぱい。** · 2005/04/17(日) 00:48:27

>>186
つ openpty(3)

**名無しさん＠お腹いっぱい。** · 2005/04/17(日) 02:02:30

>>187
ありがとうございます。でもド素人には荷が重いアドバイスかも。

openptyしてforkして制御端末化してからsshをexec。
親はバッファリングを止めて子の出力を見てパスワード要求が来たら
パスワード送ってそのあとは入出力をそのままスルーで流すって
感じですか?

...ちょっとシェルスクリプトレベルを超えてる気がしますが、やってみます。

**名無しさん＠お腹いっぱい。** · 2005/04/17(日) 08:47:32

expect

**名無しさん＠お腹いっぱい。** · 2005/04/17(日) 09:09:03

sshのソースコードを修正して内部でその秘密のプログラムを呼ぶ方が早いのでは?

**名無しさん＠お腹いっぱい。** · 2005/04/17(日) 10:44:38

>>189
ありがとうございます。結局ptyをperlから扱えるモジュールを探したら、
IO::PtyとExpect.pmにたどり着きました。TCLは知らないのでEXPECT(1)を
覚えるよりPerl使ったほうが早そうです。
サンプルの2.B.rloginってやつがほとんどそのまま使えそう。

>>190
そんな気はしますが、あんまり触りたくないんですよね。

結局スレ違いになっちゃって、すみません。

**名無しさん＠お腹いっぱい。** · 2005/04/19(火) 23:00:45

OpenSSH-4.0p1をソースからビルドしようとしてるんですが、
configureで最近のlibcryptoが無いって怒られます。
で、see config.logとも出るので、見てみるんですが、いまいちわかりません。
config.logは長いので、ここには貼り付けられません。
環境は玄箱HG　debian sargeです。現在3.8.1.p1が入ってます。（OpenSSL-0.9.7e Zlib-1.2.2）
ちなみに、LD＿LIBRARY＿PATHやPATHは通してあります。
何ぞヒントになるポインタだけでも与えていただけないでしょうか？宜しくお願いします。

**名無しさん＠お腹いっぱい。** · 2005/04/19(火) 23:20:50

>>192
> configureで最近のlibcryptoが無いって怒られます。
> ちなみに、LD＿LIBRARY＿PATHやPATHは通してあります。
下手な要約や翻訳をせずに、やった操作とエラー出力をそのまんまコピペしる。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 02:18:36

~/.ssh/identity.pubを安全な方法で持って行くように書いてある
ページをたまに見かけるんだけど、なぜ安全な方法で持って
いかなければならいのか、わかりません。

公開鍵から秘密鍵とか計算できるの？

◆uGRdPa4j32 · 2005/04/20(水) 02:54:28

>>194
嘘を嘘であると見抜ける(ry

**春山征吾** ◆unIxUSernc · 2005/04/20(水) 12:09:02

>>194
ユーザの公開鍵が他者に知られると、
他者が偽ホストを作ってそこにログインさせようとする攻撃に対する防御が弱くなります。

ホストの認証が適切に行われれば防げますが、
SSHのホストの認証は相手のホスト公開鍵を入手しておかないと機能しません。
たとえば、先方のホストの入れ換えがあって、ホスト公開鍵が変わったことはわかっているが
ホスト公開鍵そのものは知らないという状況では、
新しく提示されたホスト公開鍵を信用してしまいがちです。

ユーザの公開鍵が真に安全に渡され管理されていれば、
ホストの認証がごまかされてもユーザの認証の段階で不審なことに気づきやすいでしょう。
(公開鍵を登録してもらったはずなのにパスワードのプロンプトがでるな? とか)

なのでユーザの公開鍵も*可能ならば*安全な方法で渡したほうがよいと思います。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 12:17:30

>>196
理由とするにはかなり無理矢理な感じのする屁理屈だなあ。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 13:18:45

>>197
セキュリティホールとその対策なんてそんなもんよ
半分はブービートラップ半分は屁理屈

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 13:37:10

事故にあう確率が違うのでできれば車より徒歩で移動した方がいいと思いますみたいな。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 13:44:48

>>198
わかってない人とかエセコン猿だとそうかもね。

>>199
知らないおじさんについていかないよう、人見知りする子に育てた方がいいと思いますみたいな。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 17:10:22

>>196の例えは不適切。ホスト名乗っ取る際に、クライアントの公開鍵はすべて無条件に
受け入れるようにしておけば疑う余地はないし、最初の1回でその公開鍵を入手できる。

**春山征吾** ◆unIxUSernc · 2005/04/20(水) 17:38:56

>>201
認証の際にユーザの公開鍵を送るので、そうされたらダメですね。

196は撤回します。お騒がせして失礼しました。

**春山征吾** ◆unIxUSernc · 2005/04/20(水) 17:44:26

仕切り直して、
安全でない手段でユーザの公開鍵を送ると、
途中で他者に公開鍵をすりかえられて、
サーバへの登録後正規のユーザが確認するより先に他者にログインされる
という攻撃はあると思われます。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 17:52:55

それ考えたけど、すりかえができるような状況なら
わざわざすりかえなくともいきなり偽の公開鍵送りつけても
サーバに登録してもらえそうな気がした。
「あー、おれおれ。この鍵入れといて」って。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 19:32:01

「公開」鍵だぞ？
公開して問題ない鍵なのに、安全な方法で送る必要ねぇだろ、アホか。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 19:36:30

>>205
なら >>203 に反論してよ。

**192** · 2005/04/20(水) 21:34:31

>193
apt-get installでsshをインストール。
バージョンが3.8.1p1だったので、openssh-4.0p1.tar.gzを取得して/home/userでtarコマンドで展開
openssh-4.0p1ディレクトリの中でmkdir build && cd buildして　../configureを実行。
3分弱くらいで
configure: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) ***
となりました。
以上です。宜しくお願いします。
もう一度環境ですが、玄箱HG debian sarge 　gccバージョン3.3.5です。

**名無しさん＠お腹いっぱい。** · 2005/04/20(水) 22:00:49

>>203
chrootまたはjailなどの隔離環境でクライアントに接続試験させてから本格的に
ホームディレクトリで運用させれば良いんじゃないの。
そこまでする必要にせまられったことは今まであったこと無かったが。

**春山征吾** ◆unIxUSernc · 2005/04/20(水) 22:22:26

>>208
それも安全な方法のひとつじゃないですかね。

**春山征吾** ◆unIxUSernc · 2005/04/20(水) 22:36:18

この話は、

管理者が、
・正規ユーザと確認してから登録する
なり
・(鍵自体の確認手段がないなら)正規ユーザがログインできるかどうかすぐに確認してもらえる状況で登録する
などといったポリシーに基づいて鍵の登録を行う

とユーザの側からでなく管理者の側からとらえたほうがいいのかな。

**名無しさん＠お腹いっぱい。** · 2005/04/21(木) 01:18:03

>>210
違う。
>>194は「持っていく」と書いているので、その気になれば安全な
方法で持っていって自分で登録できる人、と読める。
自分で登録できるなら登録後のverifyも可能なので、途中経路での
すり替えは気にする必要ない。当然公開鍵は盗み見られてもかまわない。
ってことで、>>194はただの杞憂。

もし、「持っていく」ではなく「ログインしたいサーバの管理者に渡す」
という話なら、>>210となる。

**名無しさん＠お腹いっぱい。** · 2005/04/21(木) 01:25:26

・公開鍵は安全で無い経路で伝達
・フィンガープリントは安全な経路で伝達

こうじゃないの？

**春山征吾** ◆unIxUSernc · 2005/04/21(木) 02:19:35

>>210
・正規ユーザと確認してから登録する -> ・正規ユーザの鍵と確認してから登録する
です。

>>212
それも管理者が確認できる方法のひとつです。

**名無しさん＠お腹いっぱい。** · NG

http://www.unixuser.org/%7Eharuyama/security/openssh/20050421.html

すばやいね。

**名無しさん＠お腹いっぱい。** · NG

http://triaez.kaisei.org/~kaoru/diary/?200305a#200305045
GlobalKnownHostsFile as read only known_hosts

http://www.nantoka.com/~kei/diary/?200504b&to=200504181#200504181
「REMOTE HOST IDENTIFICATION HAS CHANGED」が出たら、~/.ssh/known_hostsを消せ

**名無しさん＠お腹いっぱい。** · 2005/04/21(木) 16:05:30

>>2を読んで厨質問しそうになっていた自分を戒めたｗ

**名無しさん＠お腹いっぱい。** · 2005/04/22(金) 23:15:39

ポートフォワードで質問なのですが
1000番から2000番までのポートを対象のサーバへ
それぞれフォワードさせたいのですが可能でしょうか。

コマンド的には以下のような感じです。

ssh 192.168.2.1 -L 1000-2000:192.168.1.1:1000-2000 -g

**194** · 2005/04/23(土) 00:25:30

ちょっと忙しくて見れてなかったが、レスくれた方々ありがとうございます。

てっきり、公開鍵と暗号化された通信内容から秘密鍵が割り出せて
通信内容がばれる可能性があるのかと思ってた。
(これは現実的な時間では計算できない？っぽい。)
全然違うことを心配していました。

気になったのですが>>202は、間違えてませんか?
認証の際にユーザの公開鍵を送ることはたぶん無いですよ。
http://www.unixuser.org/~euske/doc/openssh/jman/ssh.html
の「チャレンジ」周辺に書いてあります。

正解は、>>195

**春山征吾** ◆unIxUSernc · 2005/04/23(土) 10:16:34

>>218
SSH1のRSA認証では(チャレンジの前に)クライアントがユーザの公開鍵を送ります。
一致する公開鍵がサーバにあるとその鍵を使ったチャレンジをサーバが送ります。

SSH2の公開鍵認証でも、通常はまずクライアントはユーザの公開鍵を送り
サーバはその有無を返します。
クライアントがユーザの秘密鍵を用いた署名を送る際にもユーザの公開鍵をつけます。

**春山征吾** ◆unIxUSernc · 2005/04/23(土) 10:42:49

偽ホストとの通信でユーザ認証までいってしまえば、
クライアントからの情報を検証せずとも偽ホストは適当な返答を返して
ログインを許可できるので
その意味でも
>>196 は間抜けでした。

**194** · 2005/04/23(土) 19:08:52

>>219
やっと、公開鍵を送ってることが理解できた。サンクス

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 17:52:18

はじめまして。
ＳＳＨ初心者なのですが、ポートフォワードに関して教えていただけないでしょうか？
一つのサーバーにＳＳＨ、WebDav(Apache)サーバ、ＩＲＣサーバを動かしているのですが
ユーザー１とユーザー２がいるとして
・ユーザー１はポートフォワードでWebDavのサーバーにしか転送できない
・ユーザー２はＩＲＣのサーバーにしか転送できない

と言った設定をする事は可能でしょうか？つまりユーザー１がＩＲＣを利用したり、
ユーザー２がWebDavを利用したりできないように特定のポート番号だけをフォワードできるようにする設定にしたいのですが

厨質問ですみません、御教授下さい・・・

**無しさん＠お腹いっぱい。** · 2005/04/25(月) 20:51:20

>>222 OpenSSH だと、ホスト毎のforwarding設定はできるけど、
ユーザ毎設定をサーバでやるいうのは出来んように思う。

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 21:28:55

>>219
待て。クライアントは公開鍵なんぞ送らんぞ。
一度クライアント公開鍵を削除してからRSA認証でログインしてみれ。

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 21:44:49

やってみたが、
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
...送ってない？

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 21:44:57

>>222
permitopen

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 22:52:15

>>225
公開鍵を送ってんじゃなくて「公開鍵認証方式で認証してくれ」っていうリクエストを送ってる。
/home/user/.ssh/id_rsa ←これクライアント秘密鍵だし。

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 23:19:46

>>227
>>225を見て興味を持ったので俺もコードを見てみた。
どの公開鍵でなのかを伝えるために、公開鍵そのものを送ってるように思う。
(もちろんサーバはそれを無条件に使うわけではなくて、
ユーザのauthorized_keysに同じものがあれば使うんだろうけど)

sshconnect2.cのuserauth_pubkeyとsend_pubkey_test。

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 23:34:30

>>228
公開鍵（例えばSSHv2のRSAならid_rsa.pub）をクライアントから削除して、
秘密鍵だけ置いた状態でサーバにSSH接続を試してみて。
接続できるでしょ？
つまり公開鍵を送っているわけではないってこと。

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 23:52:18

「どの公開鍵でなのかを伝えるために公開鍵を送る」とあるけど、
ただしくは「どの公開鍵でなのかを伝えるために秘密鍵を使う」です。

動作の詳細は自分もはっきり説明できるわけじゃないんだけど（SSHv1と
SSHv2でも少々異なるようだし）、たとえばユーザＡとしてログインしようとしてるとして、
まずSSHクライアントが「この秘密鍵ログインしたい」とサーバに伝える。
んで、SSHサーバ側で、その秘密鍵に対応する公開鍵が
/home/ユーザＡ/.ssh/authorized_keysに登録されているかどうか見る。
で、登録されているクライアント公開鍵でランダムデータを暗号化してクライアントに送る。
クライアント側ではその暗号化データをクライント秘密鍵で複合化して送り返す。
クライアント側の秘密鍵で正しく複合化できたら、クライアント側の
秘密鍵とサーバ側にある公開鍵が正しいペアだと証明できるので、認証される。

ってな具合だと思う。（本当はもっと複雑なことやってるらしいが）

**名無しさん＠お腹いっぱい。** · 2005/04/25(月) 23:57:25

>>230
「秘密鍵を使う」というのが具体的にどういう使っているのか説明してくださいな。
できればコードに即しておねがい。

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:00:20

>>229
秘密鍵ファイルには公開鍵の情報も含まれているわけだが

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:03:15

>>229
前半は後半の根拠にならないですよ。ssh-keygenのmanを読んだことないですか?

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:08:11

>>230
> まずSSHクライアントが「この秘密鍵ログインしたい」とサーバに伝える。

どういう情報でそれが伝えるのかが問題になってるわけだが。
知識もなければ読解力もないな。

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:17:05

>>230 はもしかして秘密鍵を送ると思ってるんジャマイカ

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:19:47

>>233
具体的な説明よろ

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:21:27

>>236
ssh-keygenの-yオプション
つまりは>>232ってことだと思われ

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:22:04

>>234
どういう情報で伝えるかが問題ではなく「公開鍵自体を送っているのかどうか」が問題なのだが。

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:27:31

>>238
伝えるための情報として公開鍵そのものを送っているという話だと思うが。
>>228のその主張を否定してるわけだから、
公開鍵を送らないならどういう情報で同定してるのか教えてくれ。
それを送ってる部分のコードの特定も。

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:38:57

ssh がどうやっているかは知らないけど、署名の要領 (秘密鍵で暗号化→公開鍵で復号化) で確認はできるよ。

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 00:54:49

>>240 バカ一匹追加

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 02:35:25

そろそろ誰かちゃんとした回答をしてください

**名無しさん＠お腹いっぱい。** · 2005/04/26(火) 07:00:29

おまいらソース嫁

**名無しさん＠お腹いっぱい。** · 2005/04/29(金) 12:43:52

リモート1：Solaris9(SunのSSH?)
リモート2：MiracleLinux(OpenSSH)
自分：WinXP+cygwin

という環境で、リモートマシンのパスワードの有効期限が
切れた後にsshでリモートに接続すると、

リモート1：その場で新パスワードに更新させられる
リモート2：切断

となってしまいます。OpenSSHでも、パスワード期限切れ時に
新パスワードに変更させてログイン続行させることは可能
ですか?

**名無しさん＠お腹いっぱい。** · 2005/04/29(金) 12:47:33

公開鍵、秘密鍵って、マシン毎に作るもの？
それとも一人のユーザが一つずつもってりゃいい？

**名無しさん＠お腹いっぱい。** · 2005/04/29(金) 12:49:19

リスク分散を考えるとそれぞれで作ったほうがいい。
しかし面倒くさい。
自分で判断出来ない池沼は何やっても無駄。

**名無しさん＠お腹いっぱい。** · 2005/04/29(金) 14:18:40

秘密鍵一つ作れば公開鍵は無限に作れるよ

**名無しさん＠お腹いっぱい。** · 2005/04/29(金) 14:31:00

>>244
OpenSSHとLinuxの認証システムは別個のプログラムで
あまり密でないから、結構ハックしないとだめそう。

ユーザーとして不便てことだけなら、
パスワードじゃなくて鍵をつかえればいい。

**名無しさん＠お腹いっぱい。** · 2005/04/29(金) 15:49:13

pamの設定だけじゃないか?

**名無しさん＠お腹いっぱい。** · 2005/04/29(金) 16:57:04

いや、privilege separationのせいでちとやっかい。

**244** · 2005/04/29(金) 17:07:39

>>248 >>249 レスありがとうございます。
リモートサーバの設定は、「パスワード認証なし」で、
RSAの鍵認証のみで使用しています。pamの設定、
調べてみることにします。

会社の規則で、すべてのサーバにパスワードの有効期限を
設定する必要が生じたため、困っているのです。このままだと、
遠隔地にある普段メンテしないLinuxマシンが、肝心な時に
パスワード期限切れで現地に行かないとメンテできない状況に
なりかねません。

逆に、「OpenSSH(+pam?)ではできない」という裏が取れれば、
「これこれの理由で有効期限は定めない」という設定許可申請を
会社に出すつもりなのですが、その裏も取れずに困っています。

教えてクンですみませんが、なにか情報のソースがあれば、
ご教授お願いします。

**名無しさん＠お腹いっぱい。** · NG

普段からちゃんとメンテ汁

**244** · 2005/05/01(日) 00:01:42

>>252
「普段メンテしない」≠「メンテしてない」
「必要なとき以外にはアクセスしない」です。
あんまり同じ悩み抱えてる人はいないんでしょうか。
それとも、「(必要なくても)定期的にアクセスするが正解ですか?

**名無しさん＠お腹いっぱい。** · 2005/05/01(日) 00:11:09

その状況だとワンタイムパスワードを利用するのも手

**名無しさん＠お腹いっぱい。** · 2005/05/01(日) 02:03:53

SSHの公開鍵認証使ってるんでしょ?
むしろ普通のユーザのパスワードは潰しておくべきじゃないか。

**192** · 2005/05/07(土) 21:01:20

自己解決。
opensslを0.9.7eから0.9.7gにしたらconfigure通ってあとはすんなりでした。
良かった。

**名無しさん＠お腹いっぱい。** · 2005/05/09(月) 20:44:08

携帯からSSHでPCを遠隔操作できるシステム～ベータ版を無償公開
http://internet.watch.impress.co.jp/cda/news/2005/05/09/7515.html

**名無しさん＠お腹いっぱい。** · 2005/05/10(火) 00:21:39

SymbianOSなNOKIAの携帯なら、もっと前からフリーなSSH clientはあったけど
PuTTY SSH client for Symbian OS
ttp://s2putty.sourceforge.net/

…未踏なんですか。入力/補完モードが肝？…というほどの新規性があるとも…

**名無しさん＠お腹いっぱい。** · 2005/05/12(木) 17:36:08

ssh -X -M hoge command &を何回も実行すると、実行した数だけTCP/IPコネクションが
張られるんだけど、-Mオプションをつければコネクションを共有するんじゃないの？

**名無しさん＠お腹いっぱい。** · 2005/05/14(土) 18:36:15

Intelのハイパースレッディングに深刻な脆弱性

IntelのXeonなどに実装のハイパースレッディングに深刻な脆弱性が発見された。
マルチユーザーシステムの管理者は直ちに使用を停止した方がいいとの勧告が出されている。

Intelのプロセッサに実装されているハイパースレッディング技術に深刻な脆弱性が存在すると、
セキュリティ研究者が報告した。

この問題を発見したのは、FreeBSDプロジェクトでセキュリティを担当するコリン・パーシバル氏。
オタワで開催のBSDCan 2005で5月13日、詳しい論文を提出したという。

ハイパースレッディングはIntelのPentium Extreme Edition、Pentium 4、モバイルPentium 4、
Xeonに実装されている技術。同氏がサイトに掲載している情報によれば、この脆弱性が原因で
ローカル情報が流出する恐れがあり、権限を持たないユーザーがRSA非公開鍵を盗み出すことが
できてしまうという。

マルチユーザーシステムの管理者は直ちにハイパースレッディングを停止した方がいいと同氏は
強く勧告。デスクトップPCなどのシングルユーザーシステムは影響を受けないとしている。

パーシバル氏は昨年10月にこの問題を発見。その後コンセプト実証プログラムを作成し、影響を
受ける全ベンダーにこの問題を通報したという。サイトには、FreeBSDやSCOなどから寄せられた
アドバイザリー情報が掲載されているが、今のところIntelからの情報は寄せられていない。
http://www.itmedia.co.jp/enterprise/articles/0505/14/news009.html

**名無しさん＠お腹いっぱい。** · 2005/05/15(日) 03:46:52

openSSH4.0のsftp-serverってUTF-8未対応だっけ？
WinSCPでアクセスするも適切にエンコーディングできん

**名無しさん＠お腹いっぱい。** · 2005/05/20(金) 14:17:41

>>3
SSH Plugin
http://www.mud.de/se/jta/html/SSHTest.html(SSH1)

**名無しさん＠お腹いっぱい。** · 2005/05/21(土) 16:58:51

ftp://core.ring.gr.jp/pub/net/ssh/
のWindows用sshクライアントで公開鍵を使ってopensshを使っているLinuxサーバに接続する方法を教えてください。

ssh-keygen2でキーを作成し、.pubファイルを~/.sshにアップロードし

ssh-keygen -i -f kkk.pub > kkkk.pub
cat kkkk.pub >> authorized_keys

ここまでやったのですが、その先がわかりません。よろしくお願いします。

**名無しさん＠お腹いっぱい。** · 2005/05/21(土) 17:38:50

>>263
ssh hoge

**名無しさん＠お腹いっぱい。** · 2005/05/21(土) 17:47:01

つ入門SSH

**名無しさん＠お腹いっぱい。** · 2005/05/21(土) 20:13:11

>>263
つ PuTTY
ttp://hp.vector.co.jp/authors/VA024651/#PuTTYkj_top

**名無しさん＠お腹いっぱい。** · 2005/05/22(日) 06:21:48

ftp://core.ring.gr.jp/pub/net/ssh/
以外使えない環境なんです・・・

**名無しさん＠お腹いっぱい。** · 2005/05/22(日) 06:57:49

debug表示のオプション(-vとか-d)をつけてssh2.exeで接続してみれば、
なにがおかしいかわかるかもね。

**名無しさん＠お腹いっぱい。** · 2005/05/22(日) 17:09:53

「site:2ch.net」でググったらこのスレがトップにきますた

**名無しさん＠お腹いっぱい。** · 2005/05/23(月) 07:06:38

>269
本当だ。なんでやねん。

**名無しさん＠お腹いっぱい。** · 2005/05/23(月) 13:23:11

俺が試すとトップ10にも出てこないけど……。
ちなみにトップは大学受験サロン。

第2位は日本語限定かどうかで変わる。謎。

**名無しさん＠お腹いっぱい。** · 2005/05/23(月) 19:05:21

ウェブ全体からの検索
SSH その4
大学受験サロン＠2ch掲示板
全国鉄道混雑情報
【岡部の前に】岡部幸雄スレPart41【岡部無し】

日本語のページを検索
Vodafone質問スレッドPart73
McAfee Part.17
これを日本語化！な OS X アプリ発表会 Part 6
OS/2だよOS/2

**名無しさん＠お腹いっぱい。** · 2005/05/26(木) 20:42:01

http://www.unixuser.org/~haruyama/security/openssh/

4.1p1ｷﾀｷﾀｷﾀｷﾀ━━━(ﾟ∀ﾟ≡(ﾟ∀ﾟ≡ﾟ∀ﾟ)≡ﾟ∀ﾟ)━━━━!!
けど、ぁゃιぃ？

**名無しさん＠お腹いっぱい。** · 2005/05/26(木) 21:58:06

本家見たけど、んなもんないじゃん。

**名無しさん＠お腹いっぱい。** · 2005/05/26(木) 22:12:55

なんかオライリーから出るね

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 01:01:01

>>274
本家webサイトはまだ更新されていないみたいだけど、openssh-unix-announce
にはアナウンスメールが来てるよ。

ただし、最初に送られてきたアナウンスメールに記載されていた SHA1 checksum
は間違いだそうで。。>>273の言う
　> けど、ぁゃιぃ？
はそういうことだろう。正しい checksum は
　SHA1 (openssh-4.1.tar.gz) = 62fc9596b20244bb559d5fee3ff3ecc0dfd557cb
　SHA1 (openssh-4.1p1.tar.gz) = e85d389da8ad8290f5031b8f9972e2623c674e46
だそうだ。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 01:11:54

いつもの通り、春山さんが変更内容の日本語訳を出して下さってますねー（感謝！）
ttp://www.unixuser.org/~haruyama/security/openssh/henkouten/henkouten_4.1.txt

で、大したことではないかもしれないですが…、

(1) 「著しい修正としては以下がある.」→「大きな修正としては以下のものが
挙げられる.」
(2) 「を用いる場合に起きる segfault を修正した.」→「を用いる場合に
　segmentation fault が発生してしまうのを修正した.」

のように書き直すといいかなと思いました。

**276** · 2005/05/27(金) 01:41:32

>>274
> 本家見たけど、んなもんないじゃん。
って、本家 *FTPサーバ* のことか。確かにないですね。。チェックサム間違えた
とかで引っ込められたのかな？

アナウンスメールは確かに届いているんだけど...

**274** · 2005/05/27(金) 13:13:10

今はたしかにありんす。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 15:59:28

portable版のpgp signatureも合わない。。。

$ gpg --verify openssh-4.1p1.tar.gz.asc
gpg: Signature made Wed May 25 21:26:24 2005 JST using DSA key ID 86FF9C48
gpg: BAD signature from "Damien Miller (Personal Key) <djm@mindrot.org>"