トップページ⇒unix
1001コメント300KB

SSH その7

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2010/02/16(火) 21:23:37
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/
　Part5：http://pc11.2ch.net/test/read.cgi/unix/1145484540/
　Part6：http://pc12.2ch.net/test/read.cgi/unix/1202782840/
0291名無しさん＠お腹いっぱい。2011/01/23(日) 21:25:22
>>290
侵入された時点で物理的に電源を切る以外何をやっても無駄。
そこまで心配するならSELinuxなどを使いなよ。
0292名無しさん＠お腹いっぱい。2011/01/23(日) 21:46:08
>>290
侵入の証跡取るためにはシャットダウンもよろしくないんだよね
うちだったら緊急時は接続してるSW側でport落とすかな
(そして俺が侵入者なら無通信になったらファイル消しまくるように
仕掛けるだろうｗ)
0293名無しさん＠お腹いっぱい。2011/01/23(日) 22:49:31
>>291
> 侵入された時点で物理的に電源を切る以外何をやっても無駄。
侵入されても、rootを取られてなければ奪還の可能性はあります。
たとえrootを取られても、ログインできればシャットダウン出来る
可能性はありますが、ログインできなければその可能性は0ですよね。

>>292
> 侵入の証跡取るためにはシャットダウンもよろしくないんだよね
放置するよりはシャットダウンを選びます。踏み台にされて犯罪に
使われたりしたら面倒ですから。

> うちだったら緊急時は接続してるSW側でport落とすかな
零細なんでリモートで落とぜるSWは無理です。
0294名無しさん＠お腹いっぱい。2011/01/23(日) 23:19:09
>>290
> sshは公開鍵認証だけです。その上で侵入された場合を想定しています。

どういう状況で「その上で侵入」が可能になるのか説明plz

・サーバは遠隔地にある……これは普通
・sshは公開鍵認証のみである……brute forceで破られる心配ゼロ
・それでも、もし入られたら制御を奪われる恐れがある……????

前提がそもそも成り立ってないでしょ。
公開鍵認証使っている以上、秘密鍵が漏洩しない限りsshでの侵入はない、というのが通常の前提。
それを突破してくるｽｰﾊﾟｰﾊｶｰを相手と想定してるなら、何やっても無駄だよ。
君の力の及ぶ相手ではないからあきらめろ、としか。
0295名無しさん＠お腹いっぱい。2011/01/24(月) 00:01:01
秘密鍵まで公開してるとか鍵長4bitとか
0296名無しさん＠お腹いっぱい。2011/01/24(月) 00:05:05
> どういう状況で「その上で侵入」が可能になるのか説明plz
sshdのバグ、httpdとか他の経路。クライアントへの攻撃。
0297名無しさん＠お腹いっぱい。2011/01/24(月) 00:08:19
Debianのウンコパッチが当たった状態で作った公開鍵もヤバイんだよな。

ま、それはともかく対策が過剰な気はする。
ipfw/iptablesなどで接続元を絞るとか、別のレイヤでの対策を考えるべき。
0298名無しさん＠お腹いっぱい。2011/01/24(月) 00:36:23
接続元はtcp wrapperでjp限定に絞ってあります。
jpからの攻撃に対する対策として、maxlogins.plを使おうとしたけど、
「待てよ、ログイン出来なくされる」と思い直しての質問です。
0299名無しさん＠お腹いっぱい。2011/01/24(月) 00:38:13
>>298
tcp wrapperで逆引きを使うとか、10年前の対策だな。
0300名無しさん＠お腹いっぱい。2011/01/24(月) 00:48:41
他にjpで絞る方法ありますか?
0301名無しさん＠お腹いっぱい。2011/01/24(月) 00:50:15
パケットフィルタはpfです。
0302名無しさん＠お腹いっぱい。2011/01/24(月) 01:19:40
いい加減スレ違いじゃないか?
全然sshの話じゃなくなってるぞ
「httpdとか他の経路」ってのは何なんだよw
0303名無しさん＠お腹いっぱい。2011/01/24(月) 01:48:10
>>298
> jpからの攻撃に対する対策として、maxlogins.plを使おうとしたけど、
> 「待てよ、ログイン出来なくされる」と思い直しての質問です。

「ある特定の条件に関しては遮断を行わない」ようなスクリプトにしとけばいいだけなんじゃないの?
管理者が直近のログインに使ったIPアドレスは除外する、とか
そこまでいろんなパターン考えてるわりに他人が作ったそのまま使うの前提ってのがよく分からん
自分に都合がいいのを自分で作りなよ
0304名無しさん＠お腹いっぱい。2011/01/24(月) 01:58:37
つか途中から>>278と質問が変わっとる
brute forceの話はどこへ行った? w
OSが何かも分からんし前提条件も途中で変わるのでは話が
0305名無しさん＠お腹いっぱい。2011/01/24(月) 08:09:36
質問者が侵入されroot盗られたというわけ
0306名無しさん＠お腹いっぱい。2011/01/24(月) 09:11:29
>>303
> 「ある特定の条件に関しては遮断を行わない」ようなスクリプトにしとけばいいだけなんじゃないの?
> 管理者が直近のログインに使ったIPアドレスは除外する、とか
自分の利用条件に合う方法が思いつきません。詳細を説明するのも面倒だし、
全部を網羅できず、条件後出しになる可能性が高いので、スクリプトの改造
に関する話題は、これ以上はやめます。
加えて、メッセージの全部を偽造可能なので、それを見破るのも面倒。

>>304
sshdに対する攻撃は
1) ユーザ名を辞書攻撃で得る。
2) そのユーザ名に対してパスワードを辞書攻撃。
という手順です。
1)の段階で検出できれば、2)が(sshdの穴をついて)公開鍵認証を突破する手法に
進化した場合にも防御することが可能です。
1)の段階でsshdの穴をつつかれる可能性は残りますが、対策する方がセキュア。

まとめます
・maxlogins.plに類する、syslogdに送られる情報を元に、sshdへの攻撃を防御する
　手法は非特権ユーザがサービス停止攻撃を実行可能。
・これに代わる確立された方法は現在のところ無し。
0307名無しさん＠お腹いっぱい。2011/01/24(月) 09:31:46
>>306
syslogdにネットワークからメッセージ送れますね。(設定されてれば)
しかも(UDPなので)IPアドレスも偽造できる。
0308名無しさん＠お腹いっぱい。2011/01/24(月) 14:08:18
ipfw/iptablesからキックして、syslogを参照すれば良いだけじゃないんかい？
まあ、多少作り込みは必要だろうけどそんなに難しい事だとは思わんけど。
0309名無しさん＠お腹いっぱい。2011/01/24(月) 15:07:03
それよりも、syslogd改造してメッセージ送信元のuid取ってくるのが
手っ取り早くて確実かと思いました。(solarisでいう)

で、それをsyslog-ngに組み込もうとしたらsysutils/syslog-ng*がコ
ンパイルできねーでやんの。(事情により今すぐportsを最新版にできない)
0310名無しさん＠お腹いっぱい。2011/01/24(月) 15:09:01
> (solarisでいう)
ゴミが残りました。気にしないでください。
0311名無しさん＠お腹いっぱい。2011/01/24(月) 15:17:26
### /etc/pam.d/sshd
auth sufficient pam_unix.so nullok try_first_pass
auth sufficient pam_exec.so /sbin/log_and_deny.sh

### /sbin/log_and_deny.sh
#!/bin/sh
x=/var/run/sshd-blacklist-$PAM_USER-$PAM_RHOST
if [ -f $x ] ; then
shutdown now $x
else
touch $x
fi
exit 1
0312名無しさん＠お腹いっぱい。2011/01/24(月) 18:22:16
>>311
わろうた
0313名無しさん＠お腹いっぱい。2011/01/24(月) 18:29:21
まぁどういう方法でもいいけど、プログラム実行はCPUやディスクI/Oのコストが高いから、ヘタするとそれ自身がDoSになる可能性があるので、気をつけてな。
0314名無しさん＠お腹いっぱい。2011/01/25(火) 00:23:01
>>306
> sshdに対する攻撃は
> 1) ユーザ名を辞書攻撃で得る。
> 2) そのユーザ名に対してパスワードを辞書攻撃。
> という手順です。
> 1)の段階で検出できれば、2)が(sshdの穴をついて)公開鍵認証を突破する手法に

1)の段階ではまだ突破されてないんだからloggerでどうのこうのってのは起こらない。
そして「1)の段階で検出」は既知の方法で十分対応可能。
1)の段階で「完全に遮断」すりゃその先の話は「まず起こり得ない物語」でしかない。
「まず起こり得ない物語」のために必死に対策打つのは
「まったく価値がない」とは言わんが、ちょいと馬鹿げてないか?
傍目には「空が落ちてきたらどうしよう」って悩んでる人と変わらんように見える。

大丈夫。
「公開鍵認証を突破する手法」とやらが広まる頃には、それに対するパッチもちゃんと出てるよw
0315名無しさん＠お腹いっぱい。2011/01/25(火) 00:30:28
>>314
> 1)の段階ではまだ突破されてないんだからloggerでどうのこうのってのは起こらない。
別経路からの侵入を想定と書いた。何度も書かせないでよ。面倒だな。
0316名無しさん＠お腹いっぱい。2011/01/25(火) 01:57:00
>>315
どれがお前さんの書き込みだか他人のチャチャだか分からんよ
名前欄に何も入れてない上にこの板はIDも出ないし
続けたいならコテハンにしたら?
本来なら「もっとふさわしいスレ」に移動すべきだろうと思うけど
0317名無しさん＠お腹いっぱい。2011/01/25(火) 02:17:43
もう面倒だから
「自分のアカウントがログイン不可にされてたら問答無用でネットワーク断」
になるように設定しとけば?
手法はいろいろ考えられると思うが
0318名無しさん＠お腹いっぱい。2011/01/25(火) 23:50:18
>>317
却下です。理由は… 面倒くさいから上の方読んで。
0319名無しさん＠お腹いっぱい。2011/01/26(水) 18:08:54
鍵認証のみで十分じゃん
0320名無しさん＠お腹いっぱい。2011/01/26(水) 18:18:28
> maxlogins.plのようにsyslogを読む方法はローカルなユーザがlogger使って
> 悪戯できるので、イヤです。

侵入者にルート権限を奪われていない状況で、これって本当に可能なんでしょうか?
管理者のユーザ名も使用しているIPアドレスも分からない状態ですよね?
もちろん「無差別に全部塞ぐ」は簡単だけど自力では「開け直す」ができないんだから
意味がないような気がするし。
0321名無しさん＠お腹いっぱい。2011/01/26(水) 18:19:34
それ以前に、踏み台等にすることを考えて侵入した場合
侵入していることが管理者に気づかれないようにするのが普通だと思うのだけど。

管理者を締め出すようなことしたら普通はすぐに対策取られちゃいますよね。
直接コンソール操作して。
苦労して侵入したのに、明かに「侵入してますよ〜」って言いふらすような
馬鹿なことをわざわざするかな。
0322名無しさん＠お腹いっぱい。2011/01/26(水) 20:06:18
>>318
で、結局のところどうするんだ？これでもまだ「自分の望む答えが出てない」と言うなら、
おそらく自分で方向性決められないので素直に鍵認証にしとけ。
0323名無しさん＠お腹いっぱい。2011/01/26(水) 20:43:24
>>320-321
他ユーザのログイン記録の管理は普通ルーズですよ。lastなどでわかる場合が多い。
maxlogins.plはホスト毎にアクセス制御なので、ユーザ名は不要ですね。

>>322
面倒だから上の方読んで。
0324名無しさん＠お腹いっぱい。2011/01/26(水) 21:40:13
>>322
やっぱりキミ頭弱いそうだから説明してあげる。
>>309(syslogd改造)が現在の結論。
0325名無しさん＠お腹いっぱい。2011/01/26(水) 22:04:55
>>324
全然結論になってないんだけど(笑)。
したり顔で言われたくないなぁ、馬鹿には。
0326名無しさん＠お腹いっぱい。2011/01/26(水) 22:46:45
>>325
完璧になってるよ。

syslogdでメッセージ投げてきたプログラムのuidを取得すれば、
sshd(root)とlogger(非特権ユーザ)が区別できるので悪戯されない。
0327名無しさん＠お腹いっぱい。2011/01/26(水) 23:07:30
ローカルユーザのいたずら対策と、外部のアタッカーからの対策がごっちゃになってるのが悪い。
・不要なサービスを立ち上げない、提供するホストを分ける
・不要なユーザを受け入れない
・二要素認証と承認の仕組み
などの基本から考え直せ。
0328名無しさん＠お腹いっぱい。2011/01/26(水) 23:18:36
>>327
そう思うのは頭が弱いキミだけだよ。syslogd改造で完了だよ。
どんなに間抜けな事言ってるか教えてあげる。

> ・不要なサービスを立ち上げない、提供するホストを分ける
sshdとhttpd提供するホストを分けたら、httpdのホストはどうやって
保守するのでしょうか?

> ・不要なユーザを受け入れない
だからmaxlogins.plのような仕組みが必要。でもsyslogdが今のままではダメ。

> ・二要素認証と承認の仕組み
ハードウエアトークン使った秘密鍵認証ですが、何か?
0329名無しさん＠お腹いっぱい。2011/01/26(水) 23:31:23
httpdの保守ならiptablesで1ホスト・1ユーザに絞ればいいじゃん
CMS使えば他のユーザをシェルまでログインさせる必要もない

あれもこれもいいとこ取りしようとして、要件が発散してるのがそもそもの問題ｗ
0330名無しさん＠お腹いっぱい。2011/01/26(水) 23:33:51
役所とか大学とかにありがち。
0331名無しさん＠お腹いっぱい。2011/01/26(水) 23:47:33
>>293
> 零細なんでリモートで落とぜるSWは無理です。
って言ってたのに、

>>328
>ハードウエアトークン使った秘密鍵認証ですが、何か?
こんな金のかかるもの導入してる。

ほんとに同じ人？
0332名無しさん＠お腹いっぱい。2011/01/26(水) 23:50:09
>>331
途中から変なのが参戦してるね。
syslogdなんて亜種がいくらでもあるし、syslogdが問題だと思うなら
余所の適切なスレへ移動して欲しい。
0333名無しさん＠お腹いっぱい。2011/01/27(木) 00:03:46
>>331
OpenPGPカードだから安いよ、15ユーロくらいだったかな。
amazonの安売りの1000円カードリーダーだし。
0334名無しさん＠お腹いっぱい。2011/01/27(木) 00:22:39
>>329
偉そうに分離しろとか言って、httpdとsshdは分離できないんじゃん。
0335名無しさん＠お腹いっぱい。2011/01/27(木) 00:32:15
>>334
daemonとしての「サービス」は複数動かさざるを得ないが、
ユーザに提供する「サービス」はhttpdとsshd両方提供する必要は無い
必要が無いソースホスト・ユーザからは到達させないようにするのはセキュリティの基本中の基本
0336名無しさん＠お腹いっぱい。2011/01/27(木) 00:43:55
おまえら、もう釣りにマジレスやめれ。
2,3万からのインテリスイッチすら買えないのに、ハードウェアトークンなんて面倒なものいれる零細企業がどこにあるんだよ。
脳内零細企業の管理者様はセキュリティ板にでもお帰りいただけばおｋ。
0337名無しさん＠お腹いっぱい。2011/01/27(木) 01:27:53
・他サービスのセキュリティには無頓着なのにSSHまわりのDoSには異常にこだわる
・侵入されないことより、侵入後の対策が重要
・syslog改造すると表明したのにいつまでSSHスレに居座るの？
・他人の提案は何でも却下

ま、釣りじゃなければ精神異常だ罠
0338名無しさん＠お腹いっぱい。2011/01/27(木) 01:34:41
>>335
sshdとhttpdが同一ホストで動かしているという前提しか提示してない
(それでどんなサービスを提供しているかは提示していない)のに
余計な憶測で
> ・不要なサービスを立ち上げない、提供するホストを分ける
と、間抜けなアドバイスしたって事だね。

>>336
外からログインさせるためにはハードウェアトークンは必須。
OpenPGPカードは(カード(15ユーロ)+リーダー(1000円))/1名
ランニングコスト0。全然面倒じゃない。
安定して購入できるかという問題はあるけど、零細はフットワー
ク軽くて小回り効くから、ディスコンになったら考えればいい。

インテリスイッチは無けりゃ無くて済む。
そのわりに設置場所やランニングコストもかかる。

全然矛盾しないんだなあ。
0339名無しさん＠お腹いっぱい。2011/01/27(木) 01:59:17
>>337
> ・他サービスのセキュリティには無頓着なのにSSHまわりのDoSには異常にこだわる
他サービスに関してはここでは話題にしていないだけ。

> ・侵入されないことより、侵入後の対策が重要
侵入されない事に関しては、ユーザー名総当たり攻撃に対する防御が残っている。
これ以外は対策済み。

> ・syslog改造すると表明したのにいつまでSSHスレに居座るの？
.jp以外を拒否する方法として、tcp wrapperが古いというので、
代わる方法を聞いたけど、まだ答えがない。
あと、>>311は、釣りだったけど、PAMを使うというのは新鮮なアイデアだった。
そういうのが出てくるかもしれない。

> ・他人の提案は何でも却下
接続元限定しろ、パスワード認証やめろ、二要素認証しろ、とか
聞いてもいない、しかも対策済みの提案と、上の方のレス読まずに
書きなぐったまぬけな提案しか出てこねーんだもん。
0340名無しさん＠お腹いっぱい。2011/01/27(木) 06:58:45
あー今日も大漁大漁♪
0341名無しさん＠お腹いっぱい。2011/01/27(木) 10:03:20
sshd止めてシリアルからログインすればいいべ。
メンテするときはシリアルポートに繋いだモデムに電話掛ければOK。
0342名無しさん＠お腹いっぱい。2011/01/28(金) 04:50:40
>>341
WarGamesを思い出した。
0343名無しさん＠お腹いっぱい。2011/01/28(金) 12:34:44
>>339
> 上の方のレス読まずに

だから、どれがお前の書き込みだか
他の人には分かんねーんだっつーのw
ここにいるのが全員エスパーだと思ってんのか?
なんでコテハンにしないんだよ




釣られちまった
0344名無しさん＠お腹いっぱい。2011/01/28(金) 12:46:01
>>343
そういうお前は誰なんだよ。
0345名無しさん＠お腹いっぱい。2011/01/28(金) 12:50:26
>>343
その理屈なら、
> ・他人の提案は何でも却下
却下したのも誰だか判らないじゃないか。ｗ
0346名無しさん＠お腹いっぱい。2011/01/28(金) 14:06:56
>>342
古いね〜
0347名無しさん＠お腹いっぱい。2011/01/28(金) 14:10:03
war dialerでやられる。
0348名無しさん＠お腹いっぱい。2011/01/28(金) 17:28:01
>>347
管理者じゃない番号からの着信はPBXで止めろよ。
0349名無しさん＠お腹いっぱい。2011/01/28(金) 21:00:29
オレオレ
0350名無しさん＠お腹いっぱい。2011/01/29(土) 10:40:26
>>344-345
問題になってるのは「どれが質問者の発言か分からない」という話だろ
「他人」は何人いようと問題じゃない
他人のツッコミや推測の書き込みと質問者の答えの区別がつかんから
「前に書いた」と言われてもどれのことだか分からん訳で

2ちゃんでは話題が継続してる間は最初の質問の番号を名前欄に入れる
のが一般的だと思うんだが質問者はそういうルールを知らんのか
あるいは質問者は>>278だけで後はなりすましの他人による釣り行為だったのかw
0351名無しさん＠お腹いっぱい。2011/01/29(土) 10:49:12
もうこの話やめようよ。
0352名無しさん＠お腹いっぱい。2011/01/29(土) 11:59:25
>>350
>>337は、(質問者が)「他人の提案をなんでも却下」したと言っている、
却下したのが他人の突っ込みでないこと、すなわち元質問者であるとわ
かっている。
わからないお前がバカなんじゃない?
0353名無しさん＠お腹いっぱい。2011/01/29(土) 12:00:00
openssh 5.7リリースの話題から目をそらそうとする陰謀としか思えんな
どういう目的があるのかはわからんが
0354名無しさん＠お腹いっぱい。2011/01/29(土) 19:54:45
>>352
とりあえず見てて不快だからこの話題やめようぜ
0355名無しさん＠お腹いっぱい。2011/01/29(土) 22:01:49
やり込めようと向かってこなきゃいいんじゃないかな。頭足りないんだから。
0356名無しさん＠お腹いっぱい。2011/01/30(日) 00:11:27
>>352
そのレス以前の文脈無視すんなよw
0357名無しさん＠お腹いっぱい。2011/01/30(日) 14:29:00
>>356
誰が書いたかわからないのに文脈もクソもないだろ。
0358名無しさん＠お腹いっぱい。2011/01/31(月) 11:39:19
>>353
とりあえず家のSolaris鯖のは既に入れ替えてみてある。
ぱっと見、session.cのコードが結構変わってた。
0359名無しさん＠お腹いっぱい。2011/02/01(火) 18:44:56
>>358
よくわかってないんだけどECDSA って美味しい?
試しにssh-keygen -t ecdsa したら規定値256bit なんだけどこれで問題ないのかな?
-3 は面白そう
0360名無しさん＠お腹いっぱい。2011/02/02(水) 10:06:03
楕円暗号だから256bitもあれば
RSA2048bit よりは強度はだいぶ上じゃないかな
0361名無しさん＠お腹いっぱい。2011/02/02(水) 10:14:40
> scp(1): 新しい -3 オプションを追加.

これ壁というかGW上のホストでの作業に
めちゃめちゃ便利そう

いままでなかったのが不思議なくらい
(いちいち ssh utigawa tar cf - | ssh sotogawa tar xpf - とかしてた)

はやく FreeBSD のツリーに取り込まれないかな…
0362名無しさん＠お腹いっぱい。2011/02/02(水) 10:19:27
もう一つ openssh 5.7関係の話から(openssh とは直接は関係ないんだけど…)
> sftp(1): sftp クライアントは非常に早くなった.

WinSCP による転送が異常に遅い問題って
この辺の話と関係あるんでしょうかね。
0363名無しさん＠お腹いっぱい。2011/02/02(水) 15:03:40
* sftp(1): the sftp client is now significantly faster at performing
directory listings,
これ？ ディレクトリ一覧取得って書いてあるけど。
0364名無しさん＠お腹いっぱい。2011/02/02(水) 15:24:48
>363
あちゃ… たしかに原文はそうなってるね。
日本語訳しか読んでなかった… orz
0365名無しさん＠お腹いっぱい。2011/02/02(水) 20:53:32
>>360
トン
RSA に比べると大分bit 数が少なかったので少し不安でした
とりあえず256bit で運用してみます
0366名無しさん＠お腹いっぱい。2011/02/04(金) 13:01:42
5.8
http://www.openssh.org/txt/release-5.8
http://www.unixuser.org/~haruyama/security/openssh/henkouten/henkouten_5.8.txt
0367名無しさん＠お腹いっぱい。2011/02/04(金) 23:35:36
この前5.7出たばっかなのにもう5.8か
0368名無しさん＠お腹いっぱい。2011/02/09(水) 07:24:56
PAMって具体的にどういう利点があるのですか？
0369名無しさん＠お腹いっぱい。2011/02/09(水) 21:43:26
>>368
認証プロセスをアプリ毎に実装する必要がない。
認証方法を変更する場合、ユーザー側の作業だけですみ、アプリに変更を加える必要がない。
0370名無しさん＠お腹いっぱい。2011/02/23(水) 00:31:11.34
MidpSSHでOpenSSHのsshdへ接続するにはsshd_configに最低でも
Ciphers 3des-cbc
としておかないと駄目らしい。
なんとか接続できたので快適ｗ
0371名無しさん＠お腹いっぱい。2011/02/28(月) 10:39:20.71
ssh-keygen コマンドで作成される公開鍵、秘密鍵にはユーザ名は含まれているのでしょうか?

◯前置き：
自分のPC(Windows)には taro というアカウント名でログオンしていて、cygwin を使っている。
家庭内LAN上の別のマシンの Linux 上に taro というアカウントを作った。
cygwin の openssh で ssh-keygen で作成した公開鍵を Linux に送り、cygwin の ssh から
鍵認証でログインすることが出来ている。

◯問題：
sourceforge.jp にアカウントを作った。このときのアカウントは hoge とする。
hoge 用に公開鍵と秘密鍵のペアを作るのが面倒だったので、↑でつくった taro 用の公開鍵を
sourceforge.jp に登録し、cygwin から

$ ssh -i .ssh/id_rsa -l hoge shell.sourceforge.jp

というようにやっているのだけど、10時間たっても
Permission denied (publickey).
というエラーが出てログインできない。
0372名無しさん＠お腹いっぱい。2011/02/28(月) 11:34:25.20
ユーザ名は含まれていない。
sshに-v付けて調べる。
03733712011/02/28(月) 12:08:14.03
>>372 レスどうもありがとうございます。 こんな感じになりました。

$ ssh -v -i .ssh/id_rsa -l hoge shell.sourceforge.jp
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /home/taro/.ssh/config
debug1: Connecting to shell.sourceforge.jp [202.221.179.26] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
(続く)
03743712011/02/28(月) 12:08:30.45
(続き)
debug1: Host 'shell.sourceforge.jp' is known and matches the RSA host key.
debug1: Found key in /home/taro/.ssh/known_hosts:43
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
0375名無しさん＠お腹いっぱい。2011/02/28(月) 12:51:57.78
pubkeyのオファーはしてるけど、サーバ側で拒否してる。
サーバーに転送した公開鍵がおかしい(行末?)とか、ディレクトリが違うとか、
パーミッションがおかしいとか。
0376名無しさん＠お腹いっぱい。2011/02/28(月) 12:52:50.37
サーバの.sshがworldライタブルとか
03773712011/02/28(月) 13:10:15.94
レスどうもありがとうございます。
sourceforge.jp の場合、下記のように、
ブラウザに、自分のPCで作成した公開鍵を貼り付けるようになっているので、
http://sourceforge.jp/projects/docs/wiki/SSH%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%AD%E3%83%BC
ディレクトリが違うとかパーミッションがおかしいということはないと思います
(sourceforge.jp の CGI が間違ってない限り)

ちなみに「サーバ側で拒否している」とは、>>373-374 のどこでわかるのでしょうか?
また、「鍵が合ってないよ」とは違う状況をサーバはおうとしているのでしょうか?
0378名無しさん＠お腹いっぱい。2011/02/28(月) 13:28:46.78
> ブラウザに、自分のPCで作成した公開鍵を貼り付けるようになっているので、
ありがちなミスでコピペしたときに途中に改行が入ってるんじゃない?
公開鍵は一行だぞ。

> debug1: Authentications that can continue: publickey
(あんたの送った公開鍵は却下)次の公開鍵送れ。
03793712011/02/28(月) 15:04:24.35
すみません、原因がわかりました。
sourceforge.jp では、アカウント申請しただけではシェルサーバに
ログインできず、何らかのプロジェクトに属さないとダメなようです。

申し訳ありません、お騒がせしました。

>>378
レスどうもありがとうございます。
ssh -v でデバッグする方法は今回で知ったので、今後に役立たせていただきます。
0380名無しさん＠お腹いっぱい。2011/03/26(土) 01:13:04.19
metosrv9.umd.eduがSSH舐めて歩いてる
0381名無しさん＠お腹いっぱい。2011/03/27(日) 01:59:12.03
公開鍵認証の接続だけを許す設定で、>>373-374と同じ問題に悩んでいる。
Mac1, Mac2, Debian Stableがあり、Mac2 と Debianは同じネットワーク。
最初、Mac1からDebにはsshで入れたが、Mac2からDebには Permission denied (publickey) のエラーで接続できなかった。
Mac1とMac2は同じ構成なので、これは不可思議だった。
Debのauthorized_keysやid_rsaのパーミッションをread onlyにするなどの変更をしたが、そうこうするうちに、
Mac1からもDebに入れなくなっていた。
Debのsshd_configを開いたときに知らずに変更してしまったのか。手がかりが分からず困ってる。
0382名無しさん＠お腹いっぱい。2011/03/27(日) 02:16:24.71
間違えたので訂正。

公開鍵認証の接続だけを許す設定で、>>373-374と同じ問題に悩んでいる。
Mac1, Mac2, Debian Stableがあり、Mac2 と Debianは同じネットワーク。
最初、Mac1からMac2にはsshで入れたが、DebからMac2には Permission denied (publickey) のエラーで接続できなかった。
Debのauthorized_keysやid_rsaのパーミッションをread onlyにするなどの変更をしたが、そうこうするうちに、
今度はMac1とMac2の両方からDebに入れなくなっていた。
Debのsshd_configを開いたときに知らずに変更してしまったのか。手がかりが分からず困ってる。
0383名無しさん＠お腹いっぱい。2011/03/27(日) 09:08:23.01
どうみても別問題です
Mac側ユーザでls -la ~/.sshした結果でも貼ってみれば？
03843822011/03/27(日) 11:20:30.38
>>383 やはりそうですかねえ。それではMac1側のを一応貼ります。
-rw------- 1 me staff 1217 Feb 11 21:26 authorized_keys
-rw------- 1 me staff 1743 Jan 1 12:28 id_rsa
-rw-r--r--@ 1 me staff 393 Feb 11 21:24 id_rsa.debian.pub
-rw------- 1 me staff 418 Jan 1 13:07 id_rsa.pub
-rw-r--r-- 1 me staff 14756 Mar 13 11:53 known_hosts

上記のうち、Debのpublic keyを
-r--------@ 1 me staff 393 Feb 11 21:24 id_rsa.debian.pub
にしても変わりません。
0385名無しさん＠お腹いっぱい。2011/03/27(日) 13:26:38.84
何言ってるのかちょっとわからない
Mac1はログインする側でDebがされる側？
まさかだけど鍵穴に鍵穴を突っ込もうと奮闘してるとか？
0386名無しさん＠お腹いっぱい。2011/03/27(日) 13:48:31.92
ここと、

＞Mac1からMac2に
＞DebからMac2に

ここで、

＞今度はMac1とMac2の両方からDebに

ログインの方向が変わってるぞ。鍵穴に鍵穴を突っ込もうとしてるか、鍵を鍵に突っ込もうとしてるのどちらか。
0387名無しさん＠お腹いっぱい。2011/03/27(日) 15:02:42.89
pubkeyオンリーの運用が難しいなどと抜かす池沼はサーバの運用するな。
0388名無しさん＠お腹いっぱい。2011/03/27(日) 23:17:45.54
>>385
なんか百合っぽい
0389名無しさん＠お腹いっぱい。2011/03/28(月) 06:06:44.71
藤原一宏教授の虚偽申請は、日本の数学界に対する国民の信頼を裏切った、
無視することのできない重大な事件です。このような者がのうのうと責任ある教授職を
続けていることに、藤原氏がプロの学者であることを自覚しているのなら
なおさら疑問をかんじざるを得ません。今後二度とこのような事件が起きないように
するためにみなさんで建設的な議論をしましょう。
03903822011/03/28(月) 10:56:35.78
>>386
ログインの方向が変わっているのはその通りです。
３つのマシンがsshdを動かしていて、それぞれ公開鍵を発行して相互にログインできてました。

いま困っているのは
＞今度はMac1とMac2の両方からDebに
が出来ない事ですが、
別の事象として、DebからMac2にアクセスするときにも同じエラーが起きていたということです。
■ このスレッドは過去ログ倉庫に格納されています