SSH その5 - 暇つぶし2ch

SSH その5 at UNIX

1:名無しさん＠お腹いっぱい。
06/04/20 07:09:00
SSHに関する情報交換のスレッドです。
FAQ、リンク集は >>2-5 あたり。

過去ログ
　Part1：URLﾘﾝｸ(pc.2ch.net)
　Part2：URLﾘﾝｸ(pc.2ch.net)
　Part3：URLﾘﾝｸ(pc5.2ch.net)
Part4：ｽﾚﾘﾝｸ(unix板)

2:名無しさん＠お腹いっぱい。
06/04/20 07:09:53
よくある質問

Q.公開鍵認証などは使用せず、パスワードによる認証を行う場合でも
　そのパスワードは暗号化されているのですか？
A.はい、その通りです。
　SSHプロトコルでは、まず始めにサーバ<->クライアント間で
　暗号化された通信路を確立します。
　ユーザ認証はその暗号化通信路の上で行なわれるので、
　パスワードなどもちゃんと秘匿されています。

Q.最近、root,test,admin,guest,userなどのユーザ名で
　ログインを試みる輩がいるのですが？
A.sshdにアタックするツールが出回っているようです。
　各サイトのポリシーに従って、適切な制限をかけましょう。
　参考：URLﾘﾝｸ(www.st.ryukoku.ac.jp)

3:名無しさん＠お腹いっぱい。
06/04/20 07:10:05
◇実装
本家ssh.com
　URLﾘﾝｸ(www.ssh.com) / URLﾘﾝｸ(www.jp.ssh.com) (日本語)
OpenSSH
　URLﾘﾝｸ(www.openssh.com) / URLﾘﾝｸ(www.openssh.com) (日本語)
　OpenSSH情報：URLﾘﾝｸ(www.unixuser.org)
　日本語マニュアル：URLﾘﾝｸ(www.unixuser.org)
　OpenSSH-HOWTO：URLﾘﾝｸ(www.momonga-linux.org)

TeraTerm/TTSSH
　URLﾘﾝｸ(hp.vector.co.jp)
　URLﾘﾝｸ(www.zip.com.au) / URLﾘﾝｸ(www.sakurachan.org) (日本語版)
　URLﾘﾝｸ(sleep.mat-yan.jp) (Yutaka氏によるUTF-8対応版,SSH2対応版)
PuTTY
　URLﾘﾝｸ(www.chiark.greenend.org.uk)
ｽﾚﾘﾝｸ(unix板)
　URLﾘﾝｸ(hp.vector.co.jp) (hdk氏による日本語パッチ)
　URLﾘﾝｸ(yebisuya.dip.jp) (蛭子屋氏による各種パッチ)
VeraTerm
　URLﾘﾝｸ(www.routrek.co.jp)
MacSSH/SFTP
　URLﾘﾝｸ(pro.wanadoo.fr)
PortForwarder
　URLﾘﾝｸ(www.fuji-climb.org)
TRAMP
　URLﾘﾝｸ(www.nongnu.org)

4:名無しさん＠お腹いっぱい。
06/04/20 07:10:21
◇規格等
IETF secsh
　URLﾘﾝｸ(www.ietf.org)
WideのSSH解説
　URLﾘﾝｸ(www.soi.wide.ad.jp)

◇おまけ
Theoのキチガイぶり
　ｽﾚﾘﾝｸ(unix板:546-550番)
djbsssh(ネタ)
　URLﾘﾝｸ(www.qmail.org)

5:名無しさん＠お腹いっぱい。
06/04/20 07:50:00
Theoつ

6:名無しさん＠お腹いっぱい。
06/04/20 19:37:27
>>4
> ◇規格等
> IETF secsh
> 　URLﾘﾝｸ(www.ietf.org)

今はRFC出てるっしょ。
　・RFC4250: The Secure Shell (SSH) Protocol Assigned Numbers
　・RFC4251: The Secure Shell (SSH) Protocol Architecture
　・RFC4252: The Secure Shell (SSH) Authentication Protocol
　・RFC4253: The Secure Shell (SSH) Transport Layer Protocol
　・RFC4254: The Secure Shell (SSH) Connection Protocol
　・RFC4255: Using DNS to Securely Publish Secure Shell (SSH)
　　Key Fingerprints
　・RFC4256: Generic Message Exchange Authentication for the Secure
　　Shell Protocol (SSH)

URLﾘﾝｸ(www.itmedia.co.jp)

7:名無しさん＠お腹いっぱい。
06/04/20 19:38:38
>>1-4
言い忘れたけど、乙！

8: ◆2YYPBG4Se.
06/04/20 23:48:04
>>3
　UTF-8 TeraTerm Pro with TTSSH2のその頁は，いまは見られないっぽいから，
URLは URLﾘﾝｸ(sourceforge.jp) あたりを書いておくほうがいいかと。

9:名無しさん＠お腹いっぱい。
06/04/21 05:09:18
rootで公開キーで接続したいのですが、公開キーはどこにコピーすればよいのでしょうか？
ユーザーの場合はホームディレクトリの.ssh内のauthorized_keysですが、rootの場合がよく分かりません。
よろしくお願いします。

10:名無しさん＠お腹いっぱい。
06/04/21 08:27:01
>>9
ホームディレクトリの.ssh内のauthorized_keys

11:名無しさん＠お腹いっぱい。
06/04/21 09:20:06
/root/.ssh/authorized_keys
でしょうか？やってみたのですがうまくいきません。

12:名無しさん＠お腹いっぱい。
06/04/21 11:15:51
>>11
sshd_config に PermitRootLogin yes

13:名無しさん＠お腹いっぱい。
06/04/21 11:24:53
面倒がらずにsu, sudoあたりを使うのが多少なりとも安全かと…

14:名無しさん＠お腹いっぱい。
06/04/22 00:51:10
>>12
消(ry

>>11
sshd_config に PermitRootLogin without-password

15:名無しさん＠お腹いっぱい。
06/04/22 01:31:47
VPS2台ある環境で、定期的に片方のサーバにバックアップを行う
SHを書いたんですが、
「Pseudo-terminal will not be allocated because stdin is not a terminal.」と
エラーが出たままコンソールが固まってしまいます。
（ctrl+cでエスケープできますが）

スクリプトはこれです。

#/bin/sh

rotate() {
ssh root@***
cd /home/backup
}

rotate &

何か考えられる原因はありますでしょうか。
ssh -t root@***は駄目でした。

16:名無しさん＠お腹いっぱい。
06/04/22 01:37:22
ｸﾏｰ

17:名無しさん＠お腹いっぱい。
06/04/23 03:16:56
URLﾘﾝｸ(www.google.co.jp)

18:ｷﾓｵﾀ
06/04/24 11:37:02
『dsaでの鍵認証が必要なグループ(webadmin)』と『パスワード認証のみのグループ(user)』という二通りのグループのユーザー達がログインできるような環境を作りたいのですが、もし可能でしたら教授頂きたいです。

下記の設定値を変更しながら複数のログイン環境を試みましたが、上述した二通りの条件を満たすに至りませんでした。

[etc/ssh/sshd_config]
ChallengeResponseAuthentication no
PasswordAuthentication yes
UsePAM yes

[etc/pam.d/ssh]
account required /lib/security/pam_access.so

[etc/security/access.conf]
+:ALL EXCEPT webadmin:ALL
-:ALL EXCEPT user:ALL

根本的に設定するファイルから間違っているのでしょうか・・
どなたか詳しい方、ヒントでもかまいません。
よろしくお願いしますm(_ _)m

19:名無しさん＠お腹いっぱい。
06/04/24 15:36:28
全角文字を含んだコマンドを発行できる無料sshクライアントがあったら教えて下さい。
現在はPuttyを使っているのですが、Puttyで全角文字を使用するのは無理ですよね？

20:名無しさん＠お腹いっぱい。
06/04/24 17:09:39
UTF-8 TeraTerm Pro with TTSSH2 のウィンドウにドラッグするとファイルを転送できる機能は
便利で良さそうなんだけど、プロトコルはどこで指定するのかなぁ・・・
デフォルトでは何使ってるんだろう？

21:名無しさん＠お腹いっぱい。
06/04/24 17:29:13
>>19
全角文字の入力ってことですよね？出来ていますが。

22:名無しさん＠お腹いっぱい。
06/04/24 18:06:10
>>18
> 『dsaでの鍵認証が必要なグループ(webadmin)』と『パスワード認証のみのグループ(user)』という二通りのグループのユーザー達がログインできるような環境を作りたい

OpenSSH はそういう小回り効かせた処理は不得手っぽいんで PAM と
組み合わせたところで無理なんじゃなかろか。

$sh.com のなら、UserSpecificConfig という user%group@host 単
位で指定できる副構成ファイル (正規表現なので group のみ指定可)
を使えるから、おそらく簡単に実現可能。

23:名無しさん＠お腹いっぱい。
06/04/24 19:37:22
>>18
ポート番号が違う異なる設定ファイルでそれぞれsshdが起動できるなら可能かも。

思いっきり思いつきだが。

24:ｷﾓｵﾀ
06/04/25 20:26:10
>>22 >>23
親切な方、ありがとう。

>>22
"$sh.com" "UserSpecificConfig" ぐぐってみたんですが、情報少ないですね；；

>>23
そのやりかたが一般的みたいですね、sshdを二つ以上起動しなくても普通にできてもいいことかなって思っていたのですがあきらめます；；

25:名無しさん＠お腹いっぱい。
06/04/25 20:27:37
>>24
つ、釣られないぞ…

26:ｷﾓｵﾀ
06/04/25 20:32:18
つ、釣ってないよ！

27:名無しさん＠お腹いっぱい。
06/04/26 12:05:04
> つ、釣ってないよ！

s/\$/S/

28:名無しさん＠お腹いっぱい。
06/04/27 03:06:32
openSSHでの公開鍵認証では、LDAPに登録した公開鍵などを利用する事は可能でしょうか？
調べてみたのですが、それらしい記述が見つかりませんでした。

29:名無しさん＠お腹いっぱい。
06/04/27 08:39:39
ためしたことはありませんが、
OPENSSH LDAP PUBLIC KEY PATCH
URLﾘﾝｸ(www.opendarwin.org)
というものがあります

30:28
06/04/27 12:48:35
>>29
情報ありがとうございます。
早速試してみようと思います。

31:名無しさん＠お腹いっぱい。
06/04/27 23:55:33
玄箱をVINE化して使ってます。先日、停電で玄箱が落ちてしまい、その後から
起動してもSSHで接続できなくなりました。sambaなどは正常に動いてます。
COMポートがないので二進も三進もいかなくて困っています。
HDDを取り外してPCに接続し、KNOPPIXで起動してHDD内のファイルを参照できました。
どこかファイルをいじれば復旧できるもんでしょうか？
識者の方、お知恵をお貸しください。

32:名無しさん＠お腹いっぱい。
06/04/28 00:43:56
>>31
telnet とか
rlogin とかいろいろあるじゃん

33:名無しさん＠お腹いっぱい。
06/04/28 01:07:29
>>3
VaraTermも今はPoderosaになってる。

URLﾘﾝｸ(ja.poderosa.org)

34:31
06/04/29 22:44:51
>>32
sshでしかつながらないように設定してあるんです。
telnetでもいいんでつなぐ方法ありますかね？
knoppixで起動して、/etc/rc.localにsshが起動するように
書いてみたんですがダメでした。。。

35:名無しさん＠お腹いっぱい。
06/04/29 23:40:57
telnetで繋がるようにすればいい

36:名無しさん＠お腹いっぱい。
06/04/29 23:55:44
>>34
マウントできるんなら、ログ見るとか
telnetd 有効にしてみるとかいろいろできるでしょ。

37:名無しさん＠お腹いっぱい。
06/04/30 08:51:15
>>34
>/etc/rc.localにsshが起動するように書いてみたんですが

sshじゃなくてsshdだが、というオチじゃないよね?
あと、Vineベースだとtelnetdは標準では無かったような・・(1CDの影響)
当然、rlogindもない。

あとは、inetdから/bin/shを直接起動するという荒技がある。
誰でもパスワード無しで入れることに注意だけど。

38:名無しさん＠お腹いっぱい。
06/05/02 00:03:27
玄箱の問題じゃなくてルーターの設定がデフォルト設定になって繋がらないというオチもあるな。

39:名無しさん＠お腹いっぱい。
06/05/04 02:02:01
PortForwarding を使うと localhost が実は他のサーバになったりしますが、
別のサーバに接続したいとき、毎回 ~/.ssh/known_hosts から localhost を
削除しないと
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED
が出てしまい接続できません。

このサーバの鍵のチェックを無視する方法はありませんでしょうか？

40:名無しさん＠お腹いっぱい。
06/05/04 02:49:40
>>39
ヒント: UserKnownHostsFile

41:39
06/05/04 07:26:12
なるほど、known_hosts をサーバごとに分けることができたのですね。
~/.ssh/config に
UserKnownHostsFile ~/.ssh/known_hosts_server1
を追加することで、毎回 known_hosts を編集しなくてよくなりました。
サンクス。

42:名無しさん＠お腹いっぱい。
06/05/06 15:02:16
scpはうまく動作するのですが、 ssh が動作しません。
$ssh -v host
の出力には、

debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

と出ますので、認証は成功してるっぽいのですが、
この表示の後、入力に対して全く応答がなくなります。

一体、何が起こっているのやら、皆目見当がつきません。
解決法、若しくは、原因を追究する方法に関する知恵をお貸しください。

43:名無しさん＠お腹いっぱい。
06/05/06 17:43:49
>>42
環境は? 他のユーザだとどうなの?

44:42
06/05/06 18:37:23
ローカルもリモートも同じくVine Linux です。
SSHは元から、入っていた物を使っております。

ローカルとリモートの間には、スイッチングハブが2台挟まっていますが、
以前、問題なく通信できており，pingも通りますので、
通信環境の問題ではないと思うのですが、詳しいところは判りません。

他ユーザーでは、どうか？との事ですが、
リモートホストで新規ユーザーを作成し、
ローカルからSSH経由でログインを試してみたところ、
新たに作成したユーザーでも同様の症状でした。

45:名無しさん＠お腹いっぱい。
06/05/08 03:42:02
>>42
うまく行ってるscpのコマンドラインとsshで入れてるユーザ名は一致してる？
sshdのログはどうなってる？

46:42
06/05/08 11:36:23
先程、ssh接続を試してみると問題なく接続できました。
うまくいかなかった原因は謎のままですが・・・。

ユーザー名ですが、一致しております。
また，ログですが、
/var/log/messages
/var/log/secure
を見る限りでは、認証は成功してるのですが、
セッションがオープンされていなかったようです。

過去、何度かこのような現象が起こっておりましたので、
できれば、原因を解明したいと思っています。
引続き、知恵を貸していただければ幸いです。

47:名無しさん＠お腹いっぱい。
06/05/09 00:06:18
>>46
疑似端末の確保ができないとそんな風になるかも?

48:名無しさん＠お腹いっぱい。
06/05/09 11:16:10
質問

SSHを使用した場合、
Linux上で動くサービスの通信プロセス全てがSSHを通して行われるの？
またはポート毎にSSHを通すor通さない等の設定は可能でしょうか？

49:名無しさん＠お腹いっぱい。
06/05/09 11:58:12
( ﾟдﾟ)ﾎﾟｶｰﾝ

50:名無しさん＠お腹いっぱい。
06/05/09 12:07:55
>>48
そういうことをやりたいときにはIPsecを使う

51:名無しさん＠お腹いっぱい。
06/05/09 13:23:42
URLﾘﾝｸ(www.unixuser.org)

52:42
06/05/10 12:48:26
>>47
擬似端末の確保ができない理由には、
どのような事が考えられるのでしょうか？

53:名無しさん＠お腹いっぱい。
06/05/10 14:01:07
>>52
疑似端末の数が足りない

54:42
06/05/11 18:20:51
53>>
SSHで接続しようとするユーザーは私だけですので，
擬似端末の数が足りないと言う事は無いと思います．

55:名無しさん＠お腹いっぱい。
06/05/11 21:30:30
>>54
質問しておいてその言い方はないだろ。

56:名無しさん＠お腹いっぱい。
06/05/12 06:41:41
はぁ～

57:名無しさん＠お腹いっぱい。
06/05/12 06:47:57
ひぃ～

58:42
06/05/12 08:08:26
申し訳ございませんでした。

>>53殿

SSHで接続しようとするユーザーは私だけでござりますので，　
>>53殿がおっしゃるような擬似端末の数が足りないなどと言う事は
無いとお申し上げございります．　

59:名無しさん＠お腹いっぱい。
06/05/12 09:37:19
ハットリ君？

60:名無しさん＠お腹いっぱい。
06/05/12 09:43:22
,.――-､
　ヽ /￣￣￣｀ヽ、
　　| |　（・）｡（･）|　　
　　| |＠＿,.--､_,> 　擬似端末が足りないはずはないでござる
　　ヽヽ＿＿＿ノ　　　　　　　　　　　　　　　　　　の巻

61:42
06/05/12 14:55:04
>>55
言い方が気に障ったのであれば謝ります。
ごめんなさい。

「擬似端末の数」との事でしたので、
私ひとりしか使っていなければ足りなくなる事は無いと思い込んでいたのですが、
調べてみましたが、そんな単純な物ではないようですね。
不見識を恥じます。

もし良ければ、Vinelinux での擬似端末の最大数の確認の仕方、
および、擬似端末の数が足りなくなる原因などを教えてください。

62:名無しさん＠お腹いっぱい。
06/05/12 14:58:25
>>61
Linux独自の確認法はLinux板で

63:42
06/05/12 17:39:44
そんなこと言わずに教えてくだすれ

64:42
06/05/12 18:03:43
Linux板のVine Linux Thread へ移動する事にしました。
質問に答えてくださり、どうもありがとうございました。

>>58,63
･･･。

65:名無しさん＠お腹いっぱい。
06/05/20 22:45:45
ﾕｰｻﾞｰ1がｻｰﾊﾞｰA上からｻｰﾊﾞｰBにSSHでログインしてｻｰﾊﾞｰCにトンネルを掘る
そのときﾕｰｻﾞｰ2がｻｰﾊﾞｰAからそのトンネルを使うことはできるんですか？

66:名無しさん＠お腹いっぱい。
06/05/20 22:52:12
>>65
できる(できてしまう)。

67:名無しさん＠お腹いっぱい。
06/05/20 23:10:16
>>66
即レスありがとうございます。やっぱりできるんですね。
Term二つ立ち上げてやってみたらできたんで、もしかしてと思って聞いてみました。
これって危険ですよね。ｻｰﾊﾞｰ上でトンネル掘るのはタブーなんでしょうか？

68:名無しさん＠お腹いっぱい。
06/05/20 23:17:58
トンネルのローカル側をUNIXドメインソケットにするようなことができれば
別ユーザにトンネルを使われることはなくなるかな。
そういうsshって存在するのかな?

69:名無しさん＠お腹いっぱい。
06/05/21 02:19:41
あったとして役に立つシーンがあまり思い浮かばない。

70:名無しさん＠お腹いっぱい。
06/05/22 08:28:04
>>65-67
なんか問題ある？

71:名無しさん＠お腹いっぱい。
06/05/22 21:18:52
>>70
偶然他人がトンネルを発見すると、普通はｻｰﾊﾞｰBからは見えない
（がｻｰﾊﾞｰCからは見える）ホストにアクセスできてしまう可能性があります。
例えばNATの内側とか。

72:名無しさん＠お腹いっぱい。
06/05/22 22:33:48
サーバ側からのトンネルは基本的に自分に返すのに使うんだから
自分側でアクセスをサーバのみに絞っておけばいいんでねーの？
あれ？

73:名無しさん＠お腹いっぱい。
06/05/22 22:49:09
>>71
> 例えばNATの内側とか。
デフォルトだと GatewayPorts が no だからいいんじゃね?

74:名無しさん＠お腹いっぱい。
06/05/23 00:13:28
>>71
なんか問題ある？

75:名無しさん＠お腹いっぱい。
06/05/23 00:22:34
むしろ見せたいんですが。80番とか。

76:名無しさん＠お腹いっぱい。
06/05/24 10:50:56
質問です。.ssh/を保護しつつscpを許可する方法ってないでしょうか。
他人のホストから自分のホストにスクリプトでscpを自動実行させたいのですが、
authorizedしてしまうと他人のホストのrootは自分のホストに対してやりたい放題です。当たり前ですが。
そもそも発想からして間違ってるかも知れませんね・・。

77:名無しさん＠お腹いっぱい。
06/05/24 11:30:26
>>76
そもそも信用できないroot管理下にいるユーザを信用するのはおかしい。信用してはいけない。
それを踏まえた上で、restricted scp/sftp 使うくらいしかないんでない?

78:76
06/05/24 13:34:09
>>77
ありがとうございます。やはりそうですよね。
相手ユーザー自体は信頼できないわけじゃないんですが、
理論上のセキュリティホールであることを気にしていました。
何か全く別の方法を考えるしかないですね。

79:名無しさん@お腹いっぱい
06/05/24 22:09:58
>76
chrootsshってのもあるけど、
URLﾘﾝｸ(chrootssh.sourceforge.net)
こういう事じゃないのかな?

80:名無しさん＠お腹いっぱい。
06/05/24 22:40:04
scponlyとか使えばいいんじゃない？

81:名無しさん＠お腹いっぱい。
06/05/24 23:16:35
>>76
大げさかも知れんがSELinuxとかで.ssh/書き込み不可能にしてみるとか。

82:名無しさん＠お腹いっぱい。
06/05/25 00:26:53
>>79-81
ありがとうございます。
chrootもscponlyも検討しました。
scponlyは何故かうまく動かなくて、ログインシェルに指定するとscpすらできず。。
chrootはまだ試していません。もう少しチャレンジしてみます。

.sshをアク禁にする方法があるとは知りませんでした。これも勉強してみます。

ただ、ネックとなる条件がいくつかありまして、
最初の公開鍵の作成から流し込みまでリモートホストから半自動実行させるため、
.sshをアク禁にはできないのです。
このやり方が問題なのかも知れませんが、リモートホストが大量にあるため。。

83:76
06/05/25 00:37:21
あ、>>82は私です。

続きです。
できればsshも制限つきで使えるようにしておきたいので、
理想に近いのはchrootでディレクトリを絞って、かつ.sshをアク禁にするか、
失敗しているscponlyを成功させて、sshが必要なところは諦めて手動にするか、
といったところです。

84:名無しさん@お腹いっぱい
06/05/25 21:47:37
>76
いまいちよくわかんないんだけどさ
たとえば、｢他人｣て言うユーザーアカウントがあったとして、｢他人｣がログインすると
/home/他人になるよね。
で、chrootssh使えば、｢他人｣がログインしたディレクトリ=/home/他人が
ルートになってそこより上の階層にはいけないから、
｢やりたい放題｣にはならないと思うんだけど、これだと何が問題なの?

85:名無しさん＠お腹いっぱい。
06/05/26 10:09:46
>>79
そこのモジュールは
いくらかまえのバージョンで本家と統合された

86:名無しさん@お腹いっぱい。
06/05/26 21:00:43
>85
そうなの?
4.3p1でもパッチ出てるけど,不要なの?

87:名無しさん＠お腹いっぱい。
06/05/27 07:49:48
"本家"と書いたらssh.com版を指す
opensshはあくまで亜流

88:名無しさん＠お腹いっぱい。
06/05/27 15:30:37
>>87
> "本家"と書いたらssh.com版を指す

そうなのか？！俺はちょっと分かりにくいと思った。。（>>86氏と同じように考えた
んで）
ssh.comのもの(T.Yolen氏が作ったもの)が確かに「本家」であるのは間違いない
が、一番よく使われているのはOpenSSHだからね…。

「商用のもの」と書くか（これはこれで混乱するカモ）、「本家(ssh.com)のもの」
と書くと余計な誤解を防げるかと

89:名無しさん＠お腹いっぱい。
06/05/27 15:51:10
>>88
> >

90:86
06/05/27 20:58:06
>87
了解

91:名無しさん＠お腹いっぱい。
06/05/28 08:51:12
自分がどう思うか、じゃ無くて
世の中ではどう扱われているかってことだよな、大事なのは

92:名無しさん＠お腹いっぱい。
06/05/28 22:02:20
最近頻発してるBruteForceAttackにリアルタイムに対応するために、
tcpserver経由でrblsmtpdを呼び出してsmtpdみたいなのを真似して
動くrblsshdを公開したら需要あるのかなぁ？

運用時の問題はRBLの更新速度やRBLの管理なんだけども… (´・ω・｀)

93:名無しさん＠お腹いっぱい。
06/05/29 01:33:16
忘れたのでrblsshd動作様子@syslog

May 29 01:24:53 ari sshd: tcpserver: status: 1/100
May 29 01:24:53 ari sshd: tcpserver: pid 62452 from 127.0.0.1
May 29 01:24:53 ari sshd: tcpserver: ok 62452 localhost:127.0.0.1:10022 localhost:127.0.0.1::1966
May 29 01:24:56 ari sshd: rblsshd: Banned IP:127.0.0.1: 553 NO MORE
May 29 01:24:56 ari sshd: tcpserver: end 62452 status 0
May 29 01:24:56 ari sshd: tcpserver: status: 0/100

sshを使った時。
% ssh localhost -p 10022 -v
OpenSSH_3.5p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to localhost.local.jp [127.0.0.1] port 10022.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 1.9, remote software version rblsshd 0.0.1 AHYA(0_0)
debug1: no match: rblsshd 0.0.1 AHYA(0_0)
debug1: Local version string SSH-1.5-OpenSSH_3.5p1 FreeBSD-20030924
debug1: Waiting for server public key.
Disconnecting: Bad packet length 1349676916.
debug1: Calling cleanup 0x804c158(0x0)

sshdの鍵を送るときに適当に送ってるのでオーバーフローしちゃってますけど…。
中身はrblsmtpdを元にやっつけなので、もっさりな動作してます（´・ω・｀）

94:名無しさん＠お腹いっぱい。
06/05/29 08:09:25
>>93
sourceforge にアカウントとって公開してみればいいんじゃね?

95:名無しさん＠お腹いっぱい。
06/05/29 13:09:53
macにrootでアクセスしたいのですが、mac側でrootのパスワードはどこで設定するのでしょうか？

96:名無しさん＠お腹いっぱい。
06/05/29 13:15:05
OSXの話か？
購入時のまにゅある見てみ？

97:名無しさん＠お腹いっぱい。
06/06/03 16:10:42
>96
Mac OS Xはrootアカウントが無効になっている。だからマニュアル読んでも……

98:名無しさん＠お腹いっぱい。
06/06/04 13:02:56
X11のポートフォワードで、
local側をinet:じゃなくてlocal:に接続させるpatchってないんですかね?

99:名無しさん＠お腹いっぱい。
06/06/04 13:29:04
>>98
何もしなくてもlocal側はLOCAL:(UNIXドメインソケット)にフォワードされる。
正確には、sshクライアント実行時のDISPLAY環境変数の値に
フォワードされる。もしINET:になってるのなら、DISPLAYの値が
localhost:0とかのINETドメインになってるんじゃないの?
DISPLAY=:0の状態でsshするべし。

100:名無しさん＠お腹いっぱい。
06/06/04 23:12:29
URLﾘﾝｸ(nanno.dip.jp)
これ使ってる人いませんか？

101:名無しさん＠お腹いっぱい。
06/06/06 18:13:03
初歩的な質問ですが、お願いします。

例えば、sshクライアント側のiptablesの設定は
-A INPUT -p tcp -s $(sshサーバ) --sport 22 -d $(自分) -j ACCEPT
-A OUTPUT -d $(sshサーバ) -s $(自分) -j ACCEPT
みたいにすればできますが、これって相手が22番ポートを使うように偽装した場合、侵入されてしまうと思うのですが、
実際はどうなんでしょうか？
でも他に方法ないし…

102:名無しさん＠お腹いっぱい。
06/06/06 19:16:18
なんでくだ質スレにいかないの?

103:101
06/06/06 19:50:28
逝ってきます
スレ汚し失礼しました

104:名無しさん＠お腹いっぱい。
06/06/06 21:08:27
>>101
そんな信用出来ないところにログインするなよ。

105:101
06/06/06 21:15:30
>>104
大学のサーバなので信用出来ないわけではないのですが…

ふと思ったので質問してしまいました

106:名無しさん＠お腹いっぱい。
06/06/07 02:20:30
Accelerating OpenSSH connections with ControlMaster
URLﾘﾝｸ(tips.linux.com)

107:名無しさん＠お腹いっぱい。
06/06/11 06:13:23
大学のサーバは信用しない方がいいね

108:名無しさん＠お腹いっぱい。
06/06/11 21:31:38
そうなんか？
プロを雇ってやってんじゃないの？（雇ってないとこは論外だが）

109:名無しさん＠お腹いっぱい。
06/06/12 00:54:12
ボランティアベースのプロだろうなw

110:名無しさん＠お腹いっぱい。
06/06/12 01:55:53
実態はひどいもんだよ

プロっていっても鯖の掃除しに来てるだけとかな

111:名無しさん＠お腹いっぱい。
06/06/12 02:34:49
うちの大学のネットワーク管理部門、連絡手段はメールのみだって。

以前、ルータにトラブルがあって、学科のLANから外にまったく繋がらなくなった。
学内部門電話帳で調べて電話したけど、秘書か誰かが「繋ぐことはできません」って。
仕方ないので研究室の電話使ってプロバイダに繋いで、ISPのメールアドレスから連絡したよ。
こいつら馬鹿なんじゃね？

112:名無しさん＠お腹いっぱい。
06/06/12 02:38:09
いい加減スレ違い。

113:名無しさん＠お腹いっぱい。
06/06/12 02:41:57
いつの話か知らんが
いまどき携帯メール使うだろ

114:名無しさん＠お腹いっぱい。
06/06/12 02:47:11
>>112
すまん、

>>113
結構前。まだ手持ちの携帯でメールは出せなかった。

115:名無しさん＠お腹いっぱい。
06/06/12 03:42:09
パスワード認証は平文で行われるから使うな

という間違った話はいまだに聞くことあるな
どこがソースなんだろう？

116:名無しさん＠お腹いっぱい。
06/06/12 05:16:42

いずれにしろパスワード認証はシラミツブシ攻撃に対して激しく弱いから使うな

おまいらのsecurityログにも攻撃の痕が大量に残ってるだろ？

117:名無しさん＠お腹いっぱい。
06/06/12 12:25:47
俺ポート変えてるから

118:名無しさん＠お腹いっぱい。
06/06/12 16:55:07
SSHの読みはシュシュハッでいいのですか？

119:名無しさん＠お腹いっぱい。
06/06/12 17:29:29
普通に「エスエスエイチ」でいいんじゃない？
Wikipedia項目ﾘﾝｸ

120:名無しさん＠お腹いっぱい。
06/06/12 18:53:28
>>115
平文？キースキーミングとかでヤバイってわけじゃなくて？

DSAｷｰとか使うってのが普通なんで，パスワードなんて最後の最後の手段じゃないか？

121:名無しさん＠お腹いっぱい。
06/06/12 19:29:48
SSHH シシハハ

122:名無しさん＠お腹いっぱい。
06/06/12 19:33:31
>>120
よく読め。

123:名無しさん＠お腹いっぱい。
06/06/12 20:52:11
>>116
denyhostsしてるし…

124:名無しさん＠お腹いっぱい。
06/06/13 18:08:38
RSAとDSAってどっちが良いの？

125:名無しさん＠お腹いっぱい。
06/06/13 18:55:40
DSAならキーボードからの打ち間違えが少ない

126:124
06/06/13 19:24:12
すまんせん意味分からんス

127:名無しさん＠お腹いっぱい。
06/06/13 19:34:48
どっちでもいいんじゃね？

128:名無しさん＠お腹いっぱい。
06/06/13 19:41:12
w
qwertyみたいにホームポジションから動かなくても打てるからかヨw

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

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

130:名無しさん＠お腹いっぱい。
06/06/14 12:20:05
>>129
パスフレーズはどうするのがいいと思うの?
expect で自動化? 平文でどっかに書いとくの?

131:名無しさん＠お腹いっぱい。
06/06/14 13:47:08
セキュアにしたいなら毎回パスワードを入力した方が良いんじゃないの。
セキュリティを犠牲にしてでも手間を省きたいならssh-agentを使えばいいじゃん

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

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

133:名無しさん＠お腹いっぱい。
06/06/14 22:39:23

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

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

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

134:ヽ(´ー`)ノ ◆.ogCuANUcE
06/06/15 00:19:41
>>129
概ね同意できると思うが。

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

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

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

至極当たり前の考え。

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

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

135:名無しさん＠お腹いっぱい。
06/06/15 01:16:50
>>132
> 自分はssh-agent＋ssh-addで自動運転、が普通だと思ってました。

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

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

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

136:名無しさん＠お腹いっぱい。
06/06/15 02:10:24
公開鍵認証なんて秘密鍵を盗まれればおしまいだよ。

137:名無しさん＠お腹いっぱい。
06/06/15 02:22:02
盗まれたら速攻でrevokeっしょ。

138:名無しさん＠お腹いっぱい。
06/06/15 02:49:36
確認せずに yes 連発するやつらばっかりだから MITM でいいよ。

139:ヽ(´ー`)ノ ◆.ogCuANUcE
06/06/15 05:40:32
>>136
鍵を盗まれてから trust な鍵のペアに交換するまでの時間が稼げる分、
パスフレーズ付きが若干有利ってだけで、結局それに尽きる。

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

140:名無しさん＠お腹いっぱい。
06/06/15 06:36:30
Theoみたいな奴がそう簡単に秘密鍵を盗まれるのか？

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

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

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

142:名無しさん＠お腹いっぱい。
06/06/15 15:43:17
すべてのマシンで同じ鍵を使用しているのですが、マシンごとにそれぞれ鍵を作る
のが一般的なのでしょうか？

143:名無しさん＠お腹いっぱい。
06/06/15 21:03:39
そう。

144:名無しさん＠お腹いっぱい。
06/06/16 19:27:23
認証転送使えばssh-agent乗っ取りのリスクも少しは軽減されるんすか？
URLﾘﾝｸ(www.h7.dion.ne.jp)

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

146:名無しさん＠お腹いっぱい。
06/06/24 16:40:02
いくつもある UNIX 鯖に Windows マシンからトンネル張るために
毎度毎度 ssh クライアントでログインしなくてもいいように、
Windows のダイヤルアップアダプタか VPN アダプタのように扱える
SSH ポートフォワーディング用のソフトってないですかね・・・

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

147:名無しさん＠お腹いっぱい。
06/06/24 17:08:25
plink

148:名無しさん＠お腹いっぱい。
06/06/24 18:49:25

PortForwarder
URLﾘﾝｸ(www.fuji-climb.org)

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

150:名無しさん＠お腹いっぱい。
06/06/25 06:27:57
otp でいいじゃん

151:名無しさん＠お腹いっぱい。
06/06/25 10:18:13
なんでもかんでもsshで解決しようとするのか

152:名無しさん＠お腹いっぱい。
06/06/25 10:21:20
>>151 他の方法での通信を組織がポリシーとして許してくれない。

153:名無しさん＠お腹いっぱい。
06/06/26 20:58:55
[1] 入門OpenSSH
　　URLﾘﾝｸ(www.shuwasystem.co.jp)

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

from
　コンピュータ関連書籍新刊一覧
　URLﾘﾝｸ(pc.watch.impress.co.jp)

参考までに、既刊書籍：

[2] 入門SSH
　　URLﾘﾝｸ(www.ascii.co.jp)

[3] (絶版)OpenSSH セキュリティ管理ガイド
　　URLﾘﾝｸ(www.shuwasystem.co.jp)

154:名無しさん＠お腹いっぱい。
06/06/27 18:42:57
どんな時に、sshのhost-keyは変わりますか？

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

155:名無しさん＠お腹いっぱい。
06/06/27 20:10:54
>>154
host-keyを変えたとき

156:名無しさん＠お腹いっぱい。
06/06/27 20:40:30
「入門OpenSSH」買ってきた。
巻末の「著者紹介」がなくなってた。まあ、どうでもいい(DDI)けど。

157:名無しさん＠お腹いっぱい。
06/06/28 02:12:41
>>154
ホストをクラックされて host key を変えられたとき
MITM されてるとき

158:名無しさん＠お腹いっぱい。
06/06/30 00:59:53
[3]は持ってるんだけど、
[1]はその改訂版なの？
あと対応バージョンはいくつなんだろう

159:名無しさん＠お腹いっぱい。
06/06/30 14:35:30
あげ

160:名無しさん＠お腹いっぱい。
06/07/05 22:53:49
bit数ってみんなどれくらいにしてまつか？
2048じゃ今時足りない？

161:名無しさん＠お腹いっぱい。
06/07/06 15:38:34
URLﾘﾝｸ(www.atmarkit.co.jp)
@ITのこの記事読んで特定のコマンドしか実行できないユーザ作ったんですが。

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

ssh foo@bar bash -i

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

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

162:名無しさん＠お腹いっぱい。
06/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.

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

164:名無しさん＠お腹いっぱい。
06/07/06 16:33:08
>>161
これってフルパスでコマンド実行できない？？

165:名無しさん＠お腹いっぱい。
06/07/06 16:50:41
/etc/exportsの(の前にスペース入れちゃう人だからねえ

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

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

>>165
怖っ！ｗ

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

167:名無しさん＠お腹いっぱい。
06/07/08 07:03:30
もしrootの人に秘密鍵を盗まれてしまったら、そのrootの人は、公開鍵を置いてあるサーバに自由にアクセスできるようになってしまうのでしょうか？

168:名無しさん＠お腹いっぱい。
06/07/08 08:47:47
>>167
つパスフレーズ

169:名無しさん＠お腹いっぱい。
06/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で出力のこの辺みろとか、なにかアドバイスいただけ
ると助かります。

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

171:167
06/07/08 19:33:43
パスフレーズは設定していません

172:名無しさん＠お腹いっぱい。
06/07/08 19:46:34
おわた

173:名無しさん＠お腹いっぱい。
06/07/09 00:21:28
>>171
それはもうだめかもわからんね。

174:名無しさん＠お腹いっぱい。
06/07/09 12:03:52
公開鍵を換えなさい

175:名無しさん＠お腹いっぱい。
06/07/09 14:20:05
/etc/sshのconfigファイル、ほとんど#がかかってるけど一体どれがデフォになってるのかﾜｹﾜｶﾒ

176:名無しさん＠お腹いっぱい。
06/07/09 15:03:56
環境を書かないとはこれいかに。

177:名無しさん＠お腹いっぱい。
06/07/09 19:19:46
#がデフォルトだろ

178:名無しさん＠お腹いっぱい。
06/07/10 15:02:24
入門OpenSSH
URLﾘﾝｸ(www.amazon.co.jp)

179:名無しさん＠お腹いっぱい。
06/07/10 21:42:14
>>177
そうとはかぎらんよ

180:名無しさん＠お腹いっぱい。
06/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.

181:名無しさん＠お腹いっぱい。
06/07/11 03:31:36
----修正前
# PasswordAuthentication yes

...

# PermitRootLogin yes
----修正前

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

...

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

182:名無しさん＠お腹いっぱい。
06/07/11 12:17:03
opensshでサーバ証明書じゃなくて個人証明書で認証を行わせることってできるでしょうか。

183:名無しさん＠お腹いっぱい。
06/07/11 17:00:13
>>179
どっちなのよ？

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

184:名無しさん＠お腹いっぱい。
06/07/11 23:39:34
デフォルトの値を知りたきゃmanすれ。

185:名無しさん＠お腹いっぱい。
06/07/12 09:36:33
manはたまに信用ならんからソース嫁

186:名無しさん＠お腹いっぱい。
06/07/12 10:40:49
ﾒﾝﾄﾞｸｾ

187:名無しさん＠お腹いっぱい。
06/07/12 12:16:23
>>186
んじゃ2chで聞け

(>>175にﾓﾄﾞﾙ)

188:名無しさん＠お腹いっぱい。
06/07/12 12:52:11
なんでずっと環境隠してるんだろう。

189:名無しさん＠お腹いっぱい。
06/07/12 22:32:07
>>186
じゃあ、デフォ使わないで明示的に指定
した方が早い気ガス

190:名無しさん＠お腹いっぱい。
06/07/12 23:04:47
parent_domain_matches_subdomainsがけしからん！

191:名無しさん＠お腹いっぱい。
06/07/13 22:40:06
man sshd_configにRhostsRSAAuthenticationとHostbasedAuthentication は似てるってあるけど、全く同じなんじゃないの？
クライアントの公開鍵がsshサーバの~/.ssh/known_hostsに入ってるかどうか、ってことでそ？
誰か教えてください

192:名無しさん＠お腹いっぱい。
06/07/14 00:07:49
>>191
SSHプロトコルのバージョンの違い。前者（RhostsRSAAuthentication）はバージ
ョン1のみで、後者（HostbasedAuthentication）はバージョン2のみで使われる。

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

次ページ