投稿

ラベル(ssh)が付いた投稿を表示しています

メールサーバの移行

イメージ
 自前のメールサーバを停止 これまで、自ドメインのメールサーバはVPS上に構築していた。 ・Ubuntu Server ・Postfix ・Dovecot ・spamAssassinと、BlackListの利用 Spam対策を行ってきたし、サーバ上でメールをトリガーにして各種プログラムを動かしたりしてきた。 メールサーバのメンテナンスは結構面倒くさくて、  ・Disk容量のチェック  ・不正アクセスのチェック  ・各種セキュリティパッチの適用 など、手間がかかる。 そこで、外部のサーバを利用することに…。 結構安くて使い勝手の良さそうなのが、「さくらのメールボックス」 3年契約で、3070円とな…。  メールアドレスは自分のだけなので、20GBまで利用可能!  (Gmailより大きいねぇ) ということで、早速契約。 アカウント設定を行って、既存のDNSを書き換える。WHOISも書き換えて完了。 SMTPとIMAPが利用できればOK。 ちょうど、GoogleがSPF設定していないと受信しないし、DKIMおよびDMARCに対応していないメールを弾くようになったので、対応しているのを確認。 さくらサーバ自体は、これまでお客さんのサーバとして何件も利用しているので、利用方法も難しくはない。  Webメールにも対応しているので、いざという場合にもありがたい。 ということで、各メールソフトの設定を変更。  PC(常時使用する3台)とタブレット、スマートフォンと台数は多いがそれ程手間はかからない。 問題は、旧サーバで送受信したメールの履歴だけれど、これはThunderbrdを使ってローカルに保存することで回避。  本当は、サーバtoサーバでMailboxに残そうとも考えたんだけど、古いメールはそれ程必要ないし、ローカルにバックアップしてあれば凌げるので、良しとする。 移行時にDNSの反映で若干時間がかかったものの、問題なく送受信できるのを確認して、作業完了。  これでメンテナンスの手間が減るので、安いもんです。

sshで自分のマシンに拒否られた

ssh localhost テストを行っていて、自分の使っているマシンに接続を行ったら、見慣れぬWarningが表示されて拒否られた。 $ ssh localhost いやいや、おかしいでしょう。 内容は以下のように出力された。 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:なんたらかんたら. Please contact your system administrator. Add correct host key in /home/yoshimura/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/yoshimura/.ssh/known_hosts:22   remove with:   ssh-keygen -f "/home/yoshimura/.ssh/known_hosts" -R "localhost" ECDSA host key for localhost has changed and you have requested strict checking. Host key verification failed. うーむ、そういえば、自分のマシンに接続したのは記憶では、こ

proxy経由のssh

proxy設置場所での作業 出先の環境では、proxyを通さないと外に出られない場合がしばしば存在する。 作業のノートPCを持って行き、いつもはテザリングで対応するのだけれど、転送ファイルのサイズがが大きかったり、電波状況の悪い環境だと、Wi-Fiを借りたり、有線での接続も多々有る。 で、いつも忘れてしまうので、まとめておく。 .ssh/configに書いてもよいのだけれど、このファイルは自宅やノート、他のマシンと同一にしておきたいので、変更を加えないようにする。 そこで、持ち歩くノートPCにのみ、proxyを通す設定をする。 .bashrc内にaliasとして設定しておく。 もちろん、テザリングでの作業も多いので、通常のsshとは別コマンドに設定する。 alias pssh="ssh -o ProxyCommand='nc -X connect -x 172.xx.yy.zz:3128 %h %p'" これで、端末から $ pssh hoge とすれば、プロキシー経由での接続ができるようになった。 もちろん、 $ ssh hoge なら、通常のssh接続だ。 自分で意識的にコマンド名を変えているので、間違えにくい・・・。 環境が変わったら、.bashrcを書き換えることで対応することに。 ああ、これで幸せにRemote作業ができるゎ。

ユーザーみて処理

bash使っていて 主にメモなんだけど…。 コンソール叩いていて、sshでリモート接続する場合が多い。 でもって、パスフレーズを60桁程度入力するのは面倒なので、keychainを利用している。 こいつを使えば、1度パスフレーズを入力すれば、バックグラウンドでssh-agent動かしてくれて、再入力の手間が省ける。 そこで、.bashrcの最後に #ssh keychain /usr/bin/keychain ~/.ssh/id_rsa source $HOME /.keychain/ $HOSTNAME -sh と書いていた。 ところが、管理者権限で作業しようとすると、 再度、パスフレーズを聞いて来る。 当然、rootではsshはしないので、ENTERでキャンセルしているのだけれど、これに気づかずコマンド入力し始めて、パスフレーズの入力を行っていることが多々有って…。 ということで、rootのときは、keychainを回避することにした。 if [ " ${USER} " != "root" ]; then #ssh keychain /usr/bin/keychain ~/.ssh/id_rsa source $HOME /.keychain/ $HOSTNAME -sh fi これで、OK。 作業中に、sudo -sしてrootになっても、パスフレーズの確認はされない。 シェルスクリプトをちょこっと書くだけで、精神衛生上非常に良いのでお勧め…。 逆に、rootのときだけ実行したい処理なんかも、同様に書いておけばお手軽ですな。 sudo コマンド で実行すれば良いのだろうけど、毎回sudo書くの面倒だし…。

オプションミスで慌てた

サーバの管理をしていて クラウド上のサーバを管理するために、いつも通りsshで接続。sudoでルート権限に上がる。 さて、今回webコンテンツも触る関係上、自分ユーザをapacheグループに入れておこうと。 別段、よくやる作業なので、気楽に…。 # usermod -G apache 自分 とやってしまっていた。 正しくは、 # usermod -a -G apache 自分 でないと、まずいのだ…。でも、この作業をした時に、ユーザの追加やら、グループの変更など、色々やって最後に自分の設定をして間違えていた。 この後、webコンテンツを、/var/www/htmlにコピーして、apacheグループに入れておいて便利〜などと浮かれていた。 ログアウトして、翌日、ログのチェック等作業を行おうとコンソールからsshする。 そして、sudo -sでルートに上がる。 [ユーザ名]はsudoersのファイルにありません。 とつれない表示。??? この時点では、何が起きたかわかっていない。 ことの重大さに気付き、冷や汗を書いたのだが・・・。 行った作業 おかしいな、sudoersに無いなんて、編集していないしなと思い、確認することに。 less /etc/sudoers パーミションが無いと言われる。 そりゃそうだ。 はっ!!! 見たり編集するためにはroot権限が必要だが、root権限を得るためにはsudoが使えないといけない。 詰んだ… rootでのsshは許可していないし、変更するにはsudoが必須。→ダメ historyで昨日の作業を見なおして、chmodのミスに気づく。 じゃ、wheelにも追加してやればいいじゃん。root権限が必要→ダメ /etc/groupを書き換える?root権限が必要→ダメ 結局、自分にroot権限を付与するためには、root権限が必要なわけだが、自分からroot権限を剥奪している以上、付与できないという綺麗な循環が成り立った。 ということは、このクラウドでは、rootに上がれず、何もできないことが判明。 解決策はちゃんとあった クラウドを借りてから、ずっとsshで作業していたけれど、そういえばWEB上の

sshのパスフレーズ自動入力

SSHは安心だけど とりあえずVPSとの接続はsshしか手段がない。 Macからのssh接続だと、最初の接続でパスフレーズをキャッシュするかと聞いてくるので、覚えさせればいい。 そうすれば、以後configに設定した名前だけで接続が可能になる。 この時、パスフレーズの入力は必要ない。 $ ssh vps でOK。 さてノートPCのUbuntuにid_rsaをコピーして、同様にconfigを.ssh以下に保存する。 端末から、Mac同様に接続を試みる。 $ ssh vps ここまでは、同じだ。 ところが、Ubuntuは自動ではパスフレーズをキャッシュしてくれない。 ssh-agentを起動 そのためのツールが別に用意されているので、起動する。 $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-SqRHipZc2573/agent.2573; export SSH_AUTH_SOCK; SSH_AGENT_PID=2574; export SSH_AGENT_PID; echo Agent pid 2574; すると、上記のような表示がなされる。この時点では、パスフレーズはキャッシュされていないので、続いて、追加作業をおこなっておく。 ここでは、ssh-addを実行する。 $ ssh-add Enter passphrase for /home/satoshi/.ssh/id_rsa: Identity added: /home/satoshi/.ssh/id_rsa (/home/satoshi/.ssh/id_rsa) 今度は、パスフレーズを聞いてくるので、正しく入力すればOK。 これで、準備完了だ。 早速接続してみる。 $ ssh vps Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-49-generic x86_64)  * Documentation:  https://help.ubuntu.com/ Last login: Sat Jul 27 21:07:50 2013 from xxx-yyy-zz-aa.sub.domain.jp username@vps:~$ 今度は、パスフレーズを聞かれることなく、接続が完了する。

ubuntu serverにssh

VPSの設定を開始 さてVPSが動作するのは分かったし、標準以外のOSも利用できるのも確認できたので、本番環境を少しずつ構築することに。 作業内容を忘れると面倒なので、作業しながら記録しておくことにする。 まずは、Ubuntu Server 12.04 LTS 64bit版をインストール。 普通serverは言語を英語で入れるのだけれど、これだけ簡単なら試しに日本語もいけるかもと思いテストしてみる。 もちろん、ubuntuが日本語を選択できなければ不可能だけれども…。選べるようだ。 ディスクも分割して使用する意味は、今のところないので、100GBまとめて利用することにして、インストール設定する。 昨日と同様のペースで進んでいく。 VNCなので(しかもブラウザ上)ちょっと表示がもたつく感じがするものの、特に問題なく終了。 光学メディアのイメージを強制排出して、再起動する。 sshのインストール $ sudo apt-get install openssh-server 実際は、これだけなんだけどね。 この時点で、パスワード認証での接続が可能になるので、確認のため接続してみる。 このままでは、アタックされ放題なので…。きちんと設定しておこう。 そのためにはsshの設定ファイルを編集する必要がある。使い慣れたエディタjedもついでに入れておく。 $ sudo apt-get install jed 準備は整ったので、設置ファイルを書き換える。 まずは、rootでのログインは無効にしておきたい。 $ sudo jed /etc/ssh/sshd_config PermitRootLogin no 保存したら、sshdの再起動。 $ sudo service ssh restart 設定ファイルを書き換えたら、これを忘れないように…。と自分に言い聞かせるw 鍵の生成作業 鍵を使った認証をするために、クライアントマシン上で鍵を生成する。 $ ssh-keygen -t rsa 好きなパスフレーズを入力。再入力も通ればファイルが生成される。 秘密鍵id_rsaと公開鍵id_rsa.pubだ。公開鍵はサーバ上に持っていく。 $ scp .