title
わたしの日記は日々の出来事の鬱憤晴らしの毒だし日記がメインです。 相当病んでいます。くだを巻いています。許容出来る方のみのアクセスをお願いします。 また、この日記へのリンクは原則自由にして頂いても結構ですが、 写真への直リンクを張るのはご遠慮下さい。内容に関しては、一切保証致しません。
カテゴリ一覧 Network, Internet, IPv6, DC, NTT, Comp, Linux, Debian, FreeBSD, Windows, Server, Security, IRC, 大学, Neta, spam, , 生活, 遊び, Drive, TV, 仕事,
過去日記:





2014年05月14日(水) [晴れ]

[Security][Neta] シマンテック・ウェブサイトセキュリティ

ベリサインが買収され、シマンテックになったのは有名だが、ちょっと用事があってアクセスしてみて気づいたのだが、ベリサインのサイトのEV SSLの名前が、日本ベリサイン株式会社となっている。
この会社のSSL事業がまるっと、シマンテックになっているわけで、会社概要などを見ても、 合同会社シマンテック・ウェブサイトセキュリティとなっているわけですよね。



なんで、EV SSLだけは、ベリサイン株式会社と表示されるんだろう?
ドメインも違和感はあるけど、SEO的なところ、過去のところなども有るから仕方ないとして…。実在する会社を証明しているものを無いものに表示されてもとかんがえると、ずさんなのか、手が回っていないのか。もう、会社としては買収され、実在しないわけですよね?

[ コメントを読む(0) | コメントする ]

[Server] VMware ESXi で SSH 鍵認証のみに設定する

VMware ESXi 環境では、5から、SSHの有効化は簡単に出来るようになり、

  「構成」-「セキュリティプロファイル」-「サービス」-「SSH」

で設定出来る。ここのオプションで、自動で起動するようにすれば問題ないが、これは、root でパスワード認証を行っている。そもそも、vSphere Client もパスワード認証で共通なので、セキュリティー的には余り違いは無いが、SSHの場合、簡単にパスワードのブルートフォースアタックなど、ツールが出回っていることと、とてもねらわれやすいと言うことから鍵認証に設定してみる(とか一般説を書いてみるが、実際のところは次に続く)。

元々、管理用ネットワークはインターネットなどに直接接続されておらず、保護されたネットワークであることが大原則の為、問題にならないので良いとしても、本題はそこではない。たんなる興味もあるのだ。

とかいいつつも、じゃあ、どういうときに使うのか?というと、純粋に、ssh-agentをつかったほうが、楽ということや、自動化などでも使えることから、採用しているケースも多いのでは無かろうか。

さくっと深く調べない範囲でググってみたが情報が鍵認証をするというところまでの内容程度しかないということ、Unixの知識はOpenSSHの設定の知識が有れば当たり前のことだがあえて書いてみる(共感もてたら、アフィぽちってねw)。

まず、SSHでrootログインすると、シェルが現れる。そこから順番に。

まずは、esxi に入っている、ssh の version を調査してみると、次の通り。

 # ssh -V
 OpenSSH_5.6p1, OpenSSL 1.0.1e 11 Feb 2013

OpenSSH5.6 なので、基本的に、OpenSSH5.6 の設定をすればよい。

じゃ、sshd_config を確認してみましょうか。
一部抽出。

# less /etc/ssh/sshd_config
----
UsePAM yes
# only use PAM challenge-response (keyboard-interactive)
PasswordAuthentication no
AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys

だが、/.ssh があるが、こちらは、known_hostsの保存の為であり、認証用の鍵ではない。
鍵は、/etc/ssh/keys- 配下に保存される。
参考にだが、/etc/ssh/ssh_config がないので、おそらくsshコマンドの初期値。すなわち、$HOME:/.ssh に保存されているのではなかろうか。

ということで、自分の鍵を上記PATHに保存すればよい。root ログインをしてるならば、下記のようにすればよい。

# cat > /etc/ssh/keys-root/authorized_keys << EOF
ssh-rsa AAAAB3Nza (略)
EOF
# chmod 600 /etc/ssh/keys-root/authorized_keys

これでよい。
念のため、鍵認証のみにしたければ、 /etc/ssh/sshd_config を修正すればよい。
こんな感じで。

# vi /etc/ssh/sshd_config
-----
UsePAM yes
↓
UsePAM no

若しくは、明示的に、ChallengeResponseAuthentication を無効にすればよい。

UsePAM yes
# only use PAM challenge-response (keyboard-interactive)
ChallengeResponseAuthentication no
PasswordAuthentication no

再起動はこんな感じだ。

# /etc/init.d/SSH restart

まあ、

# services.sh restart

でもよいが、いろいろなサービスを再起動してしまうので、SSH だけの再起動をおすすめする。
外部ストレージを使っている場合などもおそらく切れてしまう可能性があるので、余りおすすめしない。
ざっくりと、service.shをみてみると、

# /sbin/chkconfig -o

でサービスの一覧を取得し、 stop のパラメータを渡して停止する。

# ulimit -s 512  <- ulimit の書き換え
# /sbin/chkconfig -io

でサービスの一覧を取得し、start のパラメータを私て起動している。

もちろん、sshd に対して、HUP でもよいですし、セキュリティプロファイルのサービスからの再起動でも問題有りません。後は鍵認証でいけるか確認しましょう。ちゃんちゃん。あ、サービスの再起動のプロセス(停止→起動)の際にも、Firewallの設定も入っているけどあえてかいてないよ!

[ コメントを読む(0) | コメントする ]

[Server] VMware ESXi SSHシェルから、SSH接続をする

実は、ESXi のSSHでつないだターミナルから、外部ホストへ、sshやscp出来ないんですよね。よーくみてみると、セキュリティプロファイルのファイアーウォールの設定で、SSHのフィルタがされているので解放してあげればよし。解放すれば、ターミナルから、ssh や scp が出来るようになるでござる。いつからだろうかね。。

[ コメントを読む(0) | コメントする ]

[Server] vmイメージのscp/sftp でレジュームしたい

うーん、これ、とーっても困った。VPN経由で、vmのイメージ(200GBほど)をscpしてたんだけど、帯域制限されたのか、300kb/secしかでなくなった。これはVPN及びサービスで使用している表の線。それとは別に、各拠点毎に別途管理用の線と踏み台(SSH)経由でアクセスが出来る別のバックアップが存在している。2経路の侵入ルートやね。

ギリギリまで、開発環境で構築をし、並行して別拠点に物理サーバー(VMware ESXiの設置)、後に、設置した本番機へvmのイメージを投入し、サービスを行うという計画。

調達元、キッティング場所、開発環境が別々なので、開発環境で構築後、本番機(遠隔地)へ展開するするというのはよくあること。遠隔地にあるので、わざわざ区切りのついたタイミングで、USB-HDD等に抜き出してということは簡単にできないし、そもそも、ESXiでは、USB-HDDは使用出来ないことから、ネットワーク越しでの転送となった。

経緯は書いたとおりで、はまったのは、転送速度の低下、おおよそ数十ギガ転送したあとに速度低下が発生したので、リジュームしたいと言うこと。 だが、ESXi間でSCPを行っているので、そのSCPではレジューム出来ない。次に考えたのは、Windows から、 filezilla で転送したいなーと思ったが、VPNは使えず、両方踏み台経由でアクセスする必要があるので直接接続できない。最初考えたのは、nat経由で、外に抜けることが出来るので

 Dst                                  Src
 ESXi |FW| -- Internet -- |踏台| -- ESXi

というかたちで、踏台に直接sshポートフォワードをして、最初から転送するのも考えたが、半分ぐらい終わっているのでなんとしてでも、レジュームしたい。src側のESXiと同じNW上に、Windowsマシンが一台(vmの上で動いてる)あるので、こいつで、filezilla を使えば、いいかなあと。

ちなみに、両方の拠点共に、にvmイメージを保存している共有ストレージはなく、ローカルディスク上で運用されている、
Src側の拠点には、ドキュメントやHomeディレクトリなどがある別で構築されたNFS/CIFSサーバーがある。

ということで、一旦、NFSを使いファイルサーバへイメージのコピーを取り、ポートフォワードしたところに対して、filezilla で sftp経由で転送をすればいいやとおもったので、次のようにした。

 $ ssh -4 -N -f -R 192.168.xxx.xxx:50022:localhost:22 fumidai.example.jp

どういう事かというと、Dst側のESXiから、踏み台に対して、リモートポートフォワードを行ったと言うこと。イメージとしては仙石さんのサイトの 実践で学ぶ、一歩進んだサーバ構築・運用術このあたりが詳しい。やっぱり、みんな、トンネルでいろいろなFWを破ることを考えますね。先ずは明いているところで何が出来るか(-; ... 話しを戻して、これを行ったところ、リモート側のSSHでは、127.0.0.1:50022 しか、LISTEN出来ない。
man を見ると、次のような記載がある。

     -R [bind_address:]port:host:hostport
             Specifies that the given port on the remote (server) host is to
             be forwarded to the given host and port on the local side.  This
             works by allocating a socket to listen to port on the remote
             side, and whenever a connection is made to this port, the connec‐
             tion is forwarded over the secure channel, and a connection is
             made to host port hostport from the local machine.

なぜ出来ないのかわからなかったのと時間が無かったので、stoneを立ち上げ、localhost:50022 に対して、 プライベートIP側でLISTENさせることにした。後に、発覚したのは、どうやら設定の問題で、ちゃんとmanを読むと書いてあった。

     -R [bind_address:]port:host:hostport
.....
             By default, the listening socket on the server will be bound to
             the loopback interface only.  This may be overridden by specify‐
             ing a bind_address.  An empty bind_address, or the address ‘*’,
             indicates that the remote socket should listen on all interfaces.
             Specifying a remote bind_address will only succeed if the
             server's GatewayPorts option is enabled (see sshd_config(5)).

sshdの設定のデフォルトは、loopback interface にしか、socket はopen出来ませんよ。bind_addressを使用したければ、GatewayPorts = yes にしなさい。と。
ということで、有効にして試してみたところ、bind_address は無視され、*:50022 であいちゃいました...
確認したVer: FreeBSD9, OpenSSH 5.8 です。

ということで、間に、filezillaのsftpクライアントを使用し、レジュームし別のネットワーク経由で、8MB/secていどで、東西間でイメージの転送をすれば、数時間で終わりました…。スナップショットを撮って、元の固定イメージを送り、残りの差分を送って、なるべく最長減のダウンタイムで環境構築が出来たので、イイノウハウが得れましたorz そっちの回線は互いにトランジット経由になるのだが、しーったことない。VPNはIX経由で繋がっているキャリア同士なので、考慮してあげたのに。。。制限したから...IIJ/FreeBIT間は、Verio経由の通信だったけど、早かったよ。

[ コメントを読む(0) | コメントする ]

Diary for 1 day(s)
Powered by hns HyperNikkiSystem Project




(c) Copyright 1998-2014 tomocha. All rights reserved.