サーバのIPアドレス入れ換えた時のSSH再接続

 サーバーのIPアドレスを入れ換えるなんて普段は無いのですが、ハードウェア障害によるサーバ交換を行った時に気をつけなければならないのはSSHが弾かれてしまうこと。
Windowsクライアントならサーバが代わろうが警告が出ようが新しいキーを上書きして続行できるのですがLinux同士だと、一旦known_hostsの情報を削除する必要がありました。
で、これだけknown_hosts自体を削除しそうですが、SSHの接続先が複数あるときは後でknown_hostsを再生成する手間が掛かるので、該当行だけを削除します。
viでdd打てばそれで終わりですが、もっと安全な方法が無いかと探したらありました。
参考:
OpenSSH : WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

http://futuremix.org/2007/08/openssh-warning

ssh-keygen -F [IPアドレス]
で検索して
ssh-keygen -R [IPアドレス]
で削除
これは簡単。

iPhoneがフリーズしたら

持っているのはiPod touchですが、「設定」でメール設定を行っている最中に設定を閉じたら、設定が開けなくなった。何度試してもダメ。電源切ってもダメ。だったので強制シャットダウンを2回程やったら復帰。

その方法は、ホームボタンとスリープボタンの10秒同時押しでした。
画像つき説明はは以下URLより
iPhoneがフリーズした時に強制終了リセットコマンド [豆知識] – アイフォマニア(iPhoMania) ~iPhone情報配信サイト~

さくらのVPS ファイアーウォールを設定してみる

SSHの設定が済んだら次はファイアーウォールですよね。不要なサービスを止める作業も必要ですがそれだけでは新しくインストールした未設定のサービスが標的にされることもあるのでとりあえずアクセスを弾く機能は必要だと思います。

前回のSSHでも同じですが、この辺の設定を誤るとリモートログイン自体が出来なくなる可能性がありますので設定内容と手順には十分気をつけましょう。さくらのVPSの場合はブラウザ上でシリアル接続できるので最悪そこから設定を戻す事になります。(実は手順ミスって接続切られたorz)
参考:
にわかSEの独り言 CentOS 5.2 x64でiptablesを設定
基本参考サイトの通りなのですが若干気をつける点がありましたのでこちらで試した手順は以下の通り。
今までは/etc/sysconfig/iptablesを編集していたのですが、さくらのVPSにはそのファイルが初期状態でありません。それでコマンドラインで設定することにしました。念のためiptablesがストップしている事を確認し自動起動も外しておいたほうが良いと思います。それは万が一設定を間違って接続できなくなっても再起動すれば良いので、接続手段が無くなってしまったときにリモートか若しくはデーターセンター側のサポートで再起動してもらえば良いからです。
設定の初期化
# iptables -F
受信を全て破棄
# iptables -P INPUT DROP
送信を全て許可
# iptables -P OUTPUT ACCEPT
通過は全て破棄
# iptables -P FORWARD DROP
# サーバから外部に接続したコネクションのレスポンスを許可(2010/10/08追加)
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
PINGの許可
# iptables -A INPUT -p icmp -j ACCEPT
ローカルの許可
# iptables -A INPUT -i lo -j ACCEPT
ブロードキャストアドレス、マルチキャストアドレス宛のパケットを破棄
# iptables -A INPUT -d 255.255.255.255 -j DROP
# iptables -A INPUT -d 224.0.0.1 -j DROP
SSHの許可
# iptables -A INPUT -p tcp –dport 22 -j ACCEPT
SMTPの許可(submissionも追加) 2010/10/08修正
# iptables -A INPUT -p tcp –dport 25 -j ACCEPT
# iptables -A INPUT -p tcp –dport 587 -j ACCEPT
# iptables -A INPUT -p tcp –sport 25 -j ACCEPT
# iptables -A INPUT -p tcp –sport 587 -j ACCEPT
DNSの許可(source port 53 のルールも追加して下さい) 2010/10/08修正
# iptables -A INPUT -p udp –dport 53 -j ACCEPT
# iptables -A INPUT -p udp –sport 53 -j ACCEPT
HTTPの許可
# iptables -A INPUT -p tcp –dport 80 -j ACCEPT
POP3の許可
# iptables -A INPUT -p tcp –dport 110 -j ACCEPT
NTPの許可
# iptables -A INPUT -p udp –dport 123 -j ACCEPT
SNMPの許可
# iptables -A INPUT -p tcp –dport 161 -j ACCEPT
# iptables -A INPUT -p udp –dport 161 -j ACCEPT
SSLの許可
# iptables -A INPUT -p tcp –dport 443 -j ACCEPT
DROP対象をロギング
# iptables -A INPUT -m limit –limit 1/s -j LOG –log-prefix “[IPTABLES INPUT] : “
# iptables -A INPUT -j DROP
# iptables -A FORWARD -m limit –limit 1/s -j LOG –log-prefix “[IPTABLES FORWARD] : “
# iptables -A FORWARD -j DROP
設定の保存
# service iptables save
iptables起動
# service iptables start
ざっとこんな感じですが、FreeBSDのファイアーウォールと違ってハマったところは、私の調査不足なだけかも知れませんがレスポンスについてのルールを設定していないこと。サーバーから外部へのアクセスについては全許可してますが、そのアクセスのレスポンスについては何も設定していないので応答がDROPされてしまいました。今回の場合DNSの応答がDROPされた為、iptablesを起動してからSSH接続の応答が非常に遅くなって焦りました。
ちなみにSSH接続の応答が遅い時は経験上、接続元のIPを逆引きしようとして失敗している場合が多いので/etc/resolv.confで指定しているDNSサーバはアクセス可能なのか、今回のように53番が塞がっていないか確認します。そもそもSSH接続でDNS使うなよって思っているのですが、どうも逆引き→正引きを行ってIPアドレスが正しいものか認証しているようですね。理由が分かるとUseDNSをnoに変えるのもマズイかなっと思った。
追記:2010/10/08
探したらありました。絶対あるはずだと思ってた。
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
最初のACCEPT行の上に書いておけば良いかな。これでsource port 53のルールは不要になりました。多分SMTP関係のsource portのルールも不要になっているはずなので外してメールサーバを構築した時に確認してみます。
参考:
Kozupon.com – 解りにくいiptablesのアルゴリズム!