10/02/16 21:23:37
SSHに関する情報交換のスレッドです。
FAQ、リンク集は >>2-5 あたり。
過去ログ
Part1：URLﾘﾝｸ(pc.2ch.net)
Part2：URLﾘﾝｸ(pc.2ch.net)
Part3：URLﾘﾝｸ(pc5.2ch.net)
Part4：ｽﾚﾘﾝｸ(unix板)
Part5：ｽﾚﾘﾝｸ(unix板)
Part6：ｽﾚﾘﾝｸ(unix板)
2:名無しさん＠お腹いっぱい。
10/02/16 21:25:21
よくある質問
Q.公開鍵認証などは使用せず、パスワードによる認証を行う場合でも
そのパスワードは暗号化されているのですか？
A.はい、その通りです。
SSHプロトコルでは、まず始めにサーバ<->クライアント間で
暗号化された通信路を確立します。
ユーザ認証はその暗号化通信路の上で行なわれるので、
パスワードなどもちゃんと秘匿されています。
Q.最近、root,test,admin,guest,userなどのユーザ名で
ログインを試みる輩がいるのですが？
A.sshdにアタックするツールが出回っているようです。
各サイトのポリシーに従って、適切な制限をかけましょう。
参考：URLﾘﾝｸ(www.st.ryukoku.ac.jp)
3:名無しさん＠お腹いっぱい。
10/02/16 21:26:20
◇実装
本家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.sakurachan.org) (日本語版)
URLﾘﾝｸ(sleep.mat-yan.jp) / URLﾘﾝｸ(ttssh2.sourceforge.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:名無しさん＠お腹いっぱい。
10/02/16 21:27:05
◇規格等
・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)
WideのSSH解説
URLﾘﾝｸ(www.soi.wide.ad.jp)
◇おまけ
Theoのキチガイぶり
ｽﾚﾘﾝｸ(unix板:546-550番)
djbsssh(ネタ)
URLﾘﾝｸ(www.qmail.org)
5:1
10/02/16 21:28:09
一応前スレの最初の方をざっと眺めて指摘されていた点などを修正しつつスレ立てようと思いましたが
面倒糞くなったのでそのままコピペしました。
後よろしく。
6:名無しさん＠お腹いっぱい。
10/02/16 21:33:26
※デフォルト設定のまま放っておくと総当りアタックの餌食になると覚悟してください。
最低限次のような対処をしておきましょう。
URLﾘﾝｸ(www12.atwiki.jp)
●最善策
パスワード認証を止めて、公開鍵認証へ変更する
rootの直接のログインは不許可とする
特定の接続元からのみ接続を許可する
●次善策
User名を推定しにくい物に設定し、AllowUsersで特定のユーザーのみログイン可能とする｡
特定の接続元からの接続を拒否する
ポートを変える
7:名無しさん＠お腹いっぱい。
10/02/17 14:12:38
>>1
乙
8:名無しさん＠お腹いっぱい。
10/02/17 20:17:48
なあ、インターネットに繋がってないマシンも 6 をやってる？
9:名無しさん＠お腹いっぱい。
10/02/17 22:27:20
パスフレーズ無しの公開鍵認証の方が楽
10:名無しさん＠お腹いっぱい。
10/02/18 00:13:17
っつーか公開鍵使わない認証って SSH 使う意味ないよね
11:名無しさん＠お腹いっぱい。
10/02/18 00:19:24
なんで？
12:名無しさん＠お腹いっぱい。
10/02/18 00:20:21
>>10
俺もそうおもってた。。。。
でも、使えないんだよ。Dreamweaverだとかいうadobeのソフトは・・・
内部でopenssh呼び出してるだけなのに
13:名無しさん＠お腹いっぱい。
10/02/18 12:41:47
>>11
パスワード認証を暗号化したところで
ブルートフォースアタックには無力
14:名無しさん＠お腹いっぱい。
10/02/18 12:47:36
それがどうしたというのかね?
15:名無しさん＠お腹いっぱい。
10/02/18 12:57:25
>>13
それを言うなら公開鍵もブルートフォースで破れる
16:名無しさん＠お腹いっぱい。
10/02/18 12:59:58
それがどうしたというのかね?
17:名無しさん＠お腹いっぱい。
10/02/18 13:15:12
RSA1024bit一個生成するのにどれだけ時間がかかるか、わかって言ってるのか?
18:名無しさん＠お腹いっぱい。
10/02/18 14:38:16
>>6も勘違いしてるけど
ブルートフォースじゃなくて辞書攻撃なんだよなSSHが狙われてるのは
19:名無しさん＠お腹いっぱい。
10/02/18 15:05:51
アクセス元しぼればいいだけじゃん。
20:名無しさん＠お腹いっぱい。
10/02/18 15:31:37
辞書攻撃って（総当たりとは言えないにしても）ブルートフォース（腕ずく）の一種じゃないか？
21:名無しさん＠お腹いっぱい。
10/02/18 15:41:53
>>20
いや、ブルートは辞書ひいたりしないし、ポパイに至っては字も読めない
22:名無しさん＠お腹いっぱい。
10/02/18 15:52:31
辞書攻撃は立派な攻撃手法の一種
ブルートフォースといったら普通は「総当たり」作戦
一億玉砕本土決戦火の玉～な方を指すので
小賢しく辞書を片手にやるような軟弱な手法は眼中にはありません
23:名無しさん＠お腹いっぱい。
10/02/20 19:40:35
# SSHプロトコルの指定
Protocol 2
# rootでのアクセス許可
PermitRootLogin yes
# 接続を許可するユーザ
AllowUsers root
# セキュリティ設定
MaxStartups 2:90:5
LoginGraceTime 20
MaxAuthTries 3
port 22
# RSA公開鍵認証の有効化
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
24:名無しさん＠お腹いっぱい。
10/02/20 19:43:11
# パスワード認証無効化
PasswordAuthentication no
PermitEmptyPasswords no
RhostsRSAAuthentication no
ChallengeResponseAuthentication no
# ログのレベルを指定
SyslogFacility AUTH
LogLevel INFO
# パーミッションチェック
StrictModes yes
# その他
GSSAPIAuthentication no
GSSAPICleanupCredentials yes
UsePAM no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server
こんな感じで設定してるのですが、なぜか鍵認証方式で認証できなくなりました。
どうしてでしょうか？？
disconnected no supported authentication methods available
って表示されてしまいます。
25:名無しさん＠お腹いっぱい。
10/02/20 20:55:09
>>24
ssh2で接続してないからだな
26:名無しさん＠お腹いっぱい。
10/02/20 21:40:42
-vで起動すれば拒否される理由を教えてくれる。
27:名無しさん＠お腹いっぱい。
10/02/21 00:41:06
.ssh/authorized_keys から
違う場所に保存先を変えたら問題なく利用できました。
バージョンアップしたせいかな？？
28:名無しさん＠お腹いっぱい。
10/02/21 02:45:27
アクセス権のせいだろうな
29:名無しさん＠お腹いっぱい。
10/02/21 11:54:43
これまでは問題なく運用出来ていましたが、
ある日突然connection refusedのエラーが出て接続できなくなりました。
ps -e | grep sshd
としてもなにもでないため、sshdが起動してないように見えます。
HPUX10.2の環境のためか、シェルスクリプト
/etc/init.d/
がなく、
/opt/openssh/sbin/sshd start
ではダメと思いますが、sshdをfindで探してもここ以外見つかりません。
ネット上の一般的な知識が適用できず困っています。
HP-UX10.2運用で良い方法ありましたら教えてください。
30:sshd 起動するだけじゃん
10/02/21 12:02:02
> これまでは問題なく(ry
> ある日突然(ry
そのあいだにやったことを書けば解決できるじゃろ
31:名無しさん＠お腹いっぱい。
10/02/21 12:10:18
/etc/init.d/じゃなくて/sbin/init.d/じゃないの？
HP-UX知らないやつは手を出すなよ、壊すから
32:名無しさん＠お腹いっぱい。
10/02/21 13:16:06
レスサンクス。
>>30
再起動しかしてないです。
他のアプリが不調で二回再起動後に突然発生。
その後はsshd_configいじりすぎて何がなんだか。
一度全部消して作り直した方が良いかな。
>>31
init.dの場所が違うのかな。調べてみます。
init.d/sshd
があれば良いんだけど。
使いたくないんだけど、
HP-UXでしか動かないソフトを今でも使っていて。
dtermの使い勝手が悪くて閉口気味。
hptermが使える11.0に上げたいですが、目的のソフトが動かないというオチ。
10.2のdepotが非常にレアで参ってます。
33:名無しさん＠お腹いっぱい。
10/02/21 19:16:21
どう考えても ssh の質問じゃなくて HP-UX の質問じゃん
34:名無しさん＠お腹いっぱい。
10/02/21 19:25:47
>>33
10.2はデフォルトでssh入ってません。
パッケージ見つけてきて自分で入れたのですが。
とりあえずinit.dの場所が違うのが分かったので明日調べてみます。
そこから先はsshないしはsshdのconfigファイルか、
鍵関係に問題ありかなと思ってます。
自分で勉強もしますが、色々教えていただければ幸いです。
35:名無しさん＠お腹いっぱい。
10/02/21 20:19:13
スレ違いかもしれないが、WikipediaのSSHに関する記事
URLﾘﾝｸ(ja.wikipedia.org)
の「SSHのセキュリティリスク」のセクションに書かれていること、ちょっとやりすぎじゃないか？
OpenSSHのデフォルト設定の危険性を挙げているが、原文（英語）見ても
そんなことちっとも書いてないじゃないか。
IPAの仕業か？
36:名無しさん＠お腹いっぱい。
10/02/21 20:22:08
wikiなんだから書き替えたら。
37:名無しさん＠お腹いっぱい。
10/02/21 20:45:14
・PasswordAuthentication noにする
・PermitRootLogin noにする
・Protocol 2にする
正しい
・Portは22以外にする
意味無し
・ChallengeResponseAuthentication noにする
正しい
・AllowUsersにおいて特定のユーザーのみ接続を許可する
AllowUsers等(DenyUsers,DenyGroups,AllowGroups)でよい。
・authlogなどで認証失敗を検出したら、そのホストからの接続を遮断する
好きにすれば
・X11 port forwardingは無効にする
ログインを許容して、(OpenSSHの)X11 port forwardingをいじめても意味は無い。
・シェルが不要であれば、passwdファイルからシェルを取り除く
馬鹿丸出し。取り除いたらデフォルトは/bin/sh
38:名無しさん＠お腹いっぱい。
10/02/21 20:56:35
ブルートフォースアタックで簡単に破られるパスワードって、よっぽど弱いんだろうな。
そりゃ論理的にはいつかはビンゴするだろうけど、確率論的には現実的な時間内では簡単に破ることはできないし、ログ監視してりゃすぐわかるだろうになぁ。
>>37
攻撃によってログが埋もれるのがウザイ場合は、ポート番号を変更することはあるよ。
>シェルが不要であれば、passwdファイルからシェルを取り除く
/bin/false とかにすればいいと思うが。。
39:名無しさん＠お腹いっぱい。
10/02/21 21:10:01
チャイナ、コリアはデフォルトでドロップだろ。
40:名無しさん＠お腹いっぱい。
10/02/21 21:13:41
/bin/reverseattack
41:名無しさん＠お腹いっぱい。
10/02/22 02:53:56
>>38
> >シェルが不要であれば、passwdファイルからシェルを取り除く
> /bin/false とかにすればいいと思うが。。
だから"取り除く"じゃないんだろ。
42:名無しさん＠お腹いっぱい。
10/02/22 10:10:09
ssh 対象ユーザで shell 不要ってどういう場合?
sftp only?
43:名無しさん＠お腹いっぱい。
10/02/22 10:19:43
authorized_keysでコマンド指定してあれば、不要なんじゃないかな。
44:名無しさん＠お腹いっぱい。
10/02/22 17:53:23
>>37
> ・Portは22以外にする
> 意味無し
>>38 も書いてるけど、意味は大いにあるよ。
Portを変えるだけでログイン関係のログの量が簡単に1/100程度には減る。
必要なログがゴミの中に埋没しなくなるのはかなり重要。
>>39
最近は cn, kr 以外のも相当多いぞ。
数年前とは状況が違う。
45:名無しさん＠お腹いっぱい。
10/02/22 18:31:42
>>44
稚拙な攻撃ツールからのログを減らしてるだけ。
sshdは接続されたらsshdである事を自己申告するのでデフォルトから変える意味は無い。
46:名無しさん＠お腹いっぱい。
10/02/22 18:49:34
ログを減らせることに意味があるだろうが、ということだと思うんだが。
47:名無しさん＠お腹いっぱい。
10/02/22 18:54:18
ログを減らせることの意味がわからないんじゃないの
48:名無しさん＠お腹いっぱい。
10/02/22 18:56:05
俺もｳｪﾙﾉｳﾝﾎﾟｰﾄ以外を使うのは、ある程度は有効だと思う。
まるっきりﾎﾟｰﾄｽｷｬﾝする奴もいるかもしれないけど、ｳｪﾙﾉｳﾝﾎﾟｰﾄはまともに来るもんね。
効果としてはｾｷｭｱになるとまでは言えないかも知れないけど、しないよりはましだと思う。
49:名無しさん＠お腹いっぱい。
10/02/22 19:00:51
稚拙な管理者はログを一切見ないので
ログが多かろうと少なかろうと違いはない
ということだな
50:名無しさん＠お腹いっぱい。
10/02/22 19:06:33
Password(PAM)有効じゃ無ければログ残らないだろ。
ログ減らせるとか喜んでる奴、恥ずかしくないのか?
51:名無しさん＠お腹いっぱい。
10/02/22 19:08:25
セキュリティポリシーって難しいよね。
某スレで、送信元IPアドレスでフィルタリングしちゃう
（＝ 許可されたIPアドレス以外は認証すらしない）
人がいたんだが、もちろんそれはそれでポリシーとしてありだと思うよ？
でもね、俺は自宅だけでなく大学とかからもSSH使うから
送信元IPアドレスでのフィルタリングはしてないよ、って言ったら
もー、初心者扱いされてまいったよ。
死ねだのタコだの。もうね。。
52:名無しさん＠お腹いっぱい。
10/02/22 19:11:51
可能性のあるところだけ通せばいい。個人用ならそれが普通。
53:名無しさん＠お腹いっぱい。
10/02/22 19:18:39
>>50
OpenSSHサーバだけど、公開鍵認証でもログ残るよ？
Feb 22 19:14:21 *** sshd[18646]: Accepted publickey for naoto from *** port 51295 ssh2
Feb 22 19:14:21 *** sshd[18646]: pam_unix(sshd:session): session opened for user naoto by (uid=0)
ちなみに僕ちんはファイアウォールでもログ残しているよ。
54:名無しさん＠お腹いっぱい。
10/02/22 19:20:23
>>53
それ、侵入されたログ。ｗｗｗ
55:名無しさん＠お腹いっぱい。
10/02/22 19:28:00
>>54
おお、ほんとだチャレンジに失敗するとログ残さないな。
ま、ファイアウォールのログ監視してれば攻撃されていることはすぐにわかるけどね。
56:名無しさん＠お腹いっぱい。
10/02/22 19:31:32
>>50
あえて攻撃のログを出させた方が
動的にフィルタで対処できる、という考え方もあるんだが。
攻撃を受けた&失敗したログがまったく残らないのでは
「新しいパターンの攻撃」が出たときどうするの?
>>52
個人用ならある程度は限定できるだろうけど
仕事だとそうもいかんね
57:名無しさん＠お腹いっぱい。
10/02/22 19:33:08
>>53
そういうことじゃなくて、パスワード認証を有効にしてるから辞書攻撃を食らって
ログが肥大化するのであって、無効にしておけば接続してきてもすぐにあきらめるから
気にするほどログが大きくならないということかと。
>>54
知らないって幸せだね。
58:名無しさん＠お腹いっぱい。
10/02/22 19:56:28
>>57
> そういうことじゃなくて、パスワード認証を有効にしてるから辞書攻撃を食らって
UsePAMが設定されてるといってパスワード認証が有効とは限らんよ。
sshd_config の注釈では「PAMの設定次第でPasswordAuthentication, PermitEmptyPasswordsの設定は無視される」
となってるが、普通は UsePAM yes にしても PasswordAuthenticationやPermitEmptyPasswords の設定はちゃんと効く。
つまり PAMの設定が変なことになってない限り、UsePAM yes と PasswordAuthentication no の組み合わせで
ちゃんとパスワード認証不可になり、攻撃失敗のログも残る。
以下はその設定での /var/log/secure の攻撃失敗例
Feb 21 06:40:28 hogehoge sshd[25255]: Received disconnect from 219.139.240.176: 11: Bye Bye
Feb 21 17:17:26 hogehoge sshd[26496]: Did not receive identification string from 85.132.35.155
Feb 21 18:07:02 hogehoge sshd[26596]: Invalid user nagios from 222.68.194.69
Feb 21 18:07:02 hogehoge sshd[26597]: input_userauth_request: invalid user nagios
知らなかった?
59:名無しさん＠お腹いっぱい。
10/02/22 20:16:49
HTTPやSMTPやらと違って、不特定多数からアクセスされることが前提のサービスじゃないわけだから、
変えられるんなら変えたほうが効果がある。
>>45は「丸一日nmapでポートスキャンすればSSHポート見つかる」って言いたいんだろうし、
だからあんたにとっては無意味なんだろうってのもわかるけど、俺の場合デフォルトから変えたSSHポートに対して
攻撃が来たことは一度もないわけで。
まあアレだ、「HTTPのバナーを削れ」ってのとある意味では似ていてある意味では違うもんなんだと思う。
ちなみに>>44の「ログの量が減る」っていう発想はなかったｗ 微妙に間違ってる希ガス
60:名無しさん＠お腹いっぱい。
10/02/22 20:27:40
>>58
ログ太らせるのが趣味でそのように設定しているんだから、むしろ歓迎すべきだな。
22から変える意味はない。ｗ
パスワード認証不可でPAMを有効にできるのはPAMのアカウンティングを利用するため。
本質を理解しないとダメだよ。
しかも、ログの読み方知らないで見当外れのログを自信満々に例示してるし…
そこに残ってる"Did not receive identification string"はsshプロトコルでプロト
コルバージョンの交換が出来なかった時のログ。
"input_userauth_request: invalid user"は認証方式の交換に失敗した時のログ。
勉強になったか?
まとめると、
port 22を変更するのはパスワード認証を有効にしている素人管理者サイト
でログを減量できるが、それ以上の意味は無い。
61:59
10/02/22 20:32:12
「HTTPのバナーを削れ」ってのと…て書いたけど、もちとわかりやすく言うと
「それで完全に防げる」と勘違いしちゃだめなわけで。
62:名無しさん＠お腹いっぱい。
10/02/22 20:42:14
>パスワード認証を有効にしている素人管理者サイト
これ誤解や。パスワード認証自体が危険なわけじゃないで。
63:名無しさん＠お腹いっぱい。
10/02/22 20:47:06
個人で使う範囲なら、公開鍵認証オンリーにできるんだけどね。
64:名無しさん＠お腹いっぱい。
10/02/22 20:52:09
>>59
うちにも自宅鯖置いてるけど、ポートスキャンってフルでかけてくることって
ほとんどないような.....
だいたい特定のポートをいくつかかいつまんでポートスキャンしてくる感じ
っていうか全ポートスキャンなんて効率悪すぎるだろうに
うちは22/TCPでSSH動かしてるけど、例えば65432/TCPとかにでもしときゃ
確かにほとんどこんなポート突きになんて来ない気がする
65:名無しさん＠お腹いっぱい。
10/02/22 21:03:13
>>51
基本的に送信元IPアドレスを限定する方をお勧めする
一時的に可変的なIPアドレスからの接続を許可するために
コントロールパネルのようなものを作っておくと便利
いま繋がってるアドレスをその日だけ許可するとか出来るし
66:名無しさん＠お腹いっぱい。
10/02/22 21:09:01
>コントロールパネルのようなものを作っておくと便利
それをどうやって安全に操作させるか…
平文 HTTP の basic 認証とかだったら殴る
67:名無しさん＠お腹いっぱい。
10/02/22 21:10:01
>>62
このスレでのサンプリングの結果、ログが減って(すなわちパスワード認証有効)
うれしい管理者は、素人管理者と推定出来ます。
もっとも、パスワード認証無効の中にも>>58のような素人も居るので素人とパス
ワード認証を結び付けるのには無理があるかもしれません。
68:名無しさん＠お腹いっぱい。
10/02/22 21:11:07
>>62
またおまえか
そんなアホな風説流すな
69:名無しさん＠お腹いっぱい。
10/02/22 21:14:47
>>68
なにが？
70:名無しさん＠お腹いっぱい。
10/02/22 21:15:50
>>66
もちろん平文にはしないが
少なくとも ssh にアタックしてくるスクリプトが
わざわざコントロールパネルの URL を調べて
そっちでアクセス元 IP アドレス許可してから
アタックし直す可能性なんて限りなく低いだろ？
仮にコンパネ側の方が認証パスして
その IP アドレスが許可されたとしても
ssh の方の鍵持ってなきゃ実質なにも出来ないだろ？
ログが増えるのも防止できて一石二鳥三鳥だぜ
71:名無しさん＠お腹いっぱい。
10/02/22 21:18:44
>>70
VPNでアクセスすりゃいいよめんどくせぇ
72:名無しさん＠お腹いっぱい。
10/02/22 21:18:53
>平文 HTTP の basic 認証とかだったら殴る
xrea.comですねわかります
73:名無しさん＠お腹いっぱい。
10/02/22 21:25:22
>>65
なるほど、うん、うん。それはいいね。
まあ、俺は詳しいやり方を聞かなくても余裕で出来ちゃうんで
別に教えてくれなくても平気なんだけど、
まあ、世の中にはそのやり方を知りたいけど素直に聞けなくて
やれ「そんなやり方はセキュアじゃない」とか言っちゃうやつも
いるけど、
そのやり方をちょっと詳しく分かりやすく書いてあげると、なんかこう
ホノボノすると思うんで、どうかな、もうちょっと詳しく…
いや別に俺がマネしようとか言うんじゃないんだ。
74:名無しさん＠お腹いっぱい。
10/02/22 21:26:27
>>73 そういう書き方は「こいつ余裕ないんだなﾌﾟ」と思われるだけなんだがな…
75:名無しさん＠お腹いっぱい。
10/02/22 21:33:42
それをマジレスと思えるあんたはまだ素直な心の持ち主なんだなあ
76:名無しさん＠お腹いっぱい。
10/02/22 21:35:02
sshd : .jp : allow
これだけでだいぶ減る
77:名無しさん＠お腹いっぱい。
10/02/22 21:45:19
パスワード認証無効 & AllowUsersで絞っているけど、たまに攻撃の間隔
が短すぎてCPU負荷があがることがあるので、DenyHostsとかも使ってる
>>76
それは海外行った時困るだろw
78:名無しさん＠お腹いっぱい。
10/02/23 00:04:33
まあ最近SSHは流行んないつーか、普通にシングル3つでいいんじゃね？
どうしたってメタル臭が抜けない気がする。
どうしてもっていうならディマジオのスーパーディストーションの白黒
にするとおさまりいいと思うよ。
79:名無しさん＠お腹いっぱい。
10/02/23 00:05:14
あ、ごめんなさい。スレ間違えました
80:名無しさん＠お腹いっぱい。
10/02/23 00:07:38
SSH HSHｗｗｗｗ
81:名無しさん＠お腹いっぱい。
10/02/26 00:57:19
俺はHHがイイです
82:名無しさん＠お腹いっぱい。
10/02/26 13:35:19
じゃあ俺はH×H
83:名無しさん＠お腹いっぱい。
10/02/26 13:43:06
∧＿∧ ┌───────
◯（ ´∀｀ ）◯ ＜ 僕は .357 H&H Magnumちゃん！
＼ ／ └───────
_／ ＿＿ ＼_
（＿／ ＼＿）
ｌｌｌ
84:名無しさん＠お腹いっぱい。
10/02/26 18:33:22
HH+コイルタップで十分だな
85:名無しさん＠お腹いっぱい。
10/03/03 09:13:47
未だにSSHで検索すると埼玉最終兵器が一番上な件
86:名無しさん＠お腹いっぱい。
10/03/03 09:25:53
>>85
かっこいいからいいじゃん。むしろsshの語源の方がださいし。
87:名無しさん＠お腹いっぱい。
10/03/03 11:11:15
sshはセキュア・シェル・、、の略だそうですが、
では h は何の略なんですかぁ？
Secure Shell H???
88:名無しさん＠お腹いっぱい。
10/03/03 11:12:32
Secure SHell
89:名無しさん＠お腹いっぱい。
10/03/03 11:13:03
S=Secure
SH=Shell
のはず
90:名無しさん＠お腹いっぱい。
10/03/03 11:17:35
もっと粋な返しはないのか。。
91:名無しさん＠お腹いっぱい。
10/03/03 11:28:34
>>90
ぢゃお前がお手本みせろよ
92:名無しさん＠お腹いっぱい。
10/03/03 11:35:49
>>90
フリがつまんないからしょうがない。
93:名無しさん＠お腹いっぱい。
10/03/03 18:34:21
sh
↓外からも使えたら便利じゃね？
rsh
↓やべー穴だらけだったよｗ
ssh
94:名無しさん＠お腹いっぱい。
10/03/03 21:46:53
>>90
wktk
95:名無しさん＠お腹いっぱい。
10/03/03 22:57:12
S=すごい
S=Scienceで
H=Hします
96:名無しさん＠お腹いっぱい。
10/03/05 20:06:08
>>93
もう進化しないのかな
97:名無しさん＠お腹いっぱい。
10/03/06 08:33:58
sh → rsh → ssh → ssh(OpenSSH) → ssh(djbssh)
98:名無しさん＠お腹いっぱい。
10/03/06 11:26:24
おいやめろ
99:名無しさん＠お腹いっぱい。
10/03/06 15:30:31
いいぞもっとやれ
100:名無しさん＠お腹いっぱい。
10/03/06 17:01:54
で、最後は飽きて放置するんですな。
101:名無しさん＠お腹いっぱい。
10/03/06 18:47:13
そしていろんなパッチだらけになってお世辞にもsecureとはいえなくなっちゃうんですね。
102:名無しさん＠お腹いっぱい。
10/03/07 02:32:36
wsh
103:名無しさん＠お腹いっぱい。
10/03/07 08:52:59
ssh → sssh → ssssh …
今後の展開はこうだろ
104:名無しさん＠お腹いっぱい。
10/03/07 09:28:35
Secure SSHｷﾎﾞﾝ
105:名無しさん＠お腹いっぱい。
10/03/07 10:30:54
インセキュアな奴が使うから無理。
パスワード認証でパスワード保存したいとか、正気の沙汰とは思えない。
106:名無しさん＠お腹いっぱい。
10/03/07 13:05:25
>>103
ssh→ssh2→ssh2'→ssh2'turbo→superssh2→superssh2X→ssh4
107:名無しさん＠お腹いっぱい。
10/03/07 13:49:39
スーパー ssh 冒険の謎 2 でいいよ
108:名無しさん＠お腹いっぱい。
10/03/07 13:50:53
>>106
→ sshIV とか sshﾀｸﾃｨｸｽとか
109:名無しさん＠お腹いっぱい。
10/03/07 16:02:02
sshEXとssh0は
110:名無しさん＠お腹いっぱい。
10/03/07 19:35:54
Zssh
sshZZ
νssh
ssh-F91
111:名無しさん＠お腹いっぱい。
10/03/07 22:55:43
Ξssh も仲間に…
112:名無しさん＠お腹いっぱい。
10/03/07 23:26:27
続・ssh
続続・ssh
また又・ssh
新・ssh
ニュー・ssh
痛快・ssh
113:名無しさん＠お腹いっぱい。
10/03/07 23:29:58
あぶないssh
もっとあぶないssh
もっともっとあぶないssh
114:名無しさん＠お腹いっぱい。
10/03/07 23:34:46
もっともあぶないSSH
さらにあぶないSSH
115:名無しさん＠お腹いっぱい。
10/03/08 00:57:28
つまんないのでもういいです。
116:名無しさん＠お腹いっぱい。
10/03/08 16:33:56
嘘です、もっとやってください。
117:名無しさん＠お腹いっぱい。
10/03/08 21:11:22
knkssh
118:名無しさん＠お腹いっぱい。
10/03/10 21:53:41
openssh-5.4/5.4p1来たね。
119:名無しさん＠お腹いっぱい。
10/03/10 22:46:49
公開鍵認証が出来なくなった
120:名無しさん＠お腹いっぱい。
10/03/10 22:51:37
へぇ～
121:名無しさん＠お腹いっぱい。
10/03/10 22:52:20
ほぉ～
122:名無しさん＠お腹いっぱい。
10/03/10 23:04:03
公開鍵認証が出来ないなら、秘密鍵認証すればいいじゃない。
123:名無しさん＠お腹いっぱい。
10/03/11 01:14:28
えっ
124:名無しさん＠お腹いっぱい。
10/03/11 01:32:08
>>123
いじめんなよ
125:名無しさん＠お腹いっぱい。
10/03/11 01:37:00
ケーキを食べればいいじゃないネタに何いってんのっていうか
126:名無しさん＠お腹いっぱい。
10/03/11 01:42:43
もうひとひねり欲しいところ。
127:名無しさん＠お腹いっぱい。
10/03/11 01:45:22
むしろサイバーノーガード戦法で
128:名無しさん＠お腹いっぱい。
10/03/11 03:25:55
もしかしてGIF騒動の二の舞？
129:名無しさん＠お腹いっぱい。
10/03/11 12:19:55
>>119
英語でいいんでソース頼む
130:名無しさん＠お腹いっぱい。
10/03/11 12:22:11
ソースっていうか
>>119の環境でできなくなったって話じゃないの。
131:名無しさん＠お腹いっぱい。
10/03/11 15:47:16
単にプロトコル2がデフォルトになって、
敢えて設定しない限り1は使えなくなっただけじゃ
なかったっけ？
132:119
10/03/11 22:50:59
あぁ・・・うちだけか。ﾅﾝﾃｺｯﾀｲ
ssh-keygenで鍵セット作ったんだけど公開鍵がputtygen.exeで読み込めなかったんだ。
PuTTYの方で作らないとダメなのかなと、puttygen.exe作った公開鍵をssh-keygenで変換して接続を試みたんだけどNG
ChallengeResponseAuthenticationをコメントアウトすると接続そのものは出来るようになったんだけど
パスフレーズではなくパスワードの入力でないとダメだった。で、鍵認証出来なくなってる？って思ったんです。
sshd_configは5.3p1で使っていたのと全く同じ
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 2m
PermitRootLogin no
StrictModes yes
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RhostsRSAAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
133:名無しさん＠お腹いっぱい。
10/03/12 00:18:30
>>132
多分、鍵の置く場所変えたら直ると思う。
134:名無しさん＠お腹いっぱい。
10/03/12 19:50:51
AuthorizedKeysFile のところ%h付けなくなったんだっけ?
明示的に%h付けてみたら?
135:名無しさん＠お腹いっぱい。
10/03/13 05:23:41
RSAよりDSAの方がつおいんだな。
しらなカッタワ。
136:名無しさん＠お腹いっぱい。
10/03/13 11:42:41
DSAって1024縛りがなかったっけ?
137:名無しさん＠お腹いっぱい。
10/03/13 21:54:51
んなこたぁない
138:名無しさん＠お腹いっぱい。
10/03/14 14:13:18
現状のsshで使えるのは1024ビットのDSAだけでしょ？
URLﾘﾝｸ(marc.info)
反対にRSAのビット長の方は上限は決まってないんだっけ。
実際にはopensshだとssh-keygenで作成できる上限やsshが扱える限界が
あるみたいだけど何の制約からなんだろう。
ところで、うちのCore2Duoでためしにopenssl genrsa 65536を
実行してみたらCPU 50%しか使わないね。p,q同時に生成するような
パッチってないのかな？（需要ないか・・・）
139:名無しさん＠お腹いっぱい。
10/03/14 14:33:26
仕様上そうなってるけど、PuTTY の keygen では作れてしまう。
以前試したときには確か使えたと思う。
140:名無しさん＠お腹いっぱい。
10/03/14 14:44:53
ssh.com版は少なくとも2048bitを作れた気がする。
opensshが勝手に制限してるだけ？
141:名無しさん＠お腹いっぱい。
10/03/14 19:09:22
TeraTermの中の人が書いたまとめっぽいのがあった。
URLﾘﾝｸ(slashdot.jp)
142:名無しさん＠お腹いっぱい。
10/03/14 21:48:22
(L,N)=(2048,160)な中途半端なDSA鍵なら
長いRSA鍵の方がよっぽどましだと思うけど。
(L,N)=(2048,224)のDSA鍵使うにはSSHプロトコルの
拡張が必要なんでしょ？
143:名無しさん＠お腹いっぱい。
10/03/26 08:23:11
sshをつかってWindowsから接続しています。
nohupを使ってプログラムを実行したあと、ウインドウを閉じると、プログラムが終了してしまいます。
exitコマンドを使えば、切断したあともプログラムの実行は継続されます。
ウインドウを直接閉じた際もプログラムを継続する方法はないでしょうか?
144:名無しさん＠お腹いっぱい。
10/03/26 08:29:16
>>142
nohupは SIGHUPを無視するだけで、
ウィンドウ閉じた時にそれ以外のシグナルが来れば終了するわな。
すべてのシグナルを無視するラッパーをかますか、
てっとり早く setsidコマンドを使う方法もある。
145:名無しさん＠お腹いっぱい。
10/03/26 08:59:54
>>143
つ GNU screen
146:名無しさん＠お腹いっぱい。
10/03/26 12:15:39
普通screen
147:名無しさん＠お腹いっぱい。
10/03/26 12:24:14
この用途でscreenは牛刀。
148:名無しさん＠お腹いっぱい。
10/03/26 12:31:36
tmux
149:名無しさん＠お腹いっぱい。
10/03/26 13:17:52
>147
牛刀結構ではないか
ギロチンつかうよりはまし
150:名無しさん＠お腹いっぱい。
10/03/26 13:28:40
>>147
screen使うと何か問題が出るのか?
151:名無しさん＠お腹いっぱい。
10/03/26 13:43:00
debianをetch->lennyにしたらstoneがなくなったのでsocatにしたけど
こういうのが牛刀？
152:名無しさん＠お腹いっぱい。
10/03/26 13:43:29
ptyが無駄に消費される
153:名無しさん＠お腹いっぱい。
10/03/26 13:45:57
>>152
足りないの？
154:名無しさん＠お腹いっぱい。
10/03/26 13:47:16
×無駄に消費される
○有効に活用される
155:名無しさん＠お腹いっぱい。
10/03/26 13:48:30
wgetで済むのにfirefoxを起動するのが牛刀
156:名無しさん＠お腹いっぱい。
10/03/26 13:50:46
>>154
nohupの代替の場合、stdout/stderrはもともとファイルにリダイレクトされてるので、
ptyは無駄にしかならない。
setsidとかFreeBSDのdaemonとかはcontrol terminalを切り離すので
無駄にならない。
157:名無しさん＠お腹いっぱい。
10/03/26 13:51:13
牛刀のほうが使いなれてるなら牛刀でいいじゃん
158:名無しさん＠お腹いっぱい。
10/03/26 18:38:39
いやだから、ptyが無駄になって
何か問題があるのか?
そりゃ鳥をバラすのに牛刀使うのは
かえってやりにくかろうとは思うが
screen使って「特に問題が出ない」なら
別に構わんのでは?
159:名無しさん＠お腹いっぱい。
10/03/26 18:50:41
そこは触れてほしくないみたいだよ。
160:名無しさん＠お腹いっぱい。
10/03/26 19:22:26
> 「鶏を割くに焉んぞ牛刀を用いん」
> 小事を処理するのに、大掛かりな手段を用いることのたとえ。
「大掛かりな手段」と言うほどscreenは大掛かりか?
俺はわりと日常的に使ってるけど。
たかだか1、2行のメモを書くのにわざわざMS Wordを立ち上げる
みたいな話ならまだ分かるが。
screenだぜ? w
161:名無しさん＠お腹いっぱい。
10/03/26 19:24:21
MS Word を日常的に使ってれば
それは大掛かりにならんのでは
162:名無しさん＠お腹いっぱい。
10/03/26 19:43:57
screenはインストールされてるとは限らないから、
わざわざscreenをインストールしてから作業開始だとすると大がかりだな。
163:名無しさん＠お腹いっぱい。
10/03/26 19:48:50
それはまた話が別。
164:名無しさん＠お腹いっぱい。
10/03/26 19:51:09
>>161
ヘタすると実作業よりも起動待ちの方が長くなるような
という意味合いで書いたんだが。
作業内容に比して大掛かりな道具という。
165:名無しさん＠お腹いっぱい。
10/03/26 19:52:33
>>162
yumやaptの使い方知らないなら
確かに大掛かりな話になるかもね。
つか、そのレベルの人だったら
別の方法を採用したら
もっと大掛かりな話になりそうなw
166:名無しさん＠お腹いっぱい。
10/03/26 20:09:00
勝手にソフトを入れてはいけない客先のマシンとか、
社内だったとしてもインストール許可を申請すると日数がかかるものもあるわけで。
167:名無しさん＠お腹いっぱい。
10/03/26 22:39:08
>>164
もれは attach するだけだから爆速
168:名無しさん＠お腹いっぱい。
10/03/30 16:19:47
# SSHプロトコルの指定
Protocol 2
# rootでのアクセス許可
PermitRootLogin yes
# 接続を許可するユーザ
AllowUsers root
# セキュリティ設定
MaxStartups 2:90:5
LoginGraceTime 20
MaxAuthTries 3
port 22
# RSA公開鍵認証の有効化
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /etc/ssh/authorized_keys
169:名無しさん＠お腹いっぱい。
10/03/30 16:20:30
# パスワード認証無効化
PasswordAuthentication no
PermitEmptyPasswords no
RhostsRSAAuthentication no
ChallengeResponseAuthentication no
# ログのレベルを指定
SyslogFacility AUTH
LogLevel INFO
# パーミッションチェック
StrictModes yes
# その他
GSSAPIAuthentication no
GSSAPICleanupCredentials yes
UsePAM no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server
このような設定でsshに接続しているのですが、ユーザー権だとログインできないです。
なぜなのでしょうか？？
AllowUsers root は AllowUsers root hogehoge の間違いです。
170:名無しさん＠お腹いっぱい。
10/03/30 16:21:18
ログ見ないのかね。
171:名無しさん＠お腹いっぱい。
10/03/30 16:37:36
AuthorizedKeysFile /etc/ssh/authorized_keys
こんなデタラメな設定、誰に教わった?
172:名無しさん＠お腹いっぱい。
10/03/30 16:47:36
あれ、なんかデジャヴ?
173:名無しさん＠お腹いっぱい。
10/03/30 19:30:03
これは酷いw
174:名無しさん＠お腹いっぱい。
10/03/30 19:39:25
こういうバカは死んで欲しい。
URLﾘﾝｸ(d.hatena.ne.jp)
175:名無しさん＠お腹いっぱい。
10/03/30 20:31:37
>>174
いちおう「最終手段」って書いてるじゃん。
176:名無しさん＠お腹いっぱい。
10/03/30 23:56:23
何をやっているか理解せずに、全世界に公開する愚かな行為を言っているのだ。
177:名無しさん＠お腹いっぱい。
10/03/30 23:59:29
ブログに書かれた設定系のネタでまともなものを見たことがない。
178:名無しさん＠お腹いっぱい。
10/03/31 02:11:42
>>174
それ3行並べてるじゃん。
>>168のは一行しか書いてないじゃん。
なんで>>174の方を叩くべきって結論に？
>>177
ほう
179:名無しさん＠お腹いっぱい。
10/03/31 19:07:47
3:1で>>174の勝ち。
180:179
10/03/31 21:08:38
>>174の方が明らかに間違い
>>168はそれに騙された被害者
一日間に異論がなければそれで確定ね
181:名無しさん＠お腹いっぱい。
10/03/31 21:55:09
>>168
URLﾘﾝｸ(www.unixuser.org)
ｺｺ見てわからなかったら、ｸﾞｰｸﾞﾙさんに聞いてください。
182:名無しさん＠お腹いっぱい。
10/03/31 23:04:37
一日間に異論がなければそれで確定ね(ｷﾘｯ
183:名無しさん＠お腹いっぱい。
10/04/01 17:19:46
何をやっているか理解せずに、誰かが書いた設定をコピペして使うのも愚かな行為。
184:名無しさん＠お腹いっぱい。
10/04/05 19:44:17
どうしてもssh認証できなくて、2日間悩んだあげくやっと原因を発見した
作った.sshディレクトリの所有者がrootになってた
忘れないようにここに記録しておく
185:名無しさん＠お腹いっぱい。
10/04/05 19:53:15
ばーか としか言いようがない
186:名無しさん＠お腹いっぱい。
10/04/06 07:47:09
そんなこと普通起きないから忘れていいよ。
187:名無しさん＠お腹いっぱい。
10/04/06 21:43:11
いや、>>184 が記憶したいのが「所有者が root だから駄目だった」だったら
きっと同じようなことをまたやらかすに違いない
188:名無しさん＠お腹いっぱい。
10/04/07 11:24:55
>>187
?
他に何を記憶したいという可能性が?
189:名無しさん＠お腹いっぱい。
10/04/08 16:20:59
root だったからじゃなくて、所有者が違ったからだめなんだよ。
そういう記憶の仕方は良くない。
/root/.ssh の所有者がrootでも何の問題もないからな。
190:名無しさん＠お腹いっぱい。
10/04/08 16:43:10
それを言うなら「所有者が違って、かつotherに読み込み権限がなかったから」だろ
>>184は所有者の確認もせずにパーミッションだけは700とかに設定したわけだな
191:名無しさん＠お腹いっぱい。
10/04/08 16:54:06
>>190
違うよ。
「所有者が違ってotherに読み込み権限がある」状態では拒否されるよ。
192:190
10/04/08 17:17:26
/home/testuser/.ssh# ls -la
合計 12
drwx---r-x 2 root root 4096 2010-04-08 17:05 .
drwxr-xr-x 3 testuser testuser 4096 2010-04-08 17:05 ..
-rw----r-- 1 root root 395 2010-04-08 17:05 authorized_keys
試してみたけどこの状態ならtestuserでSSHログインできたぞ。
ここから chmod o-rx . ./authorized_keys するとログイン不可。
まぁ環境によるのかもしれないけど。
193:名無しさん＠お腹いっぱい。
10/04/08 21:03:08
drwx--x--x .
drwxr-xr-x ..
-rw------- authorized_keys
だろ常考
194:名無しさん＠お腹いっぱい。
10/04/08 21:10:03
そういう話はしていない。
195:187
10/04/08 22:18:50
俺が言いたかったのは「所有者が root だから駄目だった」という
個別の事例を記録しても意味がなくて、なぜ ~/.ssh の所有者を root に
してしまったのかの原因を詳らかにしておいた方がいいんじゃないの？
ってことだったんだけどね
平たく言うと、安易にスーパーユーザーで作業すんなってこと
196:名無しさん＠お腹いっぱい。
10/04/09 10:15:32
>平たく言うと
遠すぎるな
197:名無しさん＠お腹いっぱい。
10/04/09 10:23:15
いや
何度も書かれている
お前の目が節穴だっただけ
大抵の人はフィルタを通して物(この場合スレの書き込み)を見てしまう
大事なことが書かれていてもそれに気付くためには
本人がそれを受け入れるための準備が必要なんだ
198:名無しさん＠お腹いっぱい。
10/04/09 10:32:54
>>191
× 「所有者が違ってotherに読み込み権限がある」状態では拒否されるよ。
○ デフォルトでは所有者がroot以外の他人またはgoに書き込み権限有りの場合に拒否。
これほどあからさまな嘘は珍しい。
199:名無しさん＠お腹いっぱい。
10/04/16 17:26:34
opensshでログインするとサーバー側にTIOCSCTTYの引数が無効とでます
何が原因かわかりますでしょうか
200:名無しさん＠お腹いっぱい。
10/04/16 17:32:04
>>199
LANG=ja_JP.UTF-8 等にしているのが原因です。
LANG=C なら、ちゃんと
TIOCSCTTY: invalid argument
と出ます。
201:名無しさん＠お腹いっぱい。
10/04/16 17:39:01
>>200
失礼しました勝手に訳しました
ログインはできるので影響はないんですが気になるので調べてます
202:名無しさん＠お腹いっぱい。
10/05/13 21:33:11
一つ質問させて下さい。皆さんはSSHを用いて通信が暗号化された事をどのような方法で
確認していますか？
現在、
サーバ：windows2003server + cygwin(+openssh)
クライアント：windowsXP + teraterm
という環境でSSHポートフォワーディングを利用してリモートデスクトップ接続を
行おうとしており、実際に接続出来ていてリモートデスクトップが可能なのですが
経路が暗号化されているのかが判別出来ていません。
何か確認出来る方法、ツール等ありましたらご教示下さい。
203:名無しさん＠お腹いっぱい。
10/05/13 21:43:42
パケットキャプチャでも使ってみたらどうだろう
204:名無しさん＠お腹いっぱい。
10/05/13 21:50:06
ルータ経由でネットワーク分離して
間違って直結しようとしても出来ない構成にしておけばいいじゃん
205:名無しさん＠お腹いっぱい。
10/05/14 11:45:06
>>204
それだと「暗号化されてるかどうか」の
確認にはならんような
sshが信用できないから
自分の目で確認したい
ということかw
その批判精神には感じ入るが…
>>203しかないのでわ
tcpdumpとか?
206:名無しさん＠お腹いっぱい。
10/05/14 11:51:20
>>202
暗号化の確認にはならないけど、逆にリモートデスクトップの通常のポートに
接続されていないことをnetstatで確認するのはどうだろう。
207:名無しさん＠お腹いっぱい。
10/05/14 14:18:39
自分しかSSHでアクセスしないサーバでの話だが、
アクセスがあるとそのリモートアドレスだけをhosts.allow に記述するHTTPSのページを作って
そのページにアクセスしてから鍵認証でSSHにログインするようにした。
自宅からや出張先からもつなぐ必要があるけど、すごく楽になった。
ただ、もしapacheだけ落ちたりしたらお手上げなので、メール受け付けると、hosts.allowを sshd: ALL にする
メルアドとスクリプトも作った。
208:名無しさん＠お腹いっぱい。
10/05/14 20:13:48
>>205
tcpdumpの出力を目視だけでは正しく暗号化されてるかまでは判別できないと思う
>>207
それならiptablesの方が汎用的では？
209:名無しさん＠お腹いっぱい。
10/05/15 10:17:55
自分しかSSHでアクセスしないサーバでの話だが、
アクセスがあるとそのリモートアドレスだけを iptables に追加するHTTPSのページを作って
そのページにアクセスしてから鍵認証でSSHにログインするようにした。
自宅からや出張先からもつなぐ必要があるけど、すごく楽になった。
ただ、もしapacheだけ落ちたりしたらお手上げなので、メール受け付けると、iptables に追加する
メルアドとスクリプトも作った。
210:名無しさん＠お腹いっぱい。
10/05/15 14:18:11
メールサーバも落ちてたらお手上げなので、DNS query受け付けると、iptables フラッシュするためのRRとスクリプトも作った。ドメインも買った。
211:名無しさん＠お腹いっぱい。
10/05/15 16:39:38
面白いと思ってるのが痛い
212:名無しさん＠お腹いっぱい。
10/09/08 19:35:34
sshでトンネリングしてみたけれども、転送速度ってこんな遅いの？
FTPやVNCで20～30KB、squidのプロクシとかは一瞬120KBくらいは出たけど
CPUや光帯域がネックってわけじゃないみたいだし、ちょっと不満。
WindowsでOpenSSHとPuttyの組み合わせです
213:名無しさん＠お腹いっぱい。
10/09/08 22:03:31
トンネリングしない場合と比べてどうなの？
214:名無しさん＠お腹いっぱい。
10/09/09 00:18:25
トンネリング無しだと、FTPで3MB/s、
VNCでも動きが激しいとこで400kb/sくらいでる
ssh通すと帯域制限されてる感触で、30kb/sしか出ない
一つのサーバとクライアント2台で試して同じ感じ
普通はどのくらいスループットでるものですか？
もしこれで遅すぎるならソフト変えてみる
215:名無しさん＠お腹いっぱい。
10/09/09 01:31:41
サーバーは何？
216:名無しさん＠お腹いっぱい。
10/09/09 01:46:54
>>214
＞トンネリング無しだと、FTPで3MB/s、
この速度からして802.11gとかか？
あとFTPのSSHトンネリングはSOCKSサーバ方式？
どんな方式にせよそんなに落ちるのはおかしい。
暗号化方式をrc4やblowfishにすると速度出る。
217:名無しさん＠お腹いっぱい。
10/09/09 01:55:05
OpenSSH for Windows 3.8p1-1 20040709 Build
URLﾘﾝｸ(sourceforge.net)
一般的な家庭内LANで、ポート22開放してCorei3積んだWindowsXPに入れて動かしてる
SHH-2の公開鍵認証
回線はBフレッツハイパーファミリー
素直にLinux使えばいいんだろうけどね
218:名無しさん＠お腹いっぱい。
10/09/09 01:59:12
つまり回線は関係ないんだよね
219:名無しさん＠お腹いっぱい。
10/09/09 02:00:32
セキュリティソフトは？
220:名無しさん＠お腹いっぱい。
10/09/09 03:02:15
>あとFTPのSSHトンネリングはSOCKSサーバ方式？
サーバ側で転送用に再接続する待ち受けポートをいちいちトンネリング設定してた
今SOCKS5方式で試してみて、転送速度は変わらなかったけど、便利になった
ウイルスセキィリティゼロが気休めに入っているけれども、
全部無効にしても違いが無い
今はWindowsファイアウォールだけ動かしてる
PuttyだけじゃなくTera Termでも試したけれども変わらなかった
サーバ側見直すよ
221:名無しさん＠お腹いっぱい。
10/09/09 09:37:54
>>212
もしかして中国とか? 先月中国出張の際にsshトンネルを通すと耐えられないくらい遅くなったよ。
222:名無しさん＠お腹いっぱい。
10/09/09 21:02:14
ssh -q -n hostname dd if=/dev/zero bs=8M count=1 > /dev/null
223:名無しさん＠お腹いっぱい。
10/09/10 19:56:49
ダウンロードなのかアップロードなのかでCPUスペックがより必要なホストがどちらかが変わる。
それぞれのスペックは？
224:名無しさん＠お腹いっぱい。
10/09/10 20:02:28
あ、ごめんなさい、圧縮転送とかんちがいした。
共有鍵暗号だからそんなに計算量変わらないか。
225:名無しさん＠お腹いっぱい。
10/09/21 01:49:39
20MB/sくらいはデルよ
226:名無しさん＠お腹いっぱい。
10/11/12 23:54:21
authorized_keys と authorized_keys2 ってどういう違いがあるの？
バージョンや暗号化方式によって違うらしいけど
なんでそんなことするの？
227:名無しさん＠お腹いっぱい。
10/11/13 00:38:50
authorized_keys に version2 のキー置いても問題なく動いてるけど
228:名無しさん＠お腹いっぱい。
10/11/13 10:01:45
>226
openssh と本家で仕様が違ってる(or 違ってた; 最近の事情は知らない)
229:名無しさん＠お腹いっぱい。
10/11/13 15:32:38
確かに本家とは仕様が違ってる/違ってたけど、authorized_keysとauthorized_keys2って違いじゃないはずだぞ。
230:名無しさん＠お腹いっぱい。
10/11/13 20:43:41
結局authorized_keys2は互換性のために残っているんだっけ？
authorized_keysが使えない条件は何？
231:名無しさん＠お腹いっぱい。
10/11/13 21:48:36
リンクしとけよ
232:名無しさん＠お腹いっぱい。
10/11/13 22:31:54
【新世代】 Windows 7 Part70
ｽﾚﾘﾝｸ(win板:783番)
783 名前：名無し~3.EXE[sage] 投稿日：2010/11/10(水) 22:34:10 ID:Rr0vNFYE
Windows 7 クライアントだと Loopback でもポートがかちあって
ssh トンネル越しの Windows 共有 (SMB ove SSH) が自分はできてなかったが
良い解説を見つけてできるようになった
CIFS-over-SSH for Windows Vista/7
URLﾘﾝｸ(www.nikhef.nl)
キーワード:
CIFS over SSH (445/tcp)
Microsoft Loopback Adapter
sc config smb start= demand
netsh interface portproxy add v4tov4
net start smb (後から実行)
445 じゃなく proxy ポートに接続
あとは cygwin の openssh でOK
233:名無しさん＠お腹いっぱい。
10/11/22 21:44:26
鍵認証パスフレーズなしで長いことやってきたが
秘密鍵の保存場所って本気で考えると難しくないか？
普段入るサーバはsudo使えるやつが他にも数人いるし、
会社から提供されたPCもイントラチームにはdomain adminで筒抜け状態。
おいおい、いつ盗まれてもおかしくない状態！！・・・なんだけど
周りには「鍵認証って何？」って人しかいないから助かってるｗ
そもそも会社でパスフレーズなしは無謀？
しかし、パスワード毎回は面倒すぎる。
こういう場合はssh-agentかねやっぱ。
これはこれで面倒そうなんだよな。
皆どうしてるの？
234:名無しさん＠お腹いっぱい。
10/11/22 21:52:07
パスなし鍵でどのホストに繋がるのかが判らないようにしておけばよい
さらに同様の鍵が複数(沢山)あるとセキュリティ効果うｐ
235:名無しさん＠お腹いっぱい。
10/11/22 22:41:50
パスなし鍵をたくさん用意して、ホストごとに変えろってこと？
まあ、時間稼ぎにはなりそうだけど。。。
何百台もあるしなぁ。
236:名無しさん＠お腹いっぱい。
10/11/22 23:33:27
(´-`).｡oO 周囲の人間が信用できないのにどうしてパス無し鍵を使うのだろう
237:名無しさん＠お腹いっぱい。
10/11/23 00:30:37
セキュリティと利便性が相反するのはわかる。
しかし、日々数十回ssh,scpするのに毎回パス入力。。。耐えられん。
だからこそ、安全なパスなし鍵運用を追及したい。
238:名無しさん＠お腹いっぱい。
10/11/23 00:39:49
なんのためにssh-agentがあると思ってるんだ?
239:名無しさん＠お腹いっぱい。
10/11/23 01:08:00
URLﾘﾝｸ(webos-goodies.jp)
他人が root ユーザーとしてログインできるマシンでは ssh-agent は使うべきではありません。
ってのを読んで不安になったんで。
240:名無しさん＠お腹いっぱい。
10/11/23 02:05:03
rootしか見れない場所に置くしかないけど
みんながrootで入れる環境だと意味ない罠
241:名無しさん＠お腹いっぱい。
10/11/23 13:49:11
>>239
パスなし鍵の方がよっぽど危険
242:名無しさん＠お腹いっぱい。
10/11/23 15:34:51
パスなし鍵（複数）をローカルに暗号化して保存しておいて
それらをssh-agentでひとつのパスワードで管理って出来ない？
243:名無しさん＠お腹いっぱい。
10/11/23 17:39:16
> しかし、日々数十回ssh,scpするのに毎回パス入力。。。耐えられん。
こういう意識でいる限り何を言っても無駄だな
244:名無しさん＠お腹いっぱい。
10/11/23 18:13:49
USBメモリに暗号化しておいとく
245:名無しさん＠お腹いっぱい。
10/11/23 18:46:04
っていうか ssh-agent 使ってみれば
「一日一回」で済むってことが分かるのに
246:名無しさん＠お腹いっぱい。
10/11/23 18:52:14
>>243
そこをなんとかｗ
業務委託が切られちゃったから、やらざるを得ないけど、
単調作業が嫌いなので、とにかく楽にしたい。
>>244
暗号化はすでにやってる。truecryptでイメージ保存してて
出社したら、.ssh/にマウントさせてる。
でも、マウントした時点でsudoもってる奴らには見えてしまう。
247:名無しさん＠お腹いっぱい。
10/11/23 18:56:50
パスなしよりは安全だから、ssh-agentにしますわ。
ただ、
URLﾘﾝｸ(www.gcd.org)
にもあったけどやっぱ他人がroot使える環境では
安全とは言えないんだよね？
248:名無しさん＠お腹いっぱい。
10/11/23 19:03:24
そんなの当然でしょ。
ssh信頼できないデバイスが信頼できな
249:名無しさん＠お腹いっぱい。
10/11/23 19:06:33
すません、書き込み失敗した。
sshクラアントごと差し替えられたり、
キーロガーしこまれたりできるデバイスだったら
秘密鍵のパスフレーズだって抜けるでしょ。
250:名無しさん＠お腹いっぱい。
10/11/23 19:23:24
そうですよね。。
ってことは俺の環境でパスなし鍵の安全性確保は難しそうだ。
vmwareで解決しそうだけど、禁止だし。。。
厳しいなぁ。
251:名無しさん＠お腹いっぱい。
10/11/23 19:46:02
ん？>>247の引用URLはForwardAgentでの話か。
イントラチーム筒抜けとかいってたからローカルの話の
続きかと思った。この場合は秘密鍵そのものは覗き見できない。
まあ仮にクライアント側で秘密鍵の機密性が守れたとしても
ログイン先sshdに罠を仕込めるようなサーバ環境なら通信内容の
盗聴はできるよ。
とことん防衛するつもりならSSHクライアント／サーバ管理者以外にも
DNSサーバ管理者やIPルータ管理者の警戒もお忘れなく。。。
252:名無しさん＠お腹いっぱい。
10/11/23 22:55:09
>>246
>暗号化はすでにやってる。truecryptでイメージ保存してて
>出社したら、.ssh/にマウントさせてる。
そうじゃなくて使う瞬間だけメモリ上で復号するんだよ
253:名無しさん＠お腹いっぱい。
10/11/23 23:21:57
>>251
なるほど、盗まれることはないってことか。
まあ盗聴は気をつけるしかないかな。
今回は、パスなし秘密鍵はちゃんと管理せよってよく言うけど、
みんなはどうしてるのかなと思っただけだよ。
>>252
使うたびに複合は面倒じゃない？
ちなみにUSBは使えない。
254:名無しさん＠お腹いっぱい。
10/11/24 00:26:21
正直マニュアルくらい読んでからにしてくれ…
255:名無しさん＠お腹いっぱい。
10/11/24 10:28:49
社内の root が信用できないって、
どんな仕事やってんだ？
256:名無しさん＠お腹いっぱい。
10/11/24 11:36:54
仕事じゃない内職だから社内の人を信用しないんじゃないか。
257:名無しさん＠お腹いっぱい。
10/11/24 12:27:16
おまえはクビだ
258:名無しさん＠お腹いっぱい。
10/11/24 12:39:33
お前が信用されてないから他人も信用しないってことか。
259:名無しさん＠お腹いっぱい。
10/11/24 20:52:07
>>255
俺もそれ思ったw
信頼できないやつにroot権限与えてるのが
そもそも一番の問題なんじゃねーか。
それ前提だと何やっても無駄だろう。
260:名無しさん＠お腹いっぱい。
10/11/24 22:15:00
俺も>>256と同意見、見られるとまずいことやってるんじゃないか？
261:名無しさん＠お腹いっぱい。
10/11/25 12:46:55
どこぞのエロ掲示板のおじさんが
「職場でダウンローダセットしてゲットしました～」
って書いてるようなそういう話じゃね?
もっとヤバい機密の横流しとかならパスワードを
打つくらいのは厭わないだろうし
262:名無しさん＠お腹いっぱい。
10/11/25 21:46:29
うちは外部接続有りの実運用中の機器へのアクセスは
単独作業禁止、パスワードも再監者と確認しながら入力で
毎日他の担当者がアクセス履歴をチェックしてる。
当たり前のことだから別に面倒だとは思わんな
263:名無しさん＠お腹いっぱい。
10/11/25 22:35:41
アクセス履歴が残ると思ってる時点で問題だけどな
264:233
10/11/25 22:45:30
なんか、大量レスどもです。
そんな重要作業ではなく、ほとんど監査がらみのログ収集とか
ldap未導入サーバのアカウント一覧取ったりとか、そんな依頼。
サーバ一覧渡されて、scpで取るだけだけど、楽したいじゃない。
とりあえずssh-agentに変えたから、これでパスなし鍵を置きっぱなしよりは
ましになったか。sudo可の奴らは信頼することにする。
265:名無しさん＠お腹いっぱい。
10/11/25 22:55:49
> 1. ssh-agent を使うとパスフレーズ入力省略出来る。
> 2. ssh-agent を普通に使うだけでは便利性が高くない。
> 3. keychain は ssh-agent をもっと便利にしてくれるツール。
> 4. keychain を導入すればパスフレーズ入力が PC 起動につき一回で済む。
> 5. keychain を使えば複数 ssh-agent を起動する必要がなくなる。
266:マーフィ
10/11/28 03:54:00
>>257
Thank you.
267:名無しさん＠お腹いっぱい。
10/11/28 13:30:26
XPを使用しています。
URLﾘﾝｸ(www.gadgety.net)
のインストール手順で詰んだのですが、スーパーユーザーで作業するにはどのような操作を行えば良いでしょうか。
268:名無しさん＠お腹いっぱい。
10/11/28 14:56:13
su
269:名無しさん＠お腹いっぱい。
10/11/28 15:22:11
XPってWindows XPのこと?
スーパーユーザーって何のことだ?
administratorのことか?
Windowsから別のOSにログインするって話なら
その相手が何でどういう設定になってて
何をやりたいのか書かんと
270:名無しさん＠お腹いっぱい。
10/11/28 23:18:26
"su" is not Super User.
271:名無しさん＠お腹いっぱい。
10/11/28 23:21:34
Substitute User
272:名無しさん＠お腹いっぱい。
10/11/30 13:18:27
switch userだと思ってたｗ
273:名無しさん＠お腹いっぱい。
10/11/30 18:47:41
super
274:名無しさん＠お腹いっぱい。
10/12/02 08:10:56
URLﾘﾝｸ(www12.atwiki.jp)
275:名無しさん＠お腹いっぱい。
10/12/02 15:05:36
SSHのスレで延々引っ張るネタじゃないな
276:名無しさん＠お腹いっぱい。
10/12/11 02:57:10
にょろん
277:名無しさん＠お腹いっぱい。
10/12/11 19:10:00
>>265
パスフレーズ入力を何回かすることになってでも、俺は
gpg-agent --enable-ssh-supportの方がいいやｗ
278:名無しさん＠お腹いっぱい。
11/01/22 11:01:24
ssh brute force attacksに対する防御で、
OpenSSHのsshdで同一ホストからInvalied userなログイン要求があった場合に
外部プログラムを起動したいんだけど、何か方法ある?
maxlogins.plのようにsyslogを読む方法はローカルなユーザがlogger使って
悪戯できるので、イヤです。
279:名無しさん＠お腹いっぱい。
11/01/23 00:34:30
>同一ホストからInvalied userなログイン要求があった
現状これを把握するには log 見るしかないんじゃない？
280:名無しさん＠お腹いっぱい。
11/01/23 00:59:47
>>278
ソースいじるしかないんじゃね？
その程度ならすぐ追加できそう
281:名無しさん＠お腹いっぱい。
11/01/23 01:34:58
>>278
swatchかsyslog-ngあたりを使うのが普通では
syslogを読む、ってのはよく分からんが
syslogdが出力したlogファイルを読む、という意味か?
少なくとも後者なら「出力」ではなく「入力」に対応して
外部コマンド起動させることはできるよ
syslogdの置き換えだから
俺はsyslog-ngで
「同一ホストから1分間に3回ログイン失敗したら30分遮断」
なスクリプトを起動させてる
以前はswatch使ってたけど、時々変な挙動起こしてたんでやめた
282:名無しさん＠お腹いっぱい。
11/01/23 01:47:03
> syslogを読む
syslog.confでパイプすることも含みます。
ローカルユーザーがloggerで悪戯できるということは、侵入者が
これを悪用して管理者のログインを邪魔することが可能になるの
で使いたくないのです。
(侵入されたときに制御を奪い返せなくなる)
283:名無しさん＠お腹いっぱい。
11/01/23 01:51:22
あ、logger使って云々とあるから「出力」だけの話じゃねーのか。
と書こうとしたら既にw
sshdの設定変えてログ出力を非標準のfacilityに変えちゃえば
ルート権限持ってないユーザには分からんだろう。
そもそもそんな馬鹿にローカルから使わせるのがいけないんじゃね?
とも思うが。
284:名無しさん＠お腹いっぱい。
11/01/23 02:26:50
> ローカルユーザーがloggerで悪戯できるということは、侵入者が
> これを悪用して
んんん??
馬鹿ユーザじゃなくて「侵入者」がローカルで操作するの?
「ローカル」ってのはリモートではなく実機のコンソールでの操作って意味だよね?
どういう状況を想定しているのかイマイチ分からない…
実機を直接いじれる侵入者(あるいはその協力者)を想定するんじゃ
24h常駐ガードマン雇う等の物理的なセキュリティを厳重にするしか
根本対策にならんように思えるが
285:名無しさん＠お腹いっぱい。
11/01/23 02:34:35
侵入者(あなたはその協力者)
に見えた
頭腐って来てるかも・・・
286:名無しさん＠お腹いっぱい。
11/01/23 02:53:18
> ssh brute force attacksに対する防御で、
防御ならパスワード認証不可にすれば解決では。
色々複雑な状況考えてる一方でノーガードに近いパスワード認証前提というのがチグハグに見える。
287:名無しさん＠お腹いっぱい。
11/01/23 06:57:23
ログがうざいんぼるとだろ
288:名無しさん＠お腹いっぱい。
11/01/23 08:53:42
制御取り返すなんて、一度侵入された時点でアウトだろ
289:名無しさん＠お腹いっぱい。
11/01/23 12:27:56
pam_access.soとpam_tally2.so参考にPAMモジュール自作
290:名無しさん＠お腹いっぱい。
11/01/23 21:15:19
>>284
侵入されて任意のコマンド実行可能な状態になったことをローカルユーザと
表現しました。
>>286
sshは公開鍵認証だけです。その上で侵入された場合を想定しています。
>>288
当該サーバが地理的に離れているので、侵入されたことが判明したら、
到着する前にシャットダウンできる備えはしておきたいのです。
291:名無しさん＠お腹いっぱい。
11/01/23 21:25:22
>>290
侵入された時点で物理的に電源を切る以外何をやっても無駄。
そこまで心配するならSELinuxなどを使いなよ。
292:名無しさん＠お腹いっぱい。
11/01/23 21:46:08
>>290
侵入の証跡取るためにはシャットダウンもよろしくないんだよね
うちだったら緊急時は接続してるSW側でport落とすかな
(そして俺が侵入者なら無通信になったらファイル消しまくるように
仕掛けるだろうｗ)
293:名無しさん＠お腹いっぱい。
11/01/23 22:49:31
>>291
> 侵入された時点で物理的に電源を切る以外何をやっても無駄。
侵入されても、rootを取られてなければ奪還の可能性はあります。
たとえrootを取られても、ログインできればシャットダウン出来る
可能性はありますが、ログインできなければその可能性は0ですよね。
>>292
> 侵入の証跡取るためにはシャットダウンもよろしくないんだよね
放置するよりはシャットダウンを選びます。踏み台にされて犯罪に
使われたりしたら面倒ですから。
> うちだったら緊急時は接続してるSW側でport落とすかな
零細なんでリモートで落とぜるSWは無理です。
294:名無しさん＠お腹いっぱい。
11/01/23 23:19:09
>>290
> sshは公開鍵認証だけです。その上で侵入された場合を想定しています。
どういう状況で「その上で侵入」が可能になるのか説明plz
・サーバは遠隔地にある……これは普通
・sshは公開鍵認証のみである……brute forceで破られる心配ゼロ
・それでも、もし入られたら制御を奪われる恐れがある……????
前提がそもそも成り立ってないでしょ。
公開鍵認証使っている以上、秘密鍵が漏洩しない限りsshでの侵入はない、というのが通常の前提。
それを突破してくるｽｰﾊﾟｰﾊｶｰを相手と想定してるなら、何やっても無駄だよ。
君の力の及ぶ相手ではないからあきらめろ、としか。
295:名無しさん＠お腹いっぱい。
11/01/24 00:01:01
秘密鍵まで公開してるとか鍵長4bitとか
296:名無しさん＠お腹いっぱい。
11/01/24 00:05:05
> どういう状況で「その上で侵入」が可能になるのか説明plz
sshdのバグ、httpdとか他の経路。クライアントへの攻撃。
297:名無しさん＠お腹いっぱい。
11/01/24 00:08:19
Debianのウンコパッチが当たった状態で作った公開鍵もヤバイんだよな。
ま、それはともかく対策が過剰な気はする。
ipfw/iptablesなどで接続元を絞るとか、別のレイヤでの対策を考えるべき。
298:名無しさん＠お腹いっぱい。
11/01/24 00:36:23
接続元はtcp wrapperでjp限定に絞ってあります。
jpからの攻撃に対する対策として、maxlogins.plを使おうとしたけど、
「待てよ、ログイン出来なくされる」と思い直しての質問です。
299:名無しさん＠お腹いっぱい。
11/01/24 00:38:13
>>298
tcp wrapperで逆引きを使うとか、10年前の対策だな。
300:名無しさん＠お腹いっぱい。
11/01/24 00:48:41
他にjpで絞る方法ありますか?
301:名無しさん＠お腹いっぱい。
11/01/24 00:50:15
パケットフィルタはpfです。
302:名無しさん＠お腹いっぱい。
11/01/24 01:19:40
いい加減スレ違いじゃないか?
全然sshの話じゃなくなってるぞ
「httpdとか他の経路」ってのは何なんだよw
303:名無しさん＠お腹いっぱい。
11/01/24 01:48:10
>>298
> jpからの攻撃に対する対策として、maxlogins.plを使おうとしたけど、
> 「待てよ、ログイン出来なくされる」と思い直しての質問です。
「ある特定の条件に関しては遮断を行わない」ようなスクリプトにしとけばいいだけなんじゃないの?
管理者が直近のログインに使ったIPアドレスは除外する、とか
そこまでいろんなパターン考えてるわりに他人が作ったそのまま使うの前提ってのがよく分からん
自分に都合がいいのを自分で作りなよ
304:名無しさん＠お腹いっぱい。
11/01/24 01:58:37
つか途中から>>278と質問が変わっとる
brute forceの話はどこへ行った? w
OSが何かも分からんし前提条件も途中で変わるのでは話が
305:名無しさん＠お腹いっぱい。
11/01/24 08:09:36
質問者が侵入されroot盗られたというわけ
306:名無しさん＠お腹いっぱい。
11/01/24 09:11:29
>>303
> 「ある特定の条件に関しては遮断を行わない」ようなスクリプトにしとけばいいだけなんじゃないの?
> 管理者が直近のログインに使ったIPアドレスは除外する、とか
自分の利用条件に合う方法が思いつきません。詳細を説明するのも面倒だし、
全部を網羅できず、条件後出しになる可能性が高いので、スクリプトの改造
に関する話題は、これ以上はやめます。
加えて、メッセージの全部を偽造可能なので、それを見破るのも面倒。
>>304
sshdに対する攻撃は
1) ユーザ名を辞書攻撃で得る。
2) そのユーザ名に対してパスワードを辞書攻撃。
という手順です。
1)の段階で検出できれば、2)が(sshdの穴をついて)公開鍵認証を突破する手法に
進化した場合にも防御することが可能です。
1)の段階でsshdの穴をつつかれる可能性は残りますが、対策する方がセキュア。
まとめます
・maxlogins.plに類する、syslogdに送られる情報を元に、sshdへの攻撃を防御する
手法は非特権ユーザがサービス停止攻撃を実行可能。
・これに代わる確立された方法は現在のところ無し。
307:名無しさん＠お腹いっぱい。
11/01/24 09:31:46
>>306
syslogdにネットワークからメッセージ送れますね。(設定されてれば)
しかも(UDPなので)IPアドレスも偽造できる。
308:名無しさん＠お腹いっぱい。
11/01/24 14:08:18
ipfw/iptablesからキックして、syslogを参照すれば良いだけじゃないんかい？
まあ、多少作り込みは必要だろうけどそんなに難しい事だとは思わんけど。
309:名無しさん＠お腹いっぱい。
11/01/24 15:07:03
それよりも、syslogd改造してメッセージ送信元のuid取ってくるのが
手っ取り早くて確実かと思いました。(solarisでいう)
で、それをsyslog-ngに組み込もうとしたらsysutils/syslog-ng*がコ
ンパイルできねーでやんの。(事情により今すぐportsを最新版にできない)
310:名無しさん＠お腹いっぱい。
11/01/24 15:09:01
> (solarisでいう)
ゴミが残りました。気にしないでください。
311:名無しさん＠お腹いっぱい。
11/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
312:名無しさん＠お腹いっぱい。
11/01/24 18:22:16
>>311
わろうた
313:名無しさん＠お腹いっぱい。
11/01/24 18:29:21
まぁどういう方法でもいいけど、プログラム実行はCPUやディスクI/Oのコストが高いから、ヘタするとそれ自身がDoSになる可能性があるので、気をつけてな。
314:名無しさん＠お腹いっぱい。
11/01/25 00:23:01
>>306
> sshdに対する攻撃は
> 1) ユーザ名を辞書攻撃で得る。
> 2) そのユーザ名に対してパスワードを辞書攻撃。
> という手順です。
> 1)の段階で検出できれば、2)が(sshdの穴をついて)公開鍵認証を突破する手法に
1)の段階ではまだ突破されてないんだからloggerでどうのこうのってのは起こらない。
そして「1)の段階で検出」は既知の方法で十分対応可能。
1)の段階で「完全に遮断」すりゃその先の話は「まず起こり得ない物語」でしかない。
「まず起こり得ない物語」のために必死に対策打つのは
「まったく価値がない」とは言わんが、ちょいと馬鹿げてないか?
傍目には「空が落ちてきたらどうしよう」って悩んでる人と変わらんように見える。
大丈夫。
「公開鍵認証を突破する手法」とやらが広まる頃には、それに対するパッチもちゃんと出てるよw
315:名無しさん＠お腹いっぱい。
11/01/25 00:30:28
>>314
> 1)の段階ではまだ突破されてないんだからloggerでどうのこうのってのは起こらない。
別経路からの侵入を想定と書いた。何度も書かせないでよ。面倒だな。
316:名無しさん＠お腹いっぱい。
11/01/25 01:57:00
>>315
どれがお前さんの書き込みだか他人のチャチャだか分からんよ
名前欄に何も入れてない上にこの板はIDも出ないし
続けたいならコテハンにしたら?
本来なら「もっとふさわしいスレ」に移動すべきだろうと思うけど
317:名無しさん＠お腹いっぱい。
11/01/25 02:17:43
もう面倒だから
「自分のアカウントがログイン不可にされてたら問答無用でネットワーク断」
になるように設定しとけば?
手法はいろいろ考えられると思うが
318:名無しさん＠お腹いっぱい。
11/01/25 23:50:18
>>317
却下です。理由は… 面倒くさいから上の方読んで。
319:名無しさん＠お腹いっぱい。
11/01/26 18:08:54
鍵認証のみで十分じゃん
320:名無しさん＠お腹いっぱい。
11/01/26 18:18:28
> maxlogins.plのようにsyslogを読む方法はローカルなユーザがlogger使って
> 悪戯できるので、イヤです。
侵入者にルート権限を奪われていない状況で、これって本当に可能なんでしょうか?
管理者のユーザ名も使用しているIPアドレスも分からない状態ですよね?
もちろん「無差別に全部塞ぐ」は簡単だけど自力では「開け直す」ができないんだから
意味がないような気がするし。
321:名無しさん＠お腹いっぱい。
11/01/26 18:19:34
それ以前に、踏み台等にすることを考えて侵入した場合
侵入していることが管理者に気づかれないようにするのが普通だと思うのだけど。
管理者を締め出すようなことしたら普通はすぐに対策取られちゃいますよね。
直接コンソール操作して。
苦労して侵入したのに、明かに「侵入してますよ～」って言いふらすような
馬鹿なことをわざわざするかな。
322:名無しさん＠お腹いっぱい。
11/01/26 20:06:18
>>318
で、結局のところどうするんだ？これでもまだ「自分の望む答えが出てない」と言うなら、
おそらく自分で方向性決められないので素直に鍵認証にしとけ。
323:名無しさん＠お腹いっぱい。
11/01/26 20:43:24
>>320-321
他ユーザのログイン記録の管理は普通ルーズですよ。lastなどでわかる場合が多い。
maxlogins.plはホスト毎にアクセス制御なので、ユーザ名は不要ですね。
>>322
面倒だから上の方読んで。
324:名無しさん＠お腹いっぱい。
11/01/26 21:40:13
>>322
やっぱりキミ頭弱いそうだから説明してあげる。
>>309(syslogd改造)が現在の結論。
325:名無しさん＠お腹いっぱい。
11/01/26 22:04:55
>>324
全然結論になってないんだけど(笑)。
したり顔で言われたくないなぁ、馬鹿には。
326:名無しさん＠お腹いっぱい。
11/01/26 22:46:45
>>325
完璧になってるよ。
syslogdでメッセージ投げてきたプログラムのuidを取得すれば、
sshd(root)とlogger(非特権ユーザ)が区別できるので悪戯されない。
327:名無しさん＠お腹いっぱい。
11/01/26 23:07:30
ローカルユーザのいたずら対策と、外部のアタッカーからの対策がごっちゃになってるのが悪い。
・不要なサービスを立ち上げない、提供するホストを分ける
・不要なユーザを受け入れない
・二要素認証と承認の仕組み
などの基本から考え直せ。
328:名無しさん＠お腹いっぱい。
11/01/26 23:18:36
>>327
そう思うのは頭が弱いキミだけだよ。syslogd改造で完了だよ。
どんなに間抜けな事言ってるか教えてあげる。
> ・不要なサービスを立ち上げない、提供するホストを分ける
sshdとhttpd提供するホストを分けたら、httpdのホストはどうやって
保守するのでしょうか?
> ・不要なユーザを受け入れない
だからmaxlogins.plのような仕組みが必要。でもsyslogdが今のままではダメ。
> ・二要素認証と承認の仕組み
ハードウエアトークン使った秘密鍵認証ですが、何か?
329:名無しさん＠お腹いっぱい。
11/01/26 23:31:23
httpdの保守ならiptablesで1ホスト・1ユーザに絞ればいいじゃん
CMS使えば他のユーザをシェルまでログインさせる必要もない
あれもこれもいいとこ取りしようとして、要件が発散してるのがそもそもの問題ｗ
330:名無しさん＠お腹いっぱい。
11/01/26 23:33:51
役所とか大学とかにありがち。
331:名無しさん＠お腹いっぱい。
11/01/26 23:47:33
>>293
> 零細なんでリモートで落とぜるSWは無理です。
って言ってたのに、
>>328
>ハードウエアトークン使った秘密鍵認証ですが、何か?
こんな金のかかるもの導入してる。
ほんとに同じ人？
332:名無しさん＠お腹いっぱい。
11/01/26 23:50:09
>>331
途中から変なのが参戦してるね。
syslogdなんて亜種がいくらでもあるし、syslogdが問題だと思うなら
余所の適切なスレへ移動して欲しい。
333:名無しさん＠お腹いっぱい。
11/01/27 00:03:46
>>331
OpenPGPカードだから安いよ、15ユーロくらいだったかな。
amazonの安売りの1000円カードリーダーだし。
334:名無しさん＠お腹いっぱい。
11/01/27 00:22:39
>>329
偉そうに分離しろとか言って、httpdとsshdは分離できないんじゃん。
335:名無しさん＠お腹いっぱい。
11/01/27 00:32:15
>>334
daemonとしての「サービス」は複数動かさざるを得ないが、
ユーザに提供する「サービス」はhttpdとsshd両方提供する必要は無い
必要が無いソースホスト・ユーザからは到達させないようにするのはセキュリティの基本中の基本
336:名無しさん＠お腹いっぱい。
11/01/27 00:43:55
おまえら、もう釣りにマジレスやめれ。
2,3万からのインテリスイッチすら買えないのに、ハードウェアトークンなんて面倒なものいれる零細企業がどこにあるんだよ。
脳内零細企業の管理者様はセキュリティ板にでもお帰りいただけばおｋ。
337:名無しさん＠お腹いっぱい。
11/01/27 01:27:53
・他サービスのセキュリティには無頓着なのにSSHまわりのDoSには異常にこだわる
・侵入されないことより、侵入後の対策が重要
・syslog改造すると表明したのにいつまでSSHスレに居座るの？
・他人の提案は何でも却下
ま、釣りじゃなければ精神異常だ罠
338:名無しさん＠お腹いっぱい。
11/01/27 01:34:41
>>335
sshdとhttpdが同一ホストで動かしているという前提しか提示してない
(それでどんなサービスを提供しているかは提示していない)のに
余計な憶測で
> ・不要なサービスを立ち上げない、提供するホストを分ける
と、間抜けなアドバイスしたって事だね。
>>336
外からログインさせるためにはハードウェアトークンは必須。
OpenPGPカードは(カード(15ユーロ)+リーダー(1000円))/1名
ランニングコスト0。全然面倒じゃない。
安定して購入できるかという問題はあるけど、零細はフットワー
ク軽くて小回り効くから、ディスコンになったら考えればいい。
インテリスイッチは無けりゃ無くて済む。
そのわりに設置場所やランニングコストもかかる。
全然矛盾しないんだなあ。
339:名無しさん＠お腹いっぱい。
11/01/27 01:59:17
>>337
> ・他サービスのセキュリティには無頓着なのにSSHまわりのDoSには異常にこだわる
他サービスに関してはここでは話題にしていないだけ。
> ・侵入されないことより、侵入後の対策が重要
侵入されない事に関しては、ユーザー名総当たり攻撃に対する防御が残っている。
これ以外は対策済み。
> ・syslog改造すると表明したのにいつまでSSHスレに居座るの？
.jp以外を拒否する方法として、tcp wrapperが古いというので、
代わる方法を聞いたけど、まだ答えがない。
あと、>>311は、釣りだったけど、PAMを使うというのは新鮮なアイデアだった。
そういうのが出てくるかもしれない。
> ・他人の提案は何でも却下
接続元限定しろ、パスワード認証やめろ、二要素認証しろ、とか
聞いてもいない、しかも対策済みの提案と、上の方のレス読まずに
書きなぐったまぬけな提案しか出てこねーんだもん。
340:名無しさん＠お腹いっぱい。
11/01/27 06:58:45
あー今日も大漁大漁♪
341:名無しさん＠お腹いっぱい。
11/01/27 10:03:20
sshd止めてシリアルからログインすればいいべ。
メンテするときはシリアルポートに繋いだモデムに電話掛ければOK。
342:名無しさん＠お腹いっぱい。
11/01/28 04:50:40
>>341
WarGamesを思い出した。
343:名無しさん＠お腹いっぱい。
11/01/28 12:34:44
>>339
> 上の方のレス読まずに
だから、どれがお前の書き込みだか
他の人には分かんねーんだっつーのw
ここにいるのが全員エスパーだと思ってんのか?
なんでコテハンにしないんだよ
釣られちまった
344:名無しさん＠お腹いっぱい。
11/01/28 12:46:01
>>343
そういうお前は誰なんだよ。
345:名無しさん＠お腹いっぱい。
11/01/28 12:50:26
>>343
その理屈なら、
> ・他人の提案は何でも却下
却下したのも誰だか判らないじゃないか。ｗ
346:名無しさん＠お腹いっぱい。
11/01/28 14:06:56
>>342
古いね～
347:名無しさん＠お腹いっぱい。
11/01/28 14:10:03
war dialerでやられる。
348:名無しさん＠お腹いっぱい。
11/01/28 17:28:01
>>347
管理者じゃない番号からの着信はPBXで止めろよ。
349:名無しさん＠お腹いっぱい。
11/01/28 21:00:29
オレオレ
350:名無しさん＠お腹いっぱい。
11/01/29 10:40:26
>>344-345
問題になってるのは「どれが質問者の発言か分からない」という話だろ
「他人」は何人いようと問題じゃない
他人のツッコミや推測の書き込みと質問者の答えの区別がつかんから
「前に書いた」と言われてもどれのことだか分からん訳で
2ちゃんでは話題が継続してる間は最初の質問の番号を名前欄に入れる
のが一般的だと思うんだが質問者はそういうルールを知らんのか
あるいは質問者は>>278だけで後はなりすましの他人による釣り行為だったのかw
351:名無しさん＠お腹いっぱい。
11/01/29 10:49:12
もうこの話やめようよ。
352:名無しさん＠お腹いっぱい。
11/01/29 11:59:25
>>350
>>337は、(質問者が)「他人の提案をなんでも却下」したと言っている、
却下したのが他人の突っ込みでないこと、すなわち元質問者であるとわ
かっている。
わからないお前がバカなんじゃない?
353:名無しさん＠お腹いっぱい。
11/01/29 12:00:00
openssh 5.7リリースの話題から目をそらそうとする陰謀としか思えんな
どういう目的があるのかはわからんが
354:名無しさん＠お腹いっぱい。
11/01/29 19:54:45
>>352
とりあえず見てて不快だからこの話題やめようぜ
355:名無しさん＠お腹いっぱい。
11/01/29 22:01:49
やり込めようと向かってこなきゃいいんじゃないかな。頭足りないんだから。
356:名無しさん＠お腹いっぱい。
11/01/30 00:11:27
>>352
そのレス以前の文脈無視すんなよw
357:名無しさん＠お腹いっぱい。
11/01/30 14:29:00
>>356
誰が書いたかわからないのに文脈もクソもないだろ。
358:名無しさん＠お腹いっぱい。
11/01/31 11:39:19
>>353
とりあえず家のSolaris鯖のは既に入れ替えてみてある。
ぱっと見、session.cのコードが結構変わってた。
359:名無しさん＠お腹いっぱい。
11/02/01 18:44:56
>>358
よくわかってないんだけどECDSA って美味しい?
試しにssh-keygen -t ecdsa したら規定値256bit なんだけどこれで問題ないのかな?
-3 は面白そう
360:名無しさん＠お腹いっぱい。
11/02/02 10:06:03
楕円暗号だから256bitもあれば
RSA2048bit よりは強度はだいぶ上じゃないかな
361:名無しさん＠お腹いっぱい。
11/02/02 10:14:40
> scp(1): 新しい -3 オプションを追加.
これ壁というかGW上のホストでの作業に
めちゃめちゃ便利そう
いままでなかったのが不思議なくらい
(いちいち ssh utigawa tar cf - | ssh sotogawa tar xpf - とかしてた)
はやく FreeBSD のツリーに取り込まれないかな…
362:名無しさん＠お腹いっぱい。
11/02/02 10:19:27
もう一つ openssh 5.7関係の話から(openssh とは直接は関係ないんだけど…)
> sftp(1): sftp クライアントは非常に早くなった.
WinSCP による転送が異常に遅い問題って
この辺の話と関係あるんでしょうかね。
363:名無しさん＠お腹いっぱい。
11/02/02 15:03:40
* sftp(1): the sftp client is now significantly faster at performing
directory listings,
これ？ ディレクトリ一覧取得って書いてあるけど。
364:名無しさん＠お腹いっぱい。
11/02/02 15:24:48
>363
あちゃ… たしかに原文はそうなってるね。
日本語訳しか読んでなかった… orz
365:名無しさん＠お腹いっぱい。
11/02/02 20:53:32
>>360
トン
RSA に比べると大分bit 数が少なかったので少し不安でした
とりあえず256bit で運用してみます
366:名無しさん＠お腹いっぱい。
11/02/04 13:01:42
5.8
URLﾘﾝｸ(www.openssh.org)
URLﾘﾝｸ(www.unixuser.org)
367:名無しさん＠お腹いっぱい。
11/02/04 23:35:36
この前5.7出たばっかなのにもう5.8か
368:名無しさん＠お腹いっぱい。
11/02/09 07:24:56
PAMって具体的にどういう利点があるのですか？
369:名無しさん＠お腹いっぱい。
11/02/09 21:43:26
>>368
認証プロセスをアプリ毎に実装する必要がない。
認証方法を変更する場合、ユーザー側の作業だけですみ、アプリに変更を加える必要がない。
370:名無しさん＠お腹いっぱい。
11/02/23 00:31:11.34
MidpSSHでOpenSSHのsshdへ接続するにはsshd_configに最低でも
Ciphers 3des-cbc
としておかないと駄目らしい。
なんとか接続できたので快適ｗ
371:名無しさん＠お腹いっぱい。
11/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).
というエラーが出てログインできない。
372:名無しさん＠お腹いっぱい。
11/02/28 11:34:25.20
ユーザ名は含まれていない。
sshに-v付けて調べる。
373:371
11/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
(続く)
374:371
11/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).
375:名無しさん＠お腹いっぱい。
11/02/28 12:51:57.78
pubkeyのオファーはしてるけど、サーバ側で拒否してる。
サーバーに転送した公開鍵がおかしい(行末?)とか、ディレクトリが違うとか、
パーミッションがおかしいとか。
376:名無しさん＠お腹いっぱい。
11/02/28 12:52:50.37
サーバの.sshがworldライタブルとか
377:371
11/02/28 13:10:15.94
レスどうもありがとうございます。
sourceforge.jp の場合、下記のように、
ブラウザに、自分のPCで作成した公開鍵を貼り付けるようになっているので、
URLﾘﾝｸ(sourceforge.jp)
ディレクトリが違うとかパーミッションがおかしいということはないと思います
(sourceforge.jp の CGI が間違ってない限り)
ちなみに「サーバ側で拒否している」とは、>>373-374 のどこでわかるのでしょうか?
また、「鍵が合ってないよ」とは違う状況をサーバはおうとしているのでしょうか?
378:名無しさん＠お腹いっぱい。
11/02/28 13:28:46.78
> ブラウザに、自分のPCで作成した公開鍵を貼り付けるようになっているので、
ありがちなミスでコピペしたときに途中に改行が入ってるんじゃない?
公開鍵は一行だぞ。
> debug1: Authentications that can continue: publickey
(あんたの送った公開鍵は却下)次の公開鍵送れ。
379:371
11/02/28 15:04:24.35
すみません、原因がわかりました。
sourceforge.jp では、アカウント申請しただけではシェルサーバに
ログインできず、何らかのプロジェクトに属さないとダメなようです。
申し訳ありません、お騒がせしました。
>>378
レスどうもありがとうございます。
ssh -v でデバッグする方法は今回で知ったので、今後に役立たせていただきます。
380:名無しさん＠お腹いっぱい。
11/03/26 01:13:04.19
metosrv9.umd.eduがSSH舐めて歩いてる
381:名無しさん＠お腹いっぱい。
11/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を開いたときに知らずに変更してしまったのか。手がかりが分からず困ってる。
382:名無しさん＠お腹いっぱい。
11/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を開いたときに知らずに変更してしまったのか。手がかりが分からず困ってる。
383:名無しさん＠お腹いっぱい。
11/03/27 09:08:23.01
どうみても別問題です
Mac側ユーザでls -la ~/.sshした結果でも貼ってみれば？
384:382
11/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
にしても変わりません。
385:名無しさん＠お腹いっぱい。
11/03/27 13:26:38.84
何言ってるのかちょっとわからない
Mac1はログインする側でDebがされる側？
まさかだけど鍵穴に鍵穴を突っ込もうと奮闘してるとか？
386:名無しさん＠お腹いっぱい。
11/03/27 13:48:31.92
ここと、
＞Mac1からMac2に
＞DebからMac2に
ここで、
＞今度はMac1とMac2の両方からDebに
ログインの方向が変わってるぞ。鍵穴に鍵穴を突っ込もうとしてるか、鍵を鍵に突っ込もうとしてるのどちらか。
387:名無しさん＠お腹いっぱい。
11/03/27 15:02:42.89
pubkeyオンリーの運用が難しいなどと抜かす池沼はサーバの運用するな。
388:名無しさん＠お腹いっぱい。
11/03/27 23:17:45.54
>>385
なんか百合っぽい
389:名無しさん＠お腹いっぱい。
11/03/28 06:06:44.71
藤原一宏教授の虚偽申請は、日本の数学界に対する国民の信頼を裏切った、
無視することのできない重大な事件です。このような者がのうのうと責任ある教授職を
続けていることに、藤原氏がプロの学者であることを自覚しているのなら
なおさら疑問をかんじざるを得ません。今後二度とこのような事件が起きないように
するためにみなさんで建設的な議論をしましょう。
390:382
11/03/28 10:56:35.78
>>386
ログインの方向が変わっているのはその通りです。
３つのマシンがsshdを動かしていて、それぞれ公開鍵を発行して相互にログインできてました。
いま困っているのは
＞今度はMac1とMac2の両方からDebに
が出来ない事ですが、
別の事象として、DebからMac2にアクセスするときにも同じエラーが起きていたということです。
391:名無しさん＠お腹いっぱい。
11/03/28 13:44:18.52
公開鍵は使いまわせるけど、秘密鍵は使いまわせないですよね？
その公開鍵をベースに秘密鍵を使うクライアントで秘密鍵を作らないと動かない。
392:名無しさん＠お腹いっぱい。
11/03/28 13:49:53.81
どういう意味で「公開鍵を使いまわす」と言ってるんだろう。
393:名無しさん＠お腹いっぱい。
11/03/28 13:50:31.92
>>391
キミは120%理解していない。
394:名無しさん＠お腹いっぱい。
11/03/28 14:21:01.08
なるほど、この人はパスフレーズが「鍵」だと勘違いしているのかな…
まあ何を拠り所に認証しようとしているか理解しないと
いつまでたっても勘違い度2000% になっちゃうね
395:名無しさん＠お腹いっぱい。
11/03/28 14:23:13.67
＞公開鍵をベースに秘密鍵を使うクライアントで秘密鍵を作らないと動かない
これができるなら、公開鍵暗号って破綻しないか？
396:名無しさん＠お腹いっぱい。
11/03/29 15:29:07.09
お客様の中にPuTTYを使っている方はいらっしゃいませんか
PuTTYで共通する項目を設定することはできんものでしょうか
例えば色や外観など部分的な設定を各セッションで共通化したいのですが手軽な方法はないでしょうか
ICE IVのPuTTYを使っています