ssh

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

についての情報交換。

259 ：名無しさん＠お腹いっぱい。 ：01/10/24 01:38

>>256
tcshでも
　% sleep 20 </dev/null >&/dev/null & exit
などとやればすぐログアウトするよ。
でもリモートでプログラム走らせるんならちゃんとデーモン化させとくか、
screen使ってdetachするほうがよいと思うよ。
ここにちゃんとスレもあるし: http://cocoa.2ch.net/test/read.cgi/unix/1001966406/

260 ：名無しさん＠お腹いっぱい。 ：01/10/24 02:19

>>259
うみゅ。ふつ〜 screen。tty から入力する必要がある process でも
なんの問題もないし。

261 ：256 ：01/10/24 03:07

>>259
> tcshでも
> 　% sleep 20 </dev/null >&/dev/null & exit
> などとやればすぐログアウトするよ。
うちではやはりこのコマンドでもプログラムが動いている間はログアウト出来ませんでした…

デーモン化、というのがよく分かっていないのですが、
http://www.linux.or.jp/JM/html/netkit/man3/daemon.3.html
この関数を使うっていうことでしょうか?
こちらも今試してみたのですが、やはり実行中ですとログアウトできませんでした(使い方間違ってる可能性も大いにありますが…)。

screenの方は、ちょっと今からマニュアルを読んでみます。
X上で作業する場合でも有用なんでしょうか?

262 ：名無しさん＠お腹いっぱい。 ：01/10/24 04:15

むぅ。Debian unstable に emacs21 がのっかったか。Solaris じゃなぜか
compile に失敗だ…。

>>261
screen は session の再開っていう鬼のように強い機能があるので、X 環境だろ
うだなんだろうが、非常に便利。

263 ：あまね ◆ANPANsaE ：01/10/25 01:14

何でも質問板にも書いたのですが、
sshのForwardｉｎｇ機能を使って
FTPを行いたいのですが、
FTPのデータ部分も暗号化したいのです。

現在、ＦＴＰクライアントで
データ用ポートにpasvでアクセスし、
LISTしようとしたところでエラーになってしまいます。

使用しているOSはTurboLinux
使用しているFTPはWu-FTP
クライアントOSはWindows98
クライアントFTPソフトはFFftpです。

264 ：あまね ◆ANPANsaE ：01/10/25 01:22

>>226-228でも書いてあるとおり、
pasvにしつつ、
/etc/ftpaccessに
port-allowとpasv-allowを
all　0.0.0.0で書き加えたんですけど…
（検証環境なので、セキュリティは無視しています）
あと、pasvで使えるポートの幅も指定しました
（もちろん1024以上で指定しました^^;）

いろんなサイトを見ましたが、どうしても解決しません。
うぐぅ、困り果てています。

265 ：名無しさん＠お腹いっぱい。 ：01/10/25 01:27

>>264
漏れは問題ないぞ。FreeBSD だけどな（ｗ

266 ：名無しさん＠お腹いっぱい。 ：01/10/25 01:28

>>264 ssh自体がftp proxyに相当する機能を内蔵しないかぎり、
port forwardingでftpは無理。

267 ：265 ：01/10/25 01:30

>>266
漏れはやってるってYO!

268 ：名無しさん＠お腹いっぱい。 ：01/10/25 01:38

>>267
dataは暗号化されてないYO!

269 ：名無しさん＠Ｅｍａｃｓ ：01/10/25 01:42

Passive FTP にしてクライアントをちょい修正すれば
いけるような気がするんだけど、どのみち面倒そう。
sftpかrsync使えってことだな。

270 ：265 ：01/10/25 01:43

>>268
え、そなの？逆向きは暗号化してくんないの？
知らん買った逝ってきます..... ... .

271 ：名無しさん＠ＸＥｍａｃｓ ：01/10/25 02:44

>>270
逆向きな経路は暗号化しない、というか出来ないはず。

ftp のコマンドとデータの通信経路が別だからね…。
家では使わないようにしてます。

272 ：名無しさん＠お腹いっぱい。 ：01/10/25 02:51

>>271
FTPって扱いにくいプロトコルだよねー。

273 ：あまね（ﾀﾞﾒ会社員） ◆ANPANsaE ：01/10/25 09:47

>>265-272
レスありがとうございます。
えっとですね、下記のサイトにFTPのDATA部分の暗号化について
触れてあるのですが、このとおりにやっているつもりなのですが
できないのです…

http://www.ez-net.ne.jp/special/server/no-class/ssh-forward.asp

クライアントによって出来たり、出来なかったりがあるみたいですね。

http://www.ez-net.ne.jp/dictionaries/checked/pasv-ssh.asp

上記のページで紹介されている SteedFTP は既にVerUPされていて
現行のものを使って試したのですがうまくいきませんでした。

274 ：名無しさん＠お腹いっぱい。 ：01/10/25 10:55

>>273
そのページ見てみた。たしかにそうやればできなかないが、そんなこと
するよりscpなりsftpなり使った方がいいよ。

275 ：あまね（ﾀﾞﾒ会社員） ◆ANPANsaE ：01/10/25 11:55

>>274
んー、そうですか。
どうしても代替できない状況での検証だったので…

出来ないことがわかったので、よかったです。

ｱﾘｶﾞﾄｳございました。

276 ：　 ：01/10/25 15:19

ｓｓｈのセキュリティーを破る方法をMITが発見した
そうですが、どうやれば破れるのですか？

277 ：名無しさん＠お腹いっぱい。 ：01/10/25 15:24

openssh の cvs 版の version.h を見ると、OpenSSH_3.0p1 ってなっていますな。

278 ：なんか出てる ：01/10/25 19:36

「CERT/CC Vulnerability Note VU#945216」
http://www.kb.cert.org/vuls/id/945216

とりあえず、プロトコルバージョン１を無効
にしておいた方がいいのかな。

OpenSSH の方は随分前に見つかっていたセキュ
リティホールに対する攻撃を検出するコード
自体に穴があったということでしょうか？

ちょっと気味の悪い記事も…
「Hackers Put A Price Tag On New Attack Tool」
http://www.infowar.com/hacker/01/hack_101901a_j.shtml

279 ：278 ：01/10/25 20:47

どうも早とちりだった。2 月に見つかってた
問題なんですね。

> リティホールに対する攻撃を検出するコード
> 自体に穴があったということでしょうか？

だからこれはウソだった。現在のバージョンで
はもう直ってますね。

280 ：SSH ：01/10/26 05:36

SSH

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