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
普通に「エスエスエイチ」でいいんじゃない？
URLﾘﾝｸ(ja.wikipedia.org)
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のみで使われる。
内容が同じなのか、また両者を１つの項目に統合してしまっても問題ないのかまで
は分からない。（※個人的には、何らかの理由があって分けたのではないかと思っ
ているけど。）
193:名無しさん＠お腹いっぱい。
06/07/14 17:15:35
クライアントの公開鍵じゃなくて、クライアントで動いているsshdの公開鍵。
だからsshdの秘密鍵にアクセスできる必要がある。
RhostsRSAAuthenticationとHostbasedAuthenticationはssh1とssh2のそれぞれで
設定が可能になっている。
でも、今どきはssh1は普通無効なのでRhostsRSAAuthenticationは使わない。
194:191
06/07/14 17:28:48
あ、そうか
「ホスト」単位で認証するんだから、クライアントのホスト鍵＝sshdの公開鍵＝/etc/ssd/ssh_***.pubっすね
ありがとうございますた
195:191
06/07/14 22:36:26
何度もすいません。追加質問お願いします。家のマシンでテストしていたんですが
Hostbased認証にはssh-keysignをsetuidする必要があるそうですが、setuidしてないのにログインできるマシンがあります。
よく見ると「Have a lot of fun...」の直後に「Agent pid 566」とか出て、ssh-agentが走っているようです。
ssh-agentって公開鍵認証（sshd_configでPubkeyAuthentication yes)で使うものですよね？
なぜこれが起動するんでしょうか？
他のマシンでは正常にホストベース認証でログインできました（もちろんssh-keysignにsetuidを立てないとエラー）
ちなみに問題のマシンのsshバージョんはOpenSSH_3.7.1p2,です
196:名無しさん＠お腹いっぱい。
06/07/16 03:18:40
ssh-agentが起動するのはシェルのスタートアップファイルがそのように書いてあるから。
197:名無しさん＠お腹いっぱい。
06/07/16 05:39:18
ホストで認証するのは危険ですか？
198:名無しさん＠お腹いっぱい。
06/07/16 20:16:45
>>197
いいえ、それはトムです。
199:195
06/07/17 16:04:58
>>196
ほんとだアホすぎる・・・orz
thxです
200:名無しさん＠お腹いっぱい。
06/07/22 18:21:43
RSAAuthentication と RhostsRSAAuthentication の違いを教えてください。manだと、
RSAAuthentication・・・RSA認証
RhostsRSAAuthentication ・・・RSA ホスト認証を使った Rhosts ベースの認証
のようですが、つまり後者は前者のRSA認証にrhosts、shostsファイルによる認証を加えたもの、ということですか？
201:名無しさん＠お腹いっぱい。
06/07/22 19:57:12
>>200
10 レス前も読まないのか
202:名無しさん＠お腹いっぱい。
06/07/22 19:58:20
>>200
違ったねごめんね
203:名無しさん＠お腹いっぱい。
06/07/23 10:03:49
最近中国とか台湾とか韓国方面からの ssh password アタックが多いので…
同じIP address から短時間に 10回以上
アクセスがあったら(login error 回数だと尚良い)
そのアドレスにたいしては sshd を1時間 shutout する、
なんていう設定ができないかと思っているんですが
sshd の機能だけでは出来ないんですよね?
似たような話でも良いのですが、なにか方法はあるのでしょうか?
環境: OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1
(できれば公開鍵 only ではなく password 認証は生かしておきたいです)
204:名無しさん＠お腹いっぱい。
06/07/23 10:49:25
>>203
普通に、ssh接続する接続元のIP以外はFWではじくのがベスト。
でなければ、中国とか台湾とか韓国のIPを根刮ぎDeny汁
205:名無しさん＠お腹いっぱい。
06/07/23 12:24:22
URLﾘﾝｸ(www.itmedia.co.jp)
URLﾘﾝｸ(www.bsp.brain.riken.jp)
URLﾘﾝｸ(yoosee.net)
このへんを参考に。
206:名無しさん＠お腹いっぱい。
06/07/23 16:21:03
>205
thx. MaxStartups の 3:30:20 みたいな表記がほぼズバリでした
>204
出張その他でいろいろな所から接続するので接続元は特定できないのと、
家族のアカウントのことは証明書ベースにするのはちょっと
面倒だったんで...
まあ CKT 方面は ssh に関しては deny したいところですけどね...
207:名無しさん＠お腹いっぱい。
06/07/23 19:41:13
>>203＝>>206
sshdを別のポート番号で動かすのが手っ取り早いんじゃないかと思う。
そのマシンにログインする人全員にそのことを知らせる必要があるけれども。
# >>205の３つめのwebページからもリンクされている、
# URLﾘﾝｸ(www.unixuser.org)
# を参照ってことで
208:153
06/07/23 19:50:55
>>153
> [1] 入門OpenSSH
> URLﾘﾝｸ(www.shuwasystem.co.jp)
>
> キタァ！ ヽ(ﾟ∀ﾟ)ノ ヽ(ﾟ∀ﾟ)ノ ヽ(ﾟ∀ﾟ)ノ ヽ(ﾟ∀ﾟ)ノ
某大学の図書館に入った ヽ(ﾟ∀ﾟ)ノ ので、さっそく借りてきた。
# [3]は、リクエストしたのになんだかんだ言って入らないまま時間が過ぎてついに
# 絶版になっちまってｺﾝﾁｸｼｮｰだったので、よかったYO
以上、チラシの裏ｗ
>>158
> [3]は持ってるんだけど、
> [1]はその改訂版なの？
> あと対応バージョンはいくつなんだろう
[1]では4.3を対象として書かれているようですね。
209:200
06/07/24 12:16:45
何か勘違いしてますね自分・・・↓を見たのですが
URLﾘﾝｸ(www.unixuser.org)
RSAAuthenticationは「純粋なRSA認証」とありますが、これはいわゆるパスワード認証のことですか？
通信の通路はRSAで暗号化するのだから、パスワード認証もホストベース認証もみんなRSAは使ってるわけですよね？
ss1の話で今更あまり意味ないかもしれませんが、いちおう理解しておきたくて・・・
210:名無しさん＠お腹いっぱい。
06/07/24 17:13:15
>>209
> RSAAuthenticationは「純粋なRSA認証」とありますが、これはいわゆるパスワ
> ード認証のことですか？
違 い ま す ！
SSHプロトコル1.xでの公開鍵認証、です。RSAを使うんで、「RSA認証」と呼ばれて
いるわけだ。
sshd_configでの設定項目：
公開鍵認証：RSAAuthentication（1.x），PubkeyAuthentication（2.0）
パスワード認証：PasswordAuthentication（1.x,2.0共通）
211:名無しさん＠お腹いっぱい。
06/07/24 18:10:04
>通信の通路はRSAで暗号化するのだから、
いや通信経路は RSA 使わないよ?
経路の暗号化は共通鍵方式。
いろいろとキホンを勉強してから個別資料のほうがいいと思うぞ
212:209
06/07/25 03:59:39
>>210
公開鍵認証だったんですかー！ありがとうございました。
でもどっちも公開鍵認証なんなら
RSAAuthentication→PubkeyAuthentication1
PubkeyAuthentication→PubkeyAuthentication2
みたいにしてくれれば分かりやすいのに。"RSAを使ったAuthentication"は他にもいろいろあるのだし・・・
歴史の流れでそうなってるってことでしょうかね？
>>211
通信コストを下げるために公開鍵暗号は最初の認証のみで、後は共通鍵みたいですね。知らなかった
でも、使う共通鍵はホストとクライアントどちらのものなんでしょうか？
213:名無しさん＠お腹いっぱい。
06/07/25 06:16:42
sshでサーバに繋ぐときに、GlobalKnownHostsFile(/etc/ssh/ssh_known_hosts)で
許可していないホストを、勝手にユーザの~/.ssh/known_hostsにそのホスト認証鍵を
追加させたくないのですが、どうすればいいでしょうか。
とりあえず、/etc/ssh/ssh_configに
StrictHostKeyChecking yes
としておけば、未知のホストに接続した場合のfingerprintを聞いてこないので、抑止
にはなるかと思うのですが、ユーザが
% ssh -o StrictHostKeyChecking=no remote-address
とした場合、ssh_configの設定が上書きされるので、どうしたものかと思っています。
何か良い方法がありますでしょうか。
sshd_configの場合、IgnoreUserKnownHostsオプションがあるので良いのですが。。。
環境は、FreeBSD 5.3R OpenSSH_3.8.1p1です。
214:名無しさん＠お腹いっぱい。
06/07/25 10:14:08
>>213
なんでそんなことしたいんだろう。
ファイアウォールで閉じるとかじゃだめなん?
215:名無しさん＠お腹いっぱい。
06/07/25 10:52:24
理由はわからないが、ソースが公開されているのだから、修正して
そのオプションを削れば済むこと。
216:名無しさん＠お腹いっぱい。
06/07/25 10:53:21
~/.ssh/known_hosts をルート所有のリードオンリーにする。
217:名無しさん＠お腹いっぱい。
06/07/25 10:58:11
>>216
それじゃファイル消して新しく作られて終わりじゃね?
218:名無しさん＠お腹いっぱい。
06/07/25 11:12:53
>>215
自力でコンパイルされたら終わりじゃね?
219:名無しさん＠お腹いっぱい。
06/07/25 11:27:05
結局ファイアヲールで防ぐしかないんじゃね？
220:213
06/07/25 12:41:59
>>214-219
サンクス。
ファイアウォールで制限する事にしました。妙な方向に考えていたようです。
そもそもの理由は、sshのクライアントとサーバ間でホスト認証＆相互認証を
しようとして、sshd側は、クライアントのホスト公開鍵を/etc/ssh/ssh_known_hostsに
設定し、sshd_configのIgnoreUserKnownHosts,IgnoreRhostsの設定でユーザが故意・事故で
~/.ssh/に変なクライアントからの接続の許可を無視できればＯＫと考えた。
でも、ssh側は、/etc/ssh/ssh_known_hostsにサーバのホスト公開鍵を設定しても、
ユーザの設定（コマンドラインの-o指定や~/.ssh/config）で上書きされてしまったら、
意味がないかな？と思っていた次第です。
（たとえば、鍵指紋を何も考えずにEnter押すようなユーザや、サーバホスト鍵が変更されてる
というワーニングがでたら~/.ssh/known_hostsの該当部分を削除してしまうようなユーザを制限
できたらと考えていたのですが。）
>>216
ちなみに該当ファイルをReadOnlyにしても接続時に「ファイルに書き込むのに失敗した」という
旨のエラーがでるだけで接続自体は行うようです。
221:206
06/07/25 15:30:42
>206 のように書きましたが、AllowUsers で
login できるアカウントを制限していたためか
root やら admin やらでアタックを試しているうちは
"login の認証失敗" まで行かないことになって
MaxStartups の縛りが全然発動しないっぽいです… orz
だだだーとアカウントスキャンをかけてくる台・韓の
script kiddy のせいで /var/log/authlog がすげーバッチイまんまですた
(アドレス毎に 10-20行位で収まるようになるのかと思ったのに)
>207
確かに出張時に使う(接続元アドレスバラバラ)、のは私だけなので
port 22 は特定アドレスからの接続だけに限定して
一般の接続用としてはそれもアリかもしれないですね。
222:名無しさん＠お腹いっぱい。
06/07/26 21:24:46
sshポートフォワーディングを用いてftpを使いたいのですが、
ffftpで「接続しました。 接続できません。」となってしまいます。
・sshによるパスワード認証ログイン、通常のftpによるログインは可能
・PuTTY0.58-jp20050503でトンネル部分を設定
→L8021 ********.jp:21(左が源ポート、右が送り先）
・ffftpはポート8021、接続先localhost、PASV、FWなしに設定
・サーバはSolaris10、クライアントはWin。
・OpenSSH（Solaris10バンドル）使用。
→Sun_SSH_1.1、SSH プロトコル 1.5/2.0、OpenSSL
・URLﾘﾝｸ(cl.pocari.org)を見て、
AllowTcpForwarding yesにしてみました。
アドバイスあれば、よろしくお願いいたします。
223:名無しさん＠お腹いっぱい。
06/07/26 22:19:25
出来たら感動ものである
224:名無しさん＠お腹いっぱい。
06/07/26 22:25:28
ぐぐればすぐに
225:名無しさん＠お腹いっぱい。
06/07/27 17:42:20
RMSを見ならって~を777にしたらログインできなくなりますた。
どうしたらいいですか。
226:名無しさん＠お腹いっぱい。
06/07/27 18:18:27
RMSを見習って気に入らない動作はすぐに修整しましょう。
227:名無しさん＠お腹いっぱい。
06/07/27 23:38:47
hurd だとどうなるんでしょ :-)
228:名無しさん＠お腹いっぱい。
06/07/31 22:42:07
winscpでwin→linuxへファイルを送るとき、送り終わった後に「ファイル・フォルダ '4>2↑?' はありません」といちいちプロンプトが出ます。
ファイルのパスに日本語が含まれるときに出るようですが、これを回避する方法ないですか？
ｽﾚ違いな気もしますが同じssh系ということで、お願いします
229:名無しさん＠お腹いっぱい。
06/07/31 23:01:19
スレ違いなら回答するけど板違いなのでどっか行け。
230:228
06/07/31 23:48:21
win板の質問スレだとごちゃごちゃしてるし、winscp使ってる人の割合も少ないと思ったもので
即レスするくらいなら答えてくれてもいいのに…
231:名無しさん＠お腹いっぱい。
06/08/01 00:12:21
回避する方法はある。
これでいいか?
232:名無しさん＠お腹いっぱい。
06/08/01 07:29:56
パスに日本語が含まれないようにすればいい。
それか、comannderモードつかってexplorerとかからドロップしない。
233:228
06/08/01 13:06:59
>>232
レスｊどうもです
デスクトップとかからのドラッグドロップをよくやるもんで
いろいろ試しましたが、やはり無理なようですね。この件は諦めることにします
234:名無しさん＠お腹いっぱい。
06/08/06 14:14:41
PuttyだとつながるのにPoderosaだとつながらない、という現象が起きて困っています
どなたか解決策お願いします
以下、Poderosaの出力ログです（プロトコルはSSH2、認証方法は「パスワード」です）
[SSH:192.168.123.162] Received: SSH-2.0-OpenSSH_4.2
[SSH:192.168.123.162] Transmitted: SSH-2.0-Granados-2.0
[SSH:192.168.123.162] Transmitted: kex_algorithm=diffie-hellman-group1-sha1; server_host_key_algorithms=ssh-dss,ssh-rsa; encryption_algorithms_client_to_server=aes128-cbc,blowfish-cbc,3des-cbc;
encryption_algorithms_server_to_client=aes128-cbc,blowfish-cbc,3des-cbc; mac_algorithms_client_to_server=hmac-sha1; mac_algorithms_server_to_client=hmac-sha1
[SSH:192.168.123.162] Received: kex_algorithm=diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1; server_host_key_algorithms=ssh-rsa,ssh-dss;
encryption_algorithms_client_to_server=aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr;
encryption_algorithms_server_to_client=aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr;
mac_algorithms_client_to_server=hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96; mac_algorithms_server_to_client=hmac-md5,hmac-sha1,hmac-ripemd160,
hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96; comression_algorithms_client_to_server=none,zlib@openssh.com; comression_algorithms_server_to_client=none,zlib@openssh.com
[SSH:192.168.123.162] Transmitted:
[SSH:192.168.123.162] Received: verifying host key
[SSH:192.168.123.162] Received: the keys are refreshed
[SSH:192.168.123.162] Transmitted: ssh-userauth
[SSH:192.168.123.162] Transmitted: starting password authentication
[SSH:192.168.123.162] Received: user authentication failed:publickey,keyboard-interactive
235:名無しさん＠お腹いっぱい。
06/08/06 14:16:56
失礼、あげておきます
236:名無しさん＠お腹いっぱい。
06/08/06 14:35:41
元 Vera 使いだけど、キーボードインタラクティブの有効無効とか無いの？
237:名無しさん＠お腹いっぱい。
06/08/06 14:48:32
KeyboardInteractiveも可能なのですがPassword入力後無反応になってしまいます
（イベントログもpassword入力後出力無し）
なんか情報小出しですみません
238:名無しさん＠お腹いっぱい。
06/08/06 14:59:40
板違いだと思うんだが。
239:名無しさん＠お腹いっぱい。
06/08/06 17:20:34
SSH の問題ならここでもいいと思うけどよくわからんな
一応貼っとくか
Poderosa使ってる奴いる？
ｽﾚﾘﾝｸ(mysv板)
240:名無しさん＠お腹いっぱい。
06/08/07 14:49:47
keyboard-interactive認証とpassword認証の違いって何ですか？
ググったら↓を見つけましたが、これで合ってるんですか？
URLﾘﾝｸ(www.ss.ics.tut.ac.jp)
＜以下、引用＞
keyboard-interactiveはサーバが直接仮想端末を制御して、パスワードを読み込むのに対して、
passwordはクライアント側が任意の方法でパスワードを読み込んでサーバに渡すらしい。
普通に端末から使う分にはあまり違いを意識することはないと思うが、sshを実行したプログラムが
(仮想)端末を持たない場合(Eclipseからssh経由でcvsを使う場合など)はpassword認証だと
SSH_ASKPASS が使えるという違いがある。というか、多分違うのはこれくらい。
241:名無しさん＠お腹いっぱい。
06/08/07 23:26:46
>>240
> keyboard-interactive認証とpassword認証の違いって何ですか？
password認証ってのはRFC4252の8章で定義されているやつで、
ぶっちゃけて言えば、ただ一回だけClientからServer宛てに
パスワード入りのパケットを投げつけて認証の成否を決めるやり方だ。
URLﾘﾝｸ(www.ietf.org)
対するkeyboard-interactive認証はRFC4256で定義されていて、
認証できるまでClientとServerの間で任意の回数・任意の個数の
メッセージをやりとりできる方法だ。
PAMのように複雑な状態遷移を持つ認証方法をssh上で行うことができるように、
password認証を拡張した方法ってことになる。
URLﾘﾝｸ(www.ietf.org)
> ググったら↓を見つけましたが、これで合ってるんですか？
> URLﾘﾝｸ(www.ss.ics.tut.ac.jp)
なんじゃそりゃ。
そんな無茶苦茶な説明なんか参考にしないで、RFC読め。
242:240
06/08/08 19:14:33
>>241
＞なんじゃそりゃ。
＞そんな無茶苦茶な説明なんか参考にしないで、RFC読め。
おお、やはりガセでしたか。
本家（特に英語の）の説明を読むのはどうも億劫で、ついググって分かりやすく解説してるサイトを探しがちで…
やはりこういうのは公式のを読まなきゃだめっすね。猛省します。
ありがとうございました。
243:名無しさん＠お腹いっぱい。
06/08/11 00:15:14
質問です。
【環境】
クライアント putty <==> FW <==> サーバ openSSH3.9 鍵認証方式
sshdの待機ポートをわけあって2つ(22, HOGE)にしたいと思っています。
そこでsshd_config内に
---------------------------------------
Port 22
Port HOGE
---------------------------------------
を追加し、sshdの再起動を行いました。
クライアントから接続すると、22番では接続可能なのですが、HOGEでは接続出来ません。
サーバのパケットダンプ(tcpdump tcp port HOGE -n)を見ると、サーバには届いているように見受けられます。
しかしputtyのログをみると、サーバには届いていて、sshdのバージョン情報？までは取れているのにもかかわらず、認証手続きが始まらない状態です。
サーバ側で"netstat -pln"、"nmap サーバのIP"等で確認しましたが、22：HOGEポートはLISTEN状態でした。
サーバ側の"/var/log/secure"、"/var/log/message"等には何も出力されていませんでした。
FWのポートが開いている事は確認済みです。
現在手元に環境が無いので詳細を書くことは出来ませんが、どなたか原因がわかる方はいらっしゃらないでしょうか？
244:名無しさん＠お腹いっぱい。
06/08/30 03:02:29
global-IPからは鍵認証
local-IPからは鍵もしくはパスワード認証
ってのをやろうとしたら、やっぱりsshd二つ動かすのが近道になっちまう？
245:名無しさん＠お腹いっぱい。
06/09/02 00:31:32
fall back to password でいいんじゃないの?
あるいは、-o PasswordAuthentication とか。
246:名無しさん@お腹いっぱい
06/09/03 15:23:29
4.4p1そろそろみたいね。
春山さんのところに出てた話で、予定されてる追加機能("Match"命令)興味あるなぁ。
パッチ当てずにchroot出来るならその方が良いんだが、どうなんだろう?
ちょっぴり期待
247:名無しさん＠お腹いっぱい。
06/09/10 01:01:57
＿∧＿∧＿∧＿∧＿∧＿∧＿∧＿∧＿
ﾃﾞｹﾃﾞｹ | |
ﾄﾞｺﾄﾞｺ ＜ 新バージョン4.4(p1)まだーーーーーーーー！！？ ＞
☆ ﾄﾞﾑﾄﾞﾑ |＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿ ＿|
☆ ﾀﾞﾀﾞﾀﾞﾀﾞ! ∨ ∨ ∨ ∨ ∨ ∨ ∨ ∨ ∨
ﾄﾞｼｬｰﾝ! ヽ ｵﾗｵﾗｯ!! ♪
＝≡＝ ∧＿∧ ☆
♪ ／ 〃（･∀･ #） / ｼｬﾝｼｬﾝ
♪ 〆 ┌＼と＼と.ヾ∈≡∋ゞ
|| γ ⌒ヽヽコ ノ ||
|| ΣΣ .|:::|∪〓 || ♪
.／|＼人 ＿.ノノ _||_. ／|＼
ﾄﾞﾁﾄﾞﾁ!
（※出典：URLﾘﾝｸ(dokoaa.com)）
248:名無しさん@お腹いっぱい
06/09/10 09:08:41
>247
ﾄﾞﾗﾑうまいねぇ
249:名無しさん＠お腹いっぱい。
06/09/18 05:14:30
社内に設置してあるサーバーの管理を任されたのですが
社員が数人、外部からSSHで接続することもあり
動的IPの人もいるのでIP制限をするわけでもなく
IDとパスワードさえあれば、どこからでも入れてしまいます。
一週間ログを取ってみたら毎日、辞書アタックや
ブルートフォースを食らっているのでiptablesで何らかの対応するか
公開鍵認証にしたほうがいいと上司に提案したのですが
それくらいのアタックなら大丈夫と言われました。
いくら乗っ取られる確率が低いといっても
いつ当たりを引くかわからないと思うのですが
僕が間違ってるのでしょうか
ちなみに顧客の個人情報を扱ってるサーバーです･･･
250:名無しさん＠お腹いっぱい。
06/09/18 07:29:07
上司を張った押してでも、セキュアな設定をしてしまえ
251:名無しさん＠お腹いっぱい。
06/09/18 07:43:47
> それくらいのアタックなら大丈夫と言われました。
しらばっくれる可能性大なので、大丈夫と判断した根拠を文書で
貰っときましょう。
252:名無しさん＠お腹いっぱい。
06/09/18 07:48:21
>それくらいのアタックなら大丈夫と言われました。
興味があるんで、その上司の歳と簡単な経歴が知りたい
253:名無しさん＠お腹いっぱい。
06/09/18 09:52:47
>>249
そういうやりとりはメールでやって、証拠を残しとくもんだ。
254:名無しさん＠お腹いっぱい。
06/09/18 13:48:34
上司の言質を取った上で、アタックで侵入されたログをでっち上げるべし。
責任はすべて上司へ。（管理職は責任をとるためにいる）
255:名無しさん＠お腹いっぱい。
06/09/18 14:05:27
>>250
それも有りなんですが
勝手に設定を変えて作業報告すらしてくれない人なので･･･
何度か不具合を起こしてサービス不能な状態になりました
>>251 >>253
文書を残すのは大事ですよね
メールもロクに投げてくれないような会社なので
自分だけはしっかりやっておこうと思います
>>252
30歳くらいでサーバーの実務経験は長いようです
自分の方が若い上に実務経験があまりないので
あまり意見を聞いてもらえません
>>254
危険性を認識させる必要はありますね･･･
大丈夫だと思っていても
実際に事故が起きて後悔する人って多いですからね
256:名無しさん＠お腹いっぱい。
06/09/18 17:33:54
弱いパスワードのユーザをしらべておくくらいのことはしておいたほうが
257:名無しさん＠お腹いっぱい。
06/09/18 17:47:08
sshでやられたケースって、
安易なユーザ名＋安易なパスワードが9割以上じゃないのか？
最近のsshへの総当りって、辞書使って攻撃して、辞書が尽きたら諦める
つまり、辞書でヒットしなかったら、ヒットする他のサイト探した方が速いって考え方なんで、
ユーザ名もパスワードも記号の羅列になっているような物はまず侵入されない。
まぁ、漏れの所は、日本以外弾いて、更に、一度攻撃してきたところはネットワーク毎弾いてるけど。
258:名無しさん＠お腹いっぱい。
06/09/18 17:49:02
sshでログインするユーザーは数名というなら、それだけを許可する設定に変えると良い。
259:名無しさん＠お腹いっぱい。
06/09/18 18:16:17
>>256
それを上司や経営者に断りなくやってクビになった人が居るお
260:名無しさん＠お腹いっぱい。
06/09/18 18:18:34
ともかく上司がそういう方針なら仕方ない。
証拠を集めて説得する事が出来ればいいが、たいていは無駄。
もっと上の人間に直訴するか辞めるか。辞めるなら求人難の今だと思うがな。
261:名無しさん＠お腹いっぱい。
06/09/20 21:01:22
>>260
今は求人難なの？
262:名無しさん＠お腹いっぱい。
06/09/20 22:33:13
募集をしても人が来ない。コンビニでさえ人手不足。
年収1000万以上の技術者になると、恐らく言い値で雇ってもらえる。
即戦力じゃなくても再教育して使えるならOK、雇ってしまえ という所さえある。
いろいろな意味で淘汰されるな。
263:名無しさん＠お腹いっぱい。
06/09/20 23:31:45
>>262
へー
年収1000万以上の技術職なんて紹介して欲しいぐらいだけど
264:not 262
06/09/20 23:38:50
年収1000万以上の技術職ってザラに居るよ。オレもそうだし、、
265:名無しさん＠お腹いっぱい。
06/09/21 20:54:44
sshでの接続は特定の際とからしか許可していないのに、しつこく
接続しようとする馬鹿ものがいる。例えば 221.141.3.52 とか、
221.224.8.88 とか。こういう奴らは何を考えているのだろうか？
266:名無しさん＠お腹いっぱい。
06/09/21 21:05:37
CN, China とか KR, Korea, Republic of とか
267:名無しさん＠お腹いっぱい。
06/09/21 21:09:41
>>265
す～ぱ～はか～に狙われた（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
268:名無しさん＠お腹いっぱい。
06/09/21 22:59:27
iptablesなどでアドレス範囲まとめてポアしる
チョン・シナのアドレスをリストしてるとこはググれば見つかる
269:名無しさん＠お腹いっぱい。
06/09/21 23:09:09
三国人フィルタ でぐぐれ
270:名無しさん＠お腹いっぱい。
06/09/21 23:45:29
だから特定のサイトからしか接続できないのよ。
当然、中国や韓国などからは接続拒否しているよ。
それにも関わらず、接続を試みようとするのはどういう
馬鹿ものなのかという質問なのだが。
271:名無しさん＠お腹いっぱい。
06/09/21 23:50:18
何を考えてるのかって言われても、
何も考えずスクリプト回してるだけっしょ。
272:名無しさん＠お腹いっぱい。
06/09/21 23:55:18
スクリプト回すというか、そのホストがbot化され、
クラッカーにいいように使われてるだけだろうな
273:名無しさん＠お腹いっぱい。
06/09/21 23:59:11
自分が意図しない不要な接続だと思ったらとっととDENYしちゃえばいいのに
それにも関わらず、２ｃｈでその意図を聞こうとするのはどういう
馬鹿ものなのか
274:名無しさん＠お腹いっぱい。
06/09/22 00:01:32
URLﾘﾝｸ(www.dayomon.net)
275:名無しさん＠お腹いっぱい。
06/09/22 00:07:54
>>274
だよもんｷﾀｰ、だよもん
276:名無しさん＠お腹いっぱい。
06/09/22 02:35:51
>>270
アタックかけてる側は、接続拒否されてるかどうかなんて分かんないし。
馬鹿？
277:名無しさん＠お腹いっぱい。
06/09/22 07:13:39
PasswordAuthentication no なら問題なし
278:名無しさん＠お腹いっぱい。
06/09/22 07:19:54
接続拒否と接続無視は違うのだが。
もちろん、PasswordAuthentication noだし、AllowUsersも
設定している。
279:名無しさん＠お腹いっぱい。
06/09/22 08:03:18
これ以上何が聞きたいんだか
280:名無しさん＠お腹いっぱい。
06/09/22 09:38:48
そんなことはどうでもいいから、接続元IPによってconfig切り替えれる機能付けてくれよ
bindみたいに書けると完璧
281:名無しさん＠お腹いっぱい。
06/09/22 09:58:29
ローカルネットワークからはパスワード
それ以外からは公開鍵認証にしたいのですが
どうすればできますか？
282:名無しさん＠お腹いっぱい。
06/09/22 10:09:25
ローカルアドレスとそれ以外のアドレスでlistenする複数のsshdを起動しとけばよい。
283:名無しさん＠お腹いっぱい。
06/09/22 11:01:15
ちょっと質問があります。
まず、前提条件として、以下の点について質問させてください。
パスワード認証を使わず、公開鍵認証で接続を行う場合、
クライアント側に秘密鍵を置く必要がありますよね。
その上で質問です。接続するクライアントA、サーバーとBとCがあった場合、
クライアントA → サーバーB → サーバーC
と言ったように、多段に接続したいのですが、
（サーバーBには直接接続できない）
・秘密鍵をクライアントAにだけおき、サーバーBにおきたくない
・できるだけ簡単に接続する方法はないか
といったようなことはできますでしょうか？
284:名無しさん＠お腹いっぱい。
06/09/22 11:28:29
>>283
ssh-agentのフォワード機能で普通にできる。
設定によっては ssh -A のオプションが必要。
285:名無しさん＠お腹いっぱい。
06/09/22 11:37:55
置かないというのはできる。
ssh(1)
-A Enables forwarding of the authentication agent connection. This
can also be specified on a per-host basis in a configuration
file.
Agent forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
agent's Unix-domain socket) can access the local agent through
the forwarded connection. An attacker cannot obtain key material
from the agent, however they can perform operations on the keys
that enable them to authenticate using the identities loaded into
the agent.
しかし、Bの特権を持っている人は秘密鍵を使うことは出来る(秘密鍵本体は盗めない)。
俺は、秘密鍵を使う時はポップアップで確認するようputtyのpagent(authentication
agent)を改造してつかっている。
286:283
06/09/22 11:41:06
＞（サーバーBには直接接続できない）
ごめん違った
（サーバーCには直接接続できない）
でした
287:283
06/09/22 14:32:59
調べたら、いろいろでてきました。
cl.pocari.org - connect を使って簡単に多段 SSH を実現する方法
URLﾘﾝｸ(cl.pocari.org)
connect.cを使う方法
cl.pocari.org - SSH で多段接続？
URLﾘﾝｸ(cl.pocari.org)
ssh-agentを使う方法
cl.pocari.org - SSH でポートフォワード
URLﾘﾝｸ(cl.pocari.org)
wakaran
どれが簡単な方法か、試してみようと思います。
-A使う方法がいまいちわかりませんが、また調べてみます
288:名無しさん＠お腹いっぱい。
06/09/22 14:44:27
>>287
せっかく回答もらってるのにそれは無視かい?
余計なこと調べなくていい。
ssh-agent 実行済みで、ふつうに ssh hostB ができる状態で、
ssh -A hostB するだけ。
で、hostB において ssh hostC すればそのまま入れる。
それだけ。
289:283
06/09/22 15:57:33
>>288
ごめんなさい。
そっちでやってみます。
290:283
06/09/22 16:54:14
$ ssh-agent bash
$ ssh -A (hostB) -i (hostCの秘密鍵)
パスフレーズ入力
hostBのパスワード入力
hostBで、
$ ssh hostC
Permission denied (publickey).
と言われました？
んんん。
291:名無しさん＠お腹いっぱい。
06/09/22 16:59:37
>>290
おまえ、ssh-agent自体の使い方知らんのちゃうか?
$ ssh-agent bash
$ ssh-add
(パスフレーズ入力)
$ ssh -A hostB
hostB$ ssh hostC
hostC$
↑これだけだよ。
292:283
06/09/22 17:05:15
>>291
いけました！
$ eval `ssh-agent`
$ ssh-add (hostCの秘密鍵)
(パスフレーズ入力)
$ ssh -A hostB
hostB $ ssh hostC
で、おｋですね。
ssh-agentで、秘密鍵を覚えさせとかないといけないんですね
つきあっていただいて、ありがとうございました。
293:名無しさん＠お腹いっぱい。
06/09/22 18:34:25
3段活用できませんかね
host1 -> host2 -> host3 -> host4
を1発でログインできたりといった感じで…
294:名無しさん＠お腹いっぱい。
06/09/22 20:51:50
ssh -A host2 ssh -A host3 ssh host4
295:名無しさん＠お腹いっぱい。
06/09/22 20:58:22
>>294
やってみればわかるけど、それだと「無端末」状態になるので、
シェルのプロンプトは出ないし、viとか画面制御系コマンドが起動できないし、
とにかく、普通にsshで直接ログインしたのとは違う状態になるよ。
296:名無しさん＠お腹いっぱい。
06/09/22 21:09:44
んなら
ssh -A -t host2 ssh -A -t host3 ssh -t host4
297:名無しさん＠お腹いっぱい。
06/09/22 23:48:27
多段sshを一発でやる方法があったのか
いいこと知った
298:283
06/09/22 23:56:45
わおｗ
> $ ssh -A hostB
> hostB $ ssh hostC
これは、
$ ssh -A -t hostB ssh -t hostC
でいけるんですね。
すげｗ
evalとこもshellにでもしたらもっと楽になるな
299:名無しさん＠お腹いっぱい。
06/09/23 00:01:40
多段でscpしようとおもったらどうすれば？
300:名無しさん＠お腹いっぱい。
06/09/23 00:08:37
がんばりなさい
301:名無しさん＠お腹いっぱい。
06/09/23 00:23:32
ssh -A host2 ssh -A host3 ssh host4 tar cf - hoge| tar -vf -
302:名無しさん＠お腹いっぱい。
06/09/23 00:35:13
>>301
tar -v ??
あと、tarはscpじゃないし。
303:名無しさん＠お腹いっぱい。
06/09/23 01:31:30
> 299
scp -oProxyCommand='ssh hostA netcat hostB 22' file hostB:
なんて、どう？
304:名無しさん＠お腹いっぱい。
06/09/23 01:34:53
昔、多段sftpやろうとしたらcore吐いて落ちた
305:名無しさん＠お腹いっぱい。
06/09/24 16:25:59
sshdに対するアタックを減らすために、ポート番号を22以外に変更したいのですが、
どこで設定すればよいのでしょうか？
306:名無しさん＠お腹いっぱい。
06/09/24 16:28:25
>>305
sshd_configに記述、または sshdの起動スクリプトで sshd -p オプションで指定。
307:名無しさん＠お腹いっぱい。
06/09/25 07:31:28
鍵+パスフレーズを利用してsshを利用しているのですが、
ログインに時間がかかります。
12、13秒ほどかかります。
これって、こういうものですか？
鍵は、DSA 768bitです。
パスフレーズは、8文字程度です。
308:名無しさん＠お腹いっぱい。
06/09/25 07:32:54
すいません、マシンのスペック書き忘れました。
ローカルホスト： PentiumD 3GHz、メモリ 2GB
リモートホスト： Celeron(R) 2.53GHz、メモリ 512MB
です。
309:名無しさん＠お腹いっぱい。
06/09/25 07:34:40
一応、sshのバージョンも
ローカルホスト：ssh cygwin OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
リモートホスト：sshd OpenSSH_4.2p1 Debian-7ubuntu3, OpenSSL 0.9.8a 11 Oct 2005
310:名無しさん＠お腹いっぱい。
06/09/25 08:01:03
>>307
DNS まわりじゃないの？
サーバ側でクライアントの IP アドレスを逆引きできないとか。
311:名無しさん＠お腹いっぱい。
06/09/25 08:38:01
本当にDNS逆引きが原因だった場合は、
↓を読んで、環境を晒してしまったことを後悔しましょう。
ｽﾚﾘﾝｸ(unix板:13番)
312:名無しさん＠お腹いっぱい。
06/09/25 08:51:47
>>310
問題なく逆引きできました。
サーバーもクライアントも、DNSに登録されています。
313:名無しさん＠お腹いっぱい。
06/09/25 08:52:20
>>311
これくらいの情報で、個人が特定できるものなんでしょうか・・・
314:名無しさん＠お腹いっぱい。
06/09/25 13:14:22
DNS まわりが原因の場合は12,3秒では済まない。
普通は分のオーダーになる
315:名無しさん＠お腹いっぱい。
06/09/25 14:13:59
>>307
sshd_configに
UseDNS no
って書くと早くなるかも。
316:名無しさん＠お腹いっぱい。
06/09/25 14:47:15
PasswordAuthentication
をオプションで明示してみれば? fall back が遅いのであれば、-v で大体検討はつくので試してみるべし。
ssh って、packet lengthあたりにバグが残っていて巨大なパケットを吐いている形跡なくない?
317:名無しさん＠お腹いっぱい。
06/09/25 19:31:30
ssh でユーザー認証できないと言われ、
ログインできないユーザーがあるのですが、どういったことが考えられますか？
・公開鍵を使っている
・同じ鍵で、別ユーザーではログインできている
・AllowUsers/DenyUsersは、sshd_configに書いていない。
・PasswordAuthentication = noで、パスワード入力は許可していない。
しかし、PasswordAuthentication = yesのときは、普通に入れた。
318:名無しさん＠お腹いっぱい。
06/09/25 19:54:39
authorized_keysの書き方が変
authorized_keysのパーミッションが変
319:名無しさん＠お腹いっぱい。
06/09/25 20:09:14
.sshのパーミッションが変
~のパーミッションが変
320:名無しさん＠お腹いっぱい。
06/09/25 20:09:40
>>318
ログイン出来るユーザーからコピーしてもダメでした。
chmod 600 authorized_keys
chmod 644 authorized_keys
両方ダメでした。
何故だ・・・困った。
ユーザー変えただけだのに・・・
321:名無しさん＠お腹いっぱい。
06/09/25 20:16:05
chown user authorized_keys
322:名無しさん＠お腹いっぱい。
06/09/25 20:26:04
local$ chmod 600 ~/.ssh/identity ~/.ssh/id_dsa ~/.ssh/id_rsa
323:名無しさん＠お腹いっぱい。
06/09/25 20:39:09
>>319
.ssh 700
~ 775
>>321
(~と同じ)ログインしたいユーザー名になってた
>>322
そのようなファイル郡はありません。
ログインできているユーザーにもありません。
324:名無しさん＠お腹いっぱい。
06/09/25 20:41:19
>>322
あ、ローカルか。
Poderosaなので、その辺関係あるのかな？
325:317=320=323
06/09/25 20:52:49
紛らわしいので、名前つけました。
cygwinのsshからだと接続できました。
しかしながら、
> ssh (IPアドレス) -l （ユーザー名） -i (キー名)
Enter passphrase for key '(キー名)': ←パスフレーズを入力する
(ユーザー名)@(ホスト名)'s password: ←ユーザーのパスワードを入力する
ログイン出来る
という二段認証になっています・・・？
Poderosaや、WinSCPでログインできないのはこのせいでしょうか？
Poderosaでログインできたユーザーでは、
普通どおり、最初のパスフレーズのみを聞いてきます。
326:名無しさん＠お腹いっぱい。
06/09/25 20:56:35
~ を755にしてみそ
327:名無しさん＠お腹いっぱい。
06/09/25 21:12:22
なんつーか、間違ったアドバイスする人多いね、このスレ。
あまり参考にしない方がいいよ。
328:名無しさん＠お腹いっぱい。
06/09/25 21:15:16
正しいアドバイスしてから言えば
329:名無しさん＠お腹いっぱい。
06/09/25 21:16:54
正しいアドバイス：
(a) 死ね！
(b) 七輪と煉炭
(c) 樹海
330:名無しさん＠お腹いっぱい。
06/09/25 21:21:25
~ は 700 でログインできる。
authorized_keys のパーミッションとかは関係ない。
↑の点に付いて言ってるアドバイスは間違い。
ローカル側の identity id_dsa id_rsa は、
自分以外が読めるパーミッションではいけない。
331:317
06/09/25 21:58:41
>>326
同グループで書き込めなくなっちゃうよ・・・
332:名無しさん＠お腹いっぱい。
06/09/25 22:21:04
ssh -v での様子も張り付けず
sshd のログも張り付けず
な香具師は放置
333:326
06/09/25 22:35:23
>>331
俺が以前嵌った時と同じ嵌り方してるんだから、文句言うな！ｗ
334:名無しさん＠お腹いっぱい。
06/09/25 22:41:54
だからぁ～、~ のパーミッションは無関係だって
335:317
06/09/25 22:46:11
>>332
>>311を読んで、できるだけ情報を晒さないようにしたのですが、ヒドイ・・・うう
でも、解決したいので、晒してみます。
336:名無しさん＠お腹いっぱい。
06/09/25 22:46:42
>>325
それは、二段認証になってたのじゃなくて、
公開キーでの認証に失敗したから、UNIXパスワードで認証されたの。
で、>>317 では「PasswordAuthentication = noで、パスワード入力は許可していない」
と言ってるのに、これと状況が食い違っている。
もう一度状況を整理すること。
で、ssh -v のログを貼ること。でないとマトモな人間は答えてくれないし、
「知ったか」が間違ったアドバイスをするだけ。既にされてるけど。
337:名無しさん＠お腹いっぱい。
06/09/25 22:47:53
>>311 のネタを真に受けていたとはｗ
338:名無しさん＠お腹いっぱい。
06/09/25 22:49:55
騙されたと思ってchmod go-w ~ をやれ
339:名無しさん＠お腹いっぱい。
06/09/25 22:50:26
いや、騙してないからやれ。
340:名無しさん＠お腹いっぱい。
06/09/25 22:51:31
この際グループでの書き込みはあきらめてやれ。
341:317
06/09/25 22:53:59
-v 晒します
> ssh (リモートのIP) -l (ユーザー名) -i (秘密鍵) -v
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Connecting to (リモートのIP) [(リモートのIP)] port 22.
debug1: Connection established.
debug1: identity file (秘密鍵) type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 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
debug1: Host '(リモートのIP)' is known and matches the RSA host key.
debug1: Found key in /home/toby/.ssh/known_hosts:2
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,password,keyboard-interactive
debug1: Next authentication method: publickey
%
342:317
06/09/25 22:54:37
debug1: Trying private key: (秘密鍵)
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '(秘密鍵)':
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
(ユーザー名)@(リモートのIP)'s password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Mon Sep 25 22:48:07 2006 from (前回ログインしたローカルホスト)
OpenBSD 3.8-stable (GENERIC) #1: Tue May 9 19:59:50 JST 2006
343:317
06/09/25 22:56:27
>>336
すみません。
直後、ログインできねえ、とブーブー言われたので、
PasswordAuthentication = yes にしたのでした orz
>>338
試してみます。
344:317
06/09/25 23:02:04
>>338
ｷﾀ━━━（ﾟ∀ﾟ）━━━ !!
ログインできたぁぁぁぁぁぁぁぁぁぁぁーーーーーーー
これだけのことなのかーーーーーーー
みなさま、付き合っていただきありがとうございました。
グループでの書き込みは諦めます・・・あぅあぅ orz
345:名無しさん＠お腹いっぱい。
06/09/25 23:13:51
>>344
それだけの事に俺も以前はまったんだーーーーーーーっ
346:名無しさん＠お腹いっぱい。
06/09/25 23:16:04
>>334
プププ
347:名無しさん＠お腹いっぱい。
06/09/25 23:18:04
んで、君のおかげで~/.がグループから書き込めるようになってると
SSHにどんな穴が開くか今ひらめいたよorz
348:名無しさん＠お腹いっぱい。
06/09/25 23:25:22
strictmode no
お勧めはせん
349:名無しさん＠お腹いっぱい。
06/09/25 23:53:24
linux のなんかのディストリビューションだと
umask 002
になってて、考えずにauthorized_keysを作成すると
グループにwビットが立ってsloginできない事があったなそういえば。
350:名無しさん＠お腹いっぱい。
06/09/26 03:17:52
RedHat 7.x とかね。要らんことすんな死ねクソと思った。
351:名無しさん＠お腹いっぱい。
06/09/26 04:26:56
>>323
それ、ウチの若いのも報告書に書いて、
そのまま客先に行って恥かいて困ってるのよ。
「おめーの田舎は、茨城県サーバ郡か?」
って言っても気付いてくれない。
352:名無しさん＠お腹いっぱい。
06/09/27 04:21:00
セキュリティホール memo (2006.09.26) より
[SA22091] OpenSSH Identical Blocks Denial of Service Vulnerability
URLﾘﾝｸ(www.st.ryukoku.ac.jp)
ぬゎんだコレは！ (@~@)!! 寝耳に水というか何というか。。
（注：既に修正済み）
んで、SSHプロトコルver.1 って有効にしてるところって多いのかな。（デフォルト
では、両方とも有効になっている。Protocolオプションのデフォルトは"2,1"）
4.4(p1)がリリースされれば速攻でアップグレードしなきゃならんなぁ。。
353:名無しさん＠お腹いっぱい。
06/09/27 07:37:16
ｹﾞﾗｹﾞﾗ
354:名無しさん＠お腹いっぱい。
06/09/27 14:28:26
なあに、かえって Protocol 2 に設定変更する言い訳になる。
355:名無しさん＠お腹いっぱい。
06/09/27 16:23:07
Compression delayedはCompression yesと比較して何かメリットがあるのですか？
356:名無しさん＠お腹いっぱい。
06/09/27 19:06:58
>>355
zlib に穴あっても攻撃されづらくなるんじゃね？
357:名無しさん＠お腹いっぱい。
06/09/28 18:46:05
4.4p1が出たのに誰のｶｷｺもない件
…FreeBSDでビルドしようとしたけど、警告(warning)が出るわ出るわ。。orz
358:307
06/09/28 19:00:42
ログインが遅いと言っていた者です。
どうも、特定のホストで遅くなるようです。
Ubuntuで遅くなる。
CentOS、OpenBSDの場合は、普通に瞬間的にログイン。
DNSはどれも逆引きできています。
359:307
06/09/28 19:01:32
全てOSはサーバー側です。
鍵も同じもので調べました。
クライアントは、Windows(Poderosa、及びcygwin+ssh)です。
360:名無しさん@お腹いっぱい
06/09/28 21:32:48
4.4p1うちにもｷﾀｰ
361:名無しさん＠お腹いっぱい。
06/09/28 22:51:02
変更点by春山さんｷﾀ*･゜ﾟ･*:.｡..｡.:*･゜(ﾟ∀ﾟ)ﾟ･*:.｡. .｡.:*･゜ﾟ･*!!!!!
URLﾘﾝｸ(www.unixuser.org)
362:名無しさん＠お腹いっぱい。
06/09/29 18:22:29
4.4にchroot patchを当てようと思い以下にアクセスしたけど404…。
ここの活動状況について知ってる人いますか？
URLﾘﾝｸ(chrootssh.sourceforge.net)
363:307
06/09/29 22:43:01
-v 張ってみます。
> ssh (サーバーのIP) -i ~/.ssh/key.openssh -p ****** -v
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Connecting to (サーバーのIP) [(サーバーのIP)] port 25672.
debug1: Connection established.
debug1: identity file /home/.ssh/key.openssh type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.2p1 Debian-7ubuntu3
debug1: match: OpenSSH_4.2p1 Debian-7ubuntu3 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
debug1: Host '(サーバーのIP)' is known and matches the RSA host key.
debug1: Found key in /home/toby/.ssh/known_hosts:8
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: Trying private key: /home/.ssh/key.openssh
debug1: PEM_read_PrivateKey failed