- PR -

SSH2接続（ホスト公開鍵）

1|2 次のページへ»
投稿者投稿内容
トリックスター
大ベテラン
会議室デビュー日: 2003/04/16
投稿数: 104
投稿日時: 2005-12-15 00:30
現在、クライアントPCで鍵を作成し、サーバに公開鍵を置き、
SSH2でリモート接続しています。
----
　　　　　 クライアントPC　　サーバ
　　　　　 ユーザー秘密鍵 → ユーザー公開鍵
　　　　　　　　　　　　 　　/home/[ユーザー名]/.ssh/authorized_keys2
----

サーバ1からサーバ2にSSH2で接続する場合、各ユーザーの秘密鍵をサーバ1
に置きたくないので、ホスト秘密鍵を使いたいのですが、公開鍵はサーバ2
のどこに置けばよいのでしょうか？
----
　　　　　　　　　サーバ1　　サーバ2
　　　　　　 ホスト秘密鍵 → ホスト公開鍵
/etc/ssh/ssh_host_dsa_key　　？？？
----

/etc/ssh/authorized_keys2とか置いてみたんですけど、下記エラーとなります。
----
Permission denied (publickey,keyboard-interactive).
----

よろしくお願いいたします。
コブラ
ぬし
会議室デビュー日: 2003/07/18
投稿数: 1038
お住まい・勤務地: 神奈川
投稿日時: 2005-12-15 17:29
昔、 ~/.ssh 配下に何か置いたような気がします。

openssl genrsa とか openssl rsa を使ったかも知れません。

外からの接続を許可したいので止めましたが・・・
あつしfx
大ベテラン
会議室デビュー日: 2002/04/08
投稿数: 104
お住まい・勤務地: XPできるところ
投稿日時: 2005-12-16 00:15
参考ですが、うちのばあいの以下のようにしています。
なお環境はVine 3.2+rpmパッケージ
キー作成は
ssh-keygen でid_dsa,id_dsa.pubを作成し
コード:
~/.ssh/authorized_keys

に公開カギを設置しました。
ちなみに
コード:
~/.ssh 755
authorized_keys  744
id_dsa 400

です。
_________________
http://aglabo.com/ @Homepage
http://furukawa-select.com/mt/ @Blog
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-12-16 02:47
SSH2というのは商用のSSH2ではなくて、SSH2プロトコルのことですよね？
~/.ssh/authorized_keys2 と書かれているので、OpenSSHの方だと仮定して書きます。

新山さんのOpenSSH日本語マニュアルページ
によると、システム全体でホストベース認証を使う場合は、
/etc/ssh/ssh_known_hosts に相手サーバのホスト名や公開鍵を置くようです。

そして、/etc/ssh/sshd_config で
HostbasedAuthentication yes
IgnoreRhosts no　#（~/.rhosts や ~/.shostsを利用する場合）
を設定するようです。
ちなみに、/etc/host.equiv や /etc/shost.equiv を使用する場合には
十分な注意が必要らしいです。

また、サーバ1上の /etc/ssh/ssh_config や ~/.ssh/config で
HostbasedAuthentication yes
を設定しないといけないようです。


ところで、サーバ1上に秘密鍵を置きたくないというのは、
「サーバ1にログインするための秘密鍵を置きたくない」、ということでしょうか？
それとも、「サーバ2にログインするための秘密鍵」を置きたくない、ということでしょうか？

前者であれば、サーバ2にログインするための秘密鍵を新たに作ればいい気がします。
後者であれば、ポートフォワーディングとか、ssh-agentの転送とか・・・

また、前者であれ、後者であれ、それほど気にしなくてよい気もするんですよね。
普通は秘密鍵のパーミッションは600や400にしますよね。
すると、秘密鍵を読めるのはそのユーザとrootだけです。

前者の場合、プロセスを乗っ取れば、読むだけでなく書き込むことも出来るので、
~/.ssh/authorized_keys に好きな公開鍵を追加できてしまうんですよね。

秘密鍵を読めるけど、~/.ssh/authorized_keys に書き込めない状況というのは、
suExecのCGIスクリプトのセキュリティホールぐらいしか私には思いつきません。

他のホストにも同じ秘密鍵を使ってログインしている場合には、
その秘密鍵を盗まれないというのは、それなりに意味を持つとは思いますけど。
それなら、秘密鍵を使い分けたり、パスフレーズを慎重に設定したりした方が良い気がします。

後者の場合、~/.ssh/authorized_kyes に書き込める or 任意のコマンドを
実行出来るようなセキュリティホールが存在しても、秘密鍵のパスフレーズを
破らないと、サーバ2にアクセスできませんよね。

なんか、サーバ2へ直接アクセスできない環境のようですし。
アクセス元は /etc/hosts.allow, /etc/hosts.deny や iptables で制限したり、
~/.ssh/authorized_keys の from オプションで制限したりも出来ますし。

ところが、ホストベース認証が有効であり、~/.ssh/authorized_keys に書き込める
or 任意のコマンドが実行できる場合は、秘密鍵のパスフレーズを破る手間をかけずに、
サーバ2に入れてしまいます。

そういうわけで、セキュリティの観点からは、ホストベース認証を使うよりは、
サーバ2へのログイン専用の秘密鍵をサーバ1に置く方が良いように思えます。
トリックスター
大ベテラン
会議室デビュー日: 2003/04/16
投稿数: 104
投稿日時: 2005-12-16 13:33
皆さん、いろいろ教えてくださって、ありがとうございます。
非常に勉強になります。

[quota]
SSH2というのは商用のSSH2ではなくて、SSH2プロトコルのことですよね？
[/quota]
OpenSSH-4.2p1-1のプロトコルバージョン2です。

[quota]
ところで、サーバ1上に秘密鍵を置きたくないというのは、
「サーバ1にログインするための秘密鍵を置きたくない」、ということでしょうか？
それとも、「サーバ2にログインするための秘密鍵」を置きたくない、ということでしょうか？
：
また、前者であれ、後者であれ、それほど気にしなくてよい気もするんですよね。
普通は秘密鍵のパーミッションは600や400にしますよね。
すると、秘密鍵を読めるのはそのユーザとrootだけです。
[/quota]
後者です。秘密鍵は各ユーザーのクライアントPCに1つだけ置くことを推奨して
いるためです。秘密鍵を複製するような行為は抑制したいです。また、rootが
各ユーザーの秘密鍵を読めることも問題視しております。もし秘密鍵が漏れたら、
ユーザーの自己責任という状況が作れます。同時にユーザーは管理者にすら開示
しなくてよいので、安心できるのではないでしょうか。
ポートフォワーディング、ssh-agentの転送、ですか．．．（混乱

[quota]
そういうわけで、セキュリティの観点からは、ホストベース認証を使うよりは、
サーバ2へのログイン専用の秘密鍵をサーバ1に置く方が良いように思えます。
[/quota]
本来そうすべきですが、管理が煩雑になるのが嫌です。例えば、サーバ3、4と
増えたとき、鍵がどんどん増えます。ユーザーも嫌がる（鍵って何？レベルの
人もいる）と思います。
クラッカーからの攻撃の観点では、サーバ1に入られた時点でアウトだと思って
います。ただ、被害を最小限に抑えることを考えたら、セキュリティが甘いと
思いました。（反省
実は、非常に妙な環境にしていまして、ユーザー認証はLDAPで、/homeは、NFS
で共有しています。そういう意味では、サーバ1、2併せて1つのサーバと見てい
るわけです。そこに複数の鍵を置くのは実は意味がないですね。これは、
こちらの環境の問題で、cn009さんが知る由もなかったですね。すいません。

また、パスフレーズ や /etc/hosts.allow, /etc/hosts.deny や iptables で
のセキュリティ強化は別の話（補助あるいは相乗効果的な役割）だと思います
ので、別途考えたいと思います。

私は、ホスト認証をしたいということで、
・/etc/ssh/ssh_known_hostsに相手方の公開鍵を追加しました。
・/etc/ssh/sshd_configのHostbasedAuthenticationをyesとしました。
しかし、状況は変わらずです。

サーバ1（192.168.1.2）←→ サーバ2（192.168.1.3）相互にホスト認証
したいので、下記のようにしています。

■192.168.1.2:/etc/ssh/ssh_known_hosts
----
192.168.1.3 ssh-dss AAAAB3NzaC1kc3MAAACBAM391K4EsszNSV4SeMBlOyQhCGLgk3yJvYogYawymv54FeAQ4qmud1mJs57xTpajV5A1nKg1c/fXsahqYt7umLyynsCQVkpmMe4ZQvA89iOzUf6cA7zNUd7R0jG9P355Y7YaXJXE4p0GGYaWaCE3vH43/a75yuYjayIm5OY3Ub0BAAAAFQCJOamJemAqaEX+ac+kk/5vqfJqhwAAAIEAggfa9Rvrk87dTK8yCx6IoN6F1BKrCrRtheBiip62nlDFBQjb3BUkTz6nnRZW5TY7XBpvZQvmDBJhYsgUW18qpdJurtD+j8eIef1EqaLJPFczg8tnneTca51+4yy8uDu9W642Z35ZCwKwZkgQjpcIH0a8UT5mSg8jA5QWC/HU+b4AAACBAJsyIFPN4+8YgzhmPLaUBzz8IHZUAJhdB6ycpGEpHwmtaXEhgS1O3maPwEtbmsvKwqlBYWGXwIwtivug5INTd99Knyz+EvlkCaqepDD0z5mInubXXt0s81AITDeX0+vZyPfg+v4Oy2zmopBnXQ1XeYT5ZJKxJeVFdqes2k9wbDLU
----
ssh-dss以降は、192.168.1.3:/etc/ssh/ssh_host_dsa_key.pub の内容と同じ。

■192.168.1.2:/etc/ssh/sshd_config
----
Protocol 2
HostKey /etc/ssh/ssh_host_dsa_key
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
ClientAliveInterval 60
Subsystem sftp /usr/libexec/openssh/sftp-server
----
コメント、空行は省略。

■192.168.1.2:/etc/ssh/ssh_config
----
HostbasedAuthentication yes
----
コメント、空行は省略。

■192.168.1.3:/etc/ssh/ssh_known_hosts
----
192.168.1.2 ssh-dss AAAAB3NzaC1kc3MAAACBALtsSVEMrdtbAQEq17sXTLGQu6mEiwAVatoVh8h5rF0NpYiMvNxVVDueVh1RpIBtddCYYZt6QHyvFnMUAbW8m6cVfG60okmbHNS2hRz2RalOGoCDNPlwxRsATWVrreGD6oLXT1SlZ+N5pL4zvlCf111jdinFmcV1V/274QD+mjP9AAAAFQDZtCf+BgxpBppA+APdiKnMzbi48wAAAIEAt8dhtCdn988vwJxZW/sm4Px+WRHCzfl7RZdJs7+WtF6m69aB8/CWIg1EgZ+8Gm/TxlvlUOrYE9o63tvi7VIIYUYFhEasKhop0JIrL1W562B4akEbQsJkGWZSkTkO4gDd43VGHQ1litLIQnWjliwPj6RkdILNmkSJpJeMdfQMIPsAAACBAJjvTJYRtys0wIb6WDCLJK0I9sah5s+8/dbRnDl1gvxugItpoi1PoRYFv9L9Em9lqjnxSYCl3rY8iKH/bV5JnC7eJifJtyd0lwJAbIQ7jemof4vqcrymwHclCWbJXAq/XUyFBwGq1UuhKrOQ54aYaXV1Qjf3bymojAVWupTsHAZQ
----
ssh-dss以降は、192.168.1.2:/etc/ssh/ssh_host_dsa_key.pub の内容と同じ。

■192.168.1.3:/etc/ssh/sshd_config
----
Protocol 2
HostKey /etc/ssh/ssh_host_dsa_key
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
Subsystem sftp /usr/libexec/openssh/sftp-server
----
コメント、空行は省略。

■192.168.1.3:/etc/ssh/ssh_config
----
HostbasedAuthentication yes
----
コメント、空行は省略。

/etc/ssh/ssh_host_dsa_key.pub は、openssh-server-4.2p1-1を
インストールしたときに作成されたもので、ssh-keysignなどで
自分で作成したものではありません。

教えていただいた新山さんのページを熟読して勉強したいと思います。
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-12-16 17:43
引用:

秘密鍵は各ユーザーのクライアントPCに1つだけ置くことを推奨して
いるためです。秘密鍵を複製するような行為は抑制したいです。また、rootが
各ユーザーの秘密鍵を読めることも問題視しております。もし秘密鍵が漏れたら、
ユーザーの自己責任という状況が作れます。


秘密鍵が漏れたら各ユーザの自己責任、っていうのは良いと思いますが、
~/.ssh/autorhized_keys に公開鍵を追加されていた場合はどうなるんでしょうか？
そのユーザの責任？rootが勝手に追加して利用した可能性は？となってしまう気がします。

引用:

ユーザー認証はLDAPで、/homeは、NFS
で共有しています。そういう意味では、サーバ1、2併せて1つのサーバと見てい
るわけです。そこに複数の鍵を置くのは実は意味がないですね。


なるほど。サーバ2に直接アクセスできないのはセキュリティ重視だから、
というわけではなかったんですね。
LAN内リモートアクセス
の続きの話ということでしょうか。

外部からアクセスするための鍵と、LAN内のサーバ同士でアクセスするための鍵を
使い分けることは、それなりに意味があると思います。
ただ、~/.ssh/authorized_keys のサーバ同士で使う公開鍵の方にだけ from オプションを付けたり、
外部からのアクセス用の秘密鍵をサーバ上に置かないように気をつけたり、と
複雑になり、一般ユーザにとってはかなり面倒ですね。


「HostbasedAuthentication yes」はサーバ側の /etc/ssh/sshd_config と
クライアント側の /etc/ssh/ssh_config （もしくは ~/.ssh/config ）の両方で
設定しないといけないようですが、どちらか抜けていませんか？

~/.shosts や /etc/shosts.equiv の設定を忘れていませんか？
それぞれのサーバでユーザ名が一致しているなら、/etc/shosts.equiv に
相手サーバのホスト名を書くだけで済みそうですね。

それから、ホストの公開鍵は途中を省略した方が良い気もします。
そのサーバに接続できれば誰でも入手できる情報ではありますが、
トリックスターさんのところのユーザがここを見ていて「うちの管理者か・・・」
と気が付く可能性もありますし。
トリックスター
大ベテラン
会議室デビュー日: 2003/04/16
投稿数: 104
投稿日時: 2005-12-17 00:38
お世話になっております。

引用:

~/.ssh/autorhized_keys に公開鍵を追加されていた場合はどうなるんでしょうか？
そのユーザの責任？rootが勝手に追加して利用した可能性は？となってしまう気がします。

それができるのはrootだけですから、そんなリスクを犯さないですよね。
犯人は私ですって言っているようなもんですから。
不意に漏洩することと故意に悪さをすることとは違うと思います。
でも、セキュリティポリシーが探り探りの状態であることは、お気付きの通りです。
精進いたします。

引用:

LAN内リモートアクセス
の続きの話ということでしょうか。


あ、そうです。LAN内の話なので、最悪はTelnetでもよいと思っています。

引用:

外部からアクセスするための鍵と、LAN内のサーバ同士でアクセスするための鍵を
使い分けることは、それなりに意味があると思います。


そうですね。ただ、妙な環境でして．．．
そのLAN内の鍵が、ホスト鍵だと思ったのですが、結局ホスト認証はTelnetで
繋いでいるのと大差ないような。telnet-serverをインストールしないことは
良いことだと思いますが。

引用:

「HostbasedAuthentication yes」はサーバ側の /etc/ssh/sshd_config と
クライアント側の /etc/ssh/ssh_config （もしくは ~/.ssh/config ）の両方で
設定しないといけないようですが、どちらか抜けていませんか？


すいません。抜けてました。お恥ずかしい。
エラーメッセージが、
----
Permission denied (publickey,keyboard-interactive,hostbased).
----
に変わりました。
恥ずかしいついでに、/etc/shosts.equiv の書式を教えていただけないでしょうか。

引用:

それから、ホストの公開鍵は途中を省略した方が良い気もします。


文字通り、公開してしまいました。気をつけます。
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-12-20 22:32
引用:

それができるのはrootだけですから、そんなリスクを犯さないですよね。
犯人は私ですって言っているようなもんですから。
不意に漏洩することと故意に悪さをすることとは違うと思います。


当然すぎて思い浮かばなかったのでしょうけど、そのユーザも書き換えられますよね。
書き換えたのがrootでもそのユーザでもない可能性もあります。
サーバ上のsuExecのCGIスクリプトの脆弱性等を攻撃されて書き換えられることもあるでしょうし。

さらに、ユーザのマシンで ssh-agent が動いている場合、ユーザのマシンに
侵入したクラッカーがサーバに接続して、~/.ssh/authorized_keys を書き換えるかもしれません。

侵入されればSSHクライアントやエージェントがすりかえられたり、キーロガーを仕込まれて
パスフレーズ（と秘密鍵）が盗まれる可能性の方が高そうですけどね。
そのユーザが自分のマシンで普段は一般ユーザで使っていたり、
クラッカーが急いでいる場合は、そういう手を使わないとも限りませんし。

それから、ssh-agent を立ち上げたまま席を外したり、とかいう場合も
~/.ssh/autorized_keys を書き換えられる危険性がありますね。

引用:

結局ホスト認証はTelnetで
繋いでいるのと大差ないような。


ホスト認証だとパスワードやパスフレーズが不要なので楽ですね。
LAN内ではあまり心配は無いと思いますが、盗聴されたり偽のサーバに繋がされたりする危険性も無いですし。
その環境では必要ない気もしますが、scp や sftp、それにポートフォワーディングも使えますし。

引用:

/etc/shosts.equiv の書式を教えていただけないでしょうか。


聞くよりもマニュアルを見たほうが早いと思いますよ。

> いちばん簡単な形式は、各行にひとつのホスト名を書いておくこ
> とです。これらのホストからのユーザは、両方のマシンでユーザ名が同
> じならばパスワードなしでログインを許可されます。

とあります。

> 「警告: hosts.equiv でユーザ名を使うのは絶対にやめるべきです」

ともありますし、基本的に各行にホスト名を書くようですね。
例外は

> ここでのユーザ名の唯一のまともな使いみちは
> 、おそらく否定のエントリで使うことだけでしょう。

という場合ぐらいのようです。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）