SSH その5

**名無しさん＠お腹いっぱい。** · 2006/04/20(木) 07:09:00

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

過去ログ
　Part1：http://pc.2ch.net/unix/kako/976/976497035.html
　Part2：http://pc.2ch.net/unix/kako/1028/10281/1028157825.html
　Part3：http://pc5.2ch.net/unix/kako/1058/10582/1058202104.html
Part4：http://pc8.2ch.net/test/read.cgi/unix/1102242908/

**名無しさん＠お腹いっぱい。** · 2006/05/20(土) 23:10:16

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

**名無しさん＠お腹いっぱい。** · 2006/05/20(土) 23:17:58

トンネルのローカル側をUNIXドメインソケットにするようなことができれば
別ユーザにトンネルを使われることはなくなるかな。
そういうsshって存在するのかな?

**名無しさん＠お腹いっぱい。** · 2006/05/21(日) 02:19:41

あったとして役に立つシーンがあまり思い浮かばない。

**名無しさん＠お腹いっぱい。** · 2006/05/22(月) 08:28:04

>>65-67
なんか問題ある？

**名無しさん＠お腹いっぱい。** · 2006/05/22(月) 21:18:52

>>70
偶然他人がトンネルを発見すると、普通はｻｰﾊﾞｰBからは見えない
（がｻｰﾊﾞｰCからは見える）ホストにアクセスできてしまう可能性があります。
例えばNATの内側とか。

**名無しさん＠お腹いっぱい。** · 2006/05/22(月) 22:33:48

サーバ側からのトンネルは基本的に自分に返すのに使うんだから
自分側でアクセスをサーバのみに絞っておけばいいんでねーの？
あれ？

**名無しさん＠お腹いっぱい。** · 2006/05/22(月) 22:49:09

>>71
> 例えばNATの内側とか。
デフォルトだと GatewayPorts が no だからいいんじゃね?

**名無しさん＠お腹いっぱい。** · 2006/05/23(火) 00:13:28

>>71
なんか問題ある？

**名無しさん＠お腹いっぱい。** · 2006/05/23(火) 00:22:34

むしろ見せたいんですが。80番とか。

**名無しさん＠お腹いっぱい。** · 2006/05/24(水) 10:50:56

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

**名無しさん＠お腹いっぱい。** · 2006/05/24(水) 11:30:26

>>76
そもそも信用できないroot管理下にいるユーザを信用するのはおかしい。信用してはいけない。
それを踏まえた上で、restricted scp/sftp 使うくらいしかないんでない?

76 · 2006/05/24(水) 13:34:09

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

**名無しさん@お腹いっぱい** · 2006/05/24(水) 22:09:58

>76
chrootsshってのもあるけど、
ttp://chrootssh.sourceforge.net/index.php
こういう事じゃないのかな?

**名無しさん＠お腹いっぱい。** · 2006/05/24(水) 22:40:04

scponlyとか使えばいいんじゃない？

**名無しさん＠お腹いっぱい。** · 2006/05/24(水) 23:16:35

>>76
大げさかも知れんがSELinuxとかで.ssh/書き込み不可能にしてみるとか。

**名無しさん＠お腹いっぱい。** · 2006/05/25(木) 00:26:53

>>79-81
ありがとうございます。
chrootもscponlyも検討しました。
scponlyは何故かうまく動かなくて、ログインシェルに指定するとscpすらできず。。
chrootはまだ試していません。もう少しチャレンジしてみます。

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

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

76 · 2006/05/25(木) 00:37:21

あ、>>82は私です。

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

**名無しさん@お腹いっぱい** · 2006/05/25(木) 21:47:37

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

**名無しさん＠お腹いっぱい。** · 2006/05/26(金) 10:09:46

>>79
そこのモジュールは
いくらかまえのバージョンで本家と統合された

**名無しさん@お腹いっぱい。** · 2006/05/26(金) 21:00:43

>85
そうなの?
4.3p1でもパッチ出てるけど,不要なの?

**名無しさん＠お腹いっぱい。** · 2006/05/27(土) 07:49:48

"本家"と書いたらssh.com版を指す
opensshはあくまで亜流

**名無しさん＠お腹いっぱい。** · 2006/05/27(土) 15:30:37

>>87
> "本家"と書いたらssh.com版を指す

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

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

**名無しさん＠お腹いっぱい。** · 2006/05/27(土) 15:51:10

>>88
> >

86 · 2006/05/27(土) 20:58:06

>87
了解

**名無しさん＠お腹いっぱい。** · 2006/05/28(日) 08:51:12

自分がどう思うか、じゃ無くて
世の中ではどう扱われているかってことだよな、大事なのは

**名無しさん＠お腹いっぱい。** · 2006/05/28(日) 22:02:20

最近頻発してるBruteForceAttackにリアルタイムに対応するために、
tcpserver経由でrblsmtpdを呼び出してsmtpdみたいなのを真似して
動くrblsshdを公開したら需要あるのかなぁ？

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

**名無しさん＠お腹いっぱい。** · 2006/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を元にやっつけなので、もっさりな動作してます（´・ω・｀）

**名無しさん＠お腹いっぱい。** · 2006/05/29(月) 08:09:25

>>93
sourceforge にアカウントとって公開してみればいいんじゃね?

**名無しさん＠お腹いっぱい。** · 2006/05/29(月) 13:09:53

macにrootでアクセスしたいのですが、mac側でrootのパスワードはどこで設定するのでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/05/29(月) 13:15:05

OSXの話か？
購入時のまにゅある見てみ？

**名無しさん＠お腹いっぱい。** · 2006/06/03(土) 16:10:42

>96
Mac OS Xはrootアカウントが無効になっている。だからマニュアル読んでも……

**名無しさん＠お腹いっぱい。** · 2006/06/04(日) 13:02:56

X11のポートフォワードで、
local側をinet:じゃなくてlocal:に接続させるpatchってないんですかね?

**名無しさん＠お腹いっぱい。** · 2006/06/04(日) 13:29:04

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

**名無しさん＠お腹いっぱい。** · 2006/06/04(日) 23:12:29

ttp://nanno.dip.jp/softlib/man/rlogin/
これ使ってる人いませんか？

**名無しさん＠お腹いっぱい。** · 2006/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番ポートを使うように偽装した場合、侵入されてしまうと思うのですが、
実際はどうなんでしょうか？
でも他に方法ないし…

**名無しさん＠お腹いっぱい。** · 2006/06/06(火) 19:16:18

なんでくだ質スレにいかないの?

**101** · 2006/06/06(火) 19:50:28

逝ってきます
スレ汚し失礼しました

**名無しさん＠お腹いっぱい。** · 2006/06/06(火) 21:08:27

>>101
そんな信用出来ないところにログインするなよ。

**101** · 2006/06/06(火) 21:15:30

>>104
大学のサーバなので信用出来ないわけではないのですが…

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

**名無しさん＠お腹いっぱい。** · 2006/06/07(水) 02:20:30

Accelerating OpenSSH connections with ControlMaster
http://tips.linux.com/article.pl?sid=06/05/19/145227

**名無しさん＠お腹いっぱい。** · 2006/06/11(日) 06:13:23

大学のサーバは信用しない方がいいね

**名無しさん＠お腹いっぱい。** · 2006/06/11(日) 21:31:38

そうなんか？
プロを雇ってやってんじゃないの？（雇ってないとこは論外だが）

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 00:54:12

ボランティアベースのプロだろうなw

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 01:55:53

実態はひどいもんだよ

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

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 02:34:49

うちの大学のネットワーク管理部門、連絡手段はメールのみだって。

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

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 02:38:09

いい加減スレ違い。

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 02:41:57

いつの話か知らんが
いまどき携帯メール使うだろ

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 02:47:11

>>112
すまん、

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

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 03:42:09

パスワード認証は平文で行われるから使うな

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

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 05:16:42

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

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

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 12:25:47

俺ポート変えてるから

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 16:55:07

SSHの読みはシュシュハッでいいのですか？

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 17:29:29

普通に「エスエスエイチ」でいいんじゃない？
http://ja.wikipedia.org/wiki/Secure_Shell

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 18:53:28

>>115
平文？キースキーミングとかでヤバイってわけじゃなくて？

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

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 19:29:48

SSHH シシハハ

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 19:33:31

>>120
よく読め。

**名無しさん＠お腹いっぱい。** · 2006/06/12(月) 20:52:11

>>116
denyhostsしてるし…

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 18:08:38

RSAとDSAってどっちが良いの？

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 18:55:40

DSAならキーボードからの打ち間違えが少ない

**124** · 2006/06/13(火) 19:24:12

すまんせん意味分からんス

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 19:34:48

どっちでもいいんじゃね？

**名無しさん＠お腹いっぱい。** · 2006/06/13(火) 19:41:12

w
qwertyみたいにホームポジションから動かなくても打てるからかヨw

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 12:09:12

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

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

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 12:20:05

>>129
パスフレーズはどうするのがいいと思うの?
expect で自動化? 平文でどっかに書いとくの?

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 13:47:08

セキュアにしたいなら毎回パスワードを入力した方が良いんじゃないの。
セキュリティを犠牲にしてでも手間を省きたいならssh-agentを使えばいいじゃん

**129** · 2006/06/14(水) 21:55:03

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

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

**名無しさん＠お腹いっぱい。** · 2006/06/14(水) 22:39:23

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

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

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

**ヽ(´ー`)ノ** ◆.ogCuANUcE · 2006/06/15(木) 00:19:41

>>129
概ね同意できると思うが。

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

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

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

至極当たり前の考え。

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

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

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 01:16:50

>>132
> 自分はssh-agent＋ssh-addで自動運転、が普通だと思ってました。

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

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

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

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 02:10:24

公開鍵認証なんて秘密鍵を盗まれればおしまいだよ。

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 02:22:02

盗まれたら速攻でrevokeっしょ。

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 02:49:36

確認せずに yes 連発するやつらばっかりだから MITM でいいよ。

**ヽ(´ー`)ノ** ◆.ogCuANUcE · 2006/06/15(木) 05:40:32

>>136
鍵を盗まれてから trust な鍵のペアに交換するまでの時間が稼げる分、
パスフレーズ付きが若干有利ってだけで、結局それに尽きる。

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

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 06:36:30

Theoみたいな奴がそう簡単に秘密鍵を盗まれるのか？

**132** · 2006/06/15(木) 15:01:11

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

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

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

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 15:43:17

すべてのマシンで同じ鍵を使用しているのですが、マシンごとにそれぞれ鍵を作る
のが一般的なのでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/06/15(木) 21:03:39

そう。

**名無しさん＠お腹いっぱい。** · 2006/06/16(金) 19:27:23

認証転送使えばssh-agent乗っ取りのリスクも少しは軽減されるんすか？
ttp://www.h7.dion.ne.jp/~matsu/feature/uzumi/tool_memo/ssh.html#1

**名無しさん＠お腹いっぱい。** · 2006/06/17(土) 13:33:24

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

**名無しさん＠お腹いっぱい。** · 2006/06/24(土) 16:40:02

いくつもある UNIX 鯖に Windows マシンからトンネル張るために
毎度毎度 ssh クライアントでログインしなくてもいいように、
Windows のダイヤルアップアダプタか VPN アダプタのように扱える
SSH ポートフォワーディング用のソフトってないですかね・・・

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

**名無しさん＠お腹いっぱい。** · 2006/06/24(土) 17:08:25

plink

**名無しさん＠お腹いっぱい。** · 2006/06/24(土) 18:49:25

PortForwarder
http://www.fuji-climb.org/pf/JP/

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 06:01:33

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

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 06:27:57

otp でいいじゃん

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 10:18:13

なんでもかんでもsshで解決しようとするのか

**名無しさん＠お腹いっぱい。** · 2006/06/25(日) 10:21:20

>>151 他の方法での通信を組織がポリシーとして許してくれない。

**名無しさん＠お腹いっぱい。** · 2006/06/26(月) 20:58:55

[1] 入門OpenSSH
　　http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1348-X

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

from
　コンピュータ関連書籍新刊一覧
　http://pc.watch.impress.co.jp/docs/2006/market/i_nbook.htm

参考までに、既刊書籍：

[2] 入門SSH
　　http://www.ascii.co.jp/books/books/detail/4-7561-4553-1.shtml

[3] (絶版)OpenSSH セキュリティ管理ガイド
　　http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-0129-5

**名無しさん＠お腹いっぱい。** · 2006/06/27(火) 18:42:57

どんな時に、sshのhost-keyは変わりますか？

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

**名無しさん＠お腹いっぱい。** · 2006/06/27(火) 20:10:54

>>154
host-keyを変えたとき

**名無しさん＠お腹いっぱい。** · 2006/06/27(火) 20:40:30

「入門OpenSSH」買ってきた。
巻末の「著者紹介」がなくなってた。まあ、どうでもいい(DDI)けど。

**名無しさん＠お腹いっぱい。** · 2006/06/28(水) 02:12:41

>>154
ホストをクラックされて host key を変えられたとき
MITM されてるとき

**名無しさん＠お腹いっぱい。** · 2006/06/30(金) 00:59:53

[3]は持ってるんだけど、
[1]はその改訂版なの？
あと対応バージョンはいくつなんだろう

**名無しさん＠お腹いっぱい。** · 2006/06/30(金) 14:35:30

あげ

**名無しさん＠お腹いっぱい。** · 2006/07/05(水) 22:53:49

bit数ってみんなどれくらいにしてまつか？
2048じゃ今時足りない？

**名無しさん＠お腹いっぱい。** · 2006/07/06(木) 15:38:34

http://www.atmarkit.co.jp/flinux/rensai/linuxtips/363rbashuser.html
@ITのこの記事読んで特定のコマンドしか実行できないユーザ作ったんですが。

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

ssh foo@bar bash -i

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

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

**名無しさん＠お腹いっぱい。** · 2006/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.

**161** · 2006/07/06(木) 15:54:49

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

**名無しさん＠お腹いっぱい。** · 2006/07/06(木) 16:33:08

>>161
これってフルパスでコマンド実行できない？？

**名無しさん＠お腹いっぱい。** · 2006/07/06(木) 16:50:41

/etc/exportsの(の前にスペース入れちゃう人だからねえ

**161** · 2006/07/06(木) 16:59:06

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

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

>>165
怖っ！ｗ

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