Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年12月4日

Hashimoto Naoto

ESXiサーバにパスワードなしでSSH接続したい

ピクトリンク事業部開発部インフラ課の「部署名が変わったのに未だ慣れず、前世の記憶に苛まれている系エンジニア」の橋本です。こんにちは。今年がもう終わるとか信じたくないです。

本記事は フリューAdvent Calendar 2018 の12/4分です。

 

さて本題。

ESXiはVMware社 が提供する、仮想環境を構築する上で便利に使える強力なハイパーバイザです。
無料で使えるライセンスもあるので、利用されている方も多いのではないでしょうか。

 

バージョン5以前はvSphereClientの導入が必要でしたが、バージョン6以降からは割り当てたIPアドレスにブラウザからアクセスするだけでGUIによる視覚的な操作も可能です。これまでに比べるとべんりでつよいです。

 

しかし、何か作業をする際にその都度IDとパスワードによる認証を行うのは、正直面倒です。

面倒はないほうが幸せです。孫子曰く「兵は拙速を尊ぶ」とも言います。書いてる私は兵ではないですし、兵の人がこの記事を読んでいる率は低い気もしますが、簡潔なのは良いことです。(この一文が冗長であるという厳然たる事実は全力で見逃してください)

 

また、コマンドライン操作であれば自動化もしやすいです。

そのため、楽ちんにSSH接続できる環境にしましょう! というのが今回のお題です。

やりかた

  1. SSH接続を許可する
  2. 接続するユーザを作成する
  3. ユーザに権限を付与する
  4. 鍵ファイルを配置する
  5. ssh/config に接続設定を書く

SSH接続を許可する

ESXiサーバのデフォルト設定では、SSH接続を拒否するようになっています。
GUIにID, パスワードでログインしてから[アクション] → [サービス] → [SSHの有効化] を選択しましょう。

接続するユーザを作成する

[ホスト] → [管理] から [セキュリティとユーザ] タブを選択し、[ユーザーの追加]から設定してください。
英数字大文字小文字を含む、それなりに強いパスワード設定が求められます。

ユーザに権限を付与する

[アクション] → [権限]から、先ほど作成したユーザに対して権限を設定します。

そのユーザで行いたいことによって、適切な権限を設定します。

 

ゲストサーバの状態を確認する用途であれば「読み取り専用」で十分ですし、ホストの起動/停止まで自動化したいという欲求があるならば「システム管理者」といった具合にです。
「システム管理者」はなんでもできるので、迷ったらコレにしておけば、なんて気もするかもしれませんが、システムを壊さないためにも不要な権限付与は控えるほうが無難です。

もしユーザを乗っ取られたときにえらい目に遭いたくもないですし。

鍵ファイルを配置する

以降はコマンドラインでの操作です。

鍵の生成

接続するユーザ用の鍵ファイルを作成します。

ssh接続用の公開鍵をすでにお持ちの場合、鍵の作成はスキップして大丈夫です。
パスワードなしで接続したいので、パスフレーズは空のままにしておきます。github等で秘密鍵を公開してしまってはダメですよ。

鍵の配置

接続するESXi、接続したいユーザ名に置き換えて実行してください。rootのパスワード入力を求められます。
公開鍵(id_rsa.pub)はauthorized_keysという名前で置かなければなりません。

 

具体例として、先ほど作成して権限を付与したユーザがhogeというユーザだった場合は、

/etc/ssh/keys-hoge/authorized_keys

という形にしてやる必要があります。

.ssh/config に接続設定を書く

ここまでで完了でも良いのですが、より簡略化を進めるために ~/.ssh/config に以下の設定を追記しましょう。

たとえば、esx-hoge-01, esx-hoge-02, esx-hoge-03… というESXiサーバにhogeユーザで便利に接続したいのであれば、以下のようにまとめてやることも可能です。

こうしておくと、

としてやるだけでパスフレーズなしでSSH接続することが可能です。楽ちんになりました。

 

楽ができるって幸せですね! 手を抜くためには全力を尽くしましょうね。

余談

ESXiサーバを再起動すると鍵が消えるという悲しい問題もあるのですが、そちらはまた別の記事をご覧ください。


2018年11月2日

awata

pacemaker+corosync環境を作成した時にハマった話

こんにちは。
ピクトリンク事業部インフラ課の粟田です。
今回は pacemaker+corosync環境をCentOS7上に構築した時にハマった話を書こうかと。

発生した問題

サーバ2台(CentOS7)にpacemakerとcorosyncをインストールして環境を構築中にcorosyncが疎通できていなくて、pcs status corosync や crm_mon を実行すると、お互いにOFFLINE……

ログを見てみると unclean(offline)の文字列が見えたので、ググって出てきた結果を参照すると、再起動したら直ったというようなものが出てきたけれども解決に至らず……

原因

corosyncの設定時には(DNSで解決可能な)ホスト名を指定してたんですが、corosyncはこのホスト名を127.0.0.1と認識してたんでした。

なんで127.0.0.1になるんだろうと原因探していると/etc/hostsが悪さしてたんでした。

127.0.0.1にホスト名書くなよ……

きっとこの辺の設定を全サーバで意識したくなかったせいなんだろうな。

あとがき

無駄に時間使っちゃったよ……


2018年10月31日

Kayo

sudo: ruby: コマンドが見つかりません。。。

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。

最近、サーバのリプレース作業の一環として、バッチスクリプトの移行作業を実施しています。この作業中、「sudo: ruby: コマンドが見つかりません」問題に出くわしたので、対処方法をシェアしたいと思います。

問題

フリューでは、rundeckを使って日次・月次のバッチを実行しています。

新しく構築した環境(以下、新サーバとします)に、従来通りの手順でスクリプトを実行しようとしたところ、エラーが出てしまいました。

今までは問題なく実行できていたのに、なぜ……?

対応策

sudoにオプションiをつけて解決しました。

詳細

エラーになっているexample.shの52行目を確認すると、rubyスクリプトを実行する記述がありました。

エラーの原因は、このrubyコマンドを実行した際、rubyコマンドが見つかりませんというエラーのようです。

実際に新サーバにsshログインし、rubyコマンドがないのかバージョン確認で検証してみました。

やはり、「ruby:コマンドが見つかりません」が出力されました。

旧サーバで実施すると問題ありませんでした。

rootで実施すると問題ありませんでした。

原因は、sudo経由で実行した場合、環境変数が引き継がれない...という問題でした。

もう少し詳しく説明すると

sudo はrootや他のユーザの権限でコマンドを実行することができますが、sudoの設定(/etc/sudoers)によっては、環境変数が引き継がれなかったり、上書きされる設定になっている事があります。

こちらは/etc/sudoersファイルの一部を切り取ったものです。

env_resetが設定されていてますが、これはsudoが実行された際、環境変数がsecure_pathの設定値に上書きされてしまいます。
またenv_keepにPATHがないためにPATHが引き継がれません。

上記のように、/etc/sudoersに追加することで、PATHを引き継ぐことができますが、
今回、私はsudoにオプション-iをつけて対応しました。オプション-iとは、何でしょうか?

こういう時は、–helpコマンドで調べると便利です。

では、 -i  オプションの効果を踏まえて、ruby の設定が環境変数のPATHに設定されているかを見てみましょう。

sudoだと環境変数のPATHが通っていません。
オプション-iを付けることにより、この問題を解消することができます。

補足

sudo のオプションに-Eがあります。

これも環境変数を維持してくれるものになりますが、これでは問題を解決することができませんでした。
原因は不明なので、こちらに関してはもう少し調査する予定です。

最後に

フリューでは、全ユーザにsudo実行できる権限を付与するかわりにrootでのシェル操作を禁止しています。

【理由】

  • セキュリティ向上のため
  • rootコンソールでシェル操作をすると、「誰」が「何」を操作したのか解りにくくなるため
  • sudoを使用してのroot権限での操作はログに残るので追跡調査が可能になるため

 

今回のように、sudoを使っているといくつかの問題に出くわすことがあります。
しかし、セキュリティを担保するためには、rootで直接実行するよりもsudoを使うよう習慣付けるのが望ましいです。
そのためにも、今回のようにオプションを調べて対応することが、今後も大切になりそうです。


2018年09月20日

Kayo

sshfsを使ってみました!

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。
今回は、使ってみてとても便利だった「sshfs」をご紹介したいと思います。

sshfsとは

SSHを経由して、他のサーバのディレクトリをマウントすることができるコマンドです。

なぜ便利なのか?

私は日々の業務でよくAnsibleを使ってサーバのミドルウェアのインストールや設定などを行います。
※Ansibleについては、以前ブログを書いているのでこちらをご覧ください。

 

今までは自分のローカルUbuntu環境からAnsibleを実行していたのですが、Macから実行すると環境違いでエラーになる事などがありました。
この状況を解消すべく、インフラ課のメンバー全員が同じ環境でAnsibleを実行できるよう専用サーバを構築しました。しかし、ローカルとリモートのコードを2重で管理という面倒な仕様になってしまい、何か解消する方法はないかと悩んでいました。

blog1

そんな時見つけたのが「sshfs」です。
これを使ってリモートで直接コードを修正しつつ、ローカルでのデバッグ実行も可能となり、とても便利になりました。

NFSと比較した場合、リモートサーバでコマンドを実行する(=SSHでログインして実行する)環境が既にできあがっているので、ローカル側にプログラムをインストールするだけで実現可能というお手軽さもあります。

使い方は簡単

  • sshfsのインストール(Ubuntuの場合)

  • マウント方法

例として、私のローカルマシーンの/testというディレクトリを作成し、サーバserver1の/home/fujimoto.kayoディレクトリをマウントします。

あとは、sshfsコマンドをローカルマシーンから実行するだけです。

これでマウントができた状態です。実際にサーバserver1の/home/fujimoto.kayo配下には、example-ansibleディレクトリが存在しますが、
ローカルマシーンの/test配下にも同じexample-ansibleが存在します。

  • アンマウント方法も簡単

最後に

コードの2重管理がなくなったり、コードの修正をローカルで使い慣れている環境のエディタで編集できたり、ちょっとした工夫で日々の業務がスムーズに行えるようになりました。

是非、皆さんもこの「sshfs」を使ってみて下さい!


2018年08月27日

Kayo

サーバ増設したらDNSラウンドロビンが壊れた!?

はじめに

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。

 

先日、稼働中のサーバにアクセスが集中したため、サーバ増設を行いました。

その作業の1つとして、DNSラウンドロビン設定に増設したサーバを追加したのですが、上手く負荷分散されず、今まで特に問題なく利用していたDNSラウンドロビンの思わぬ落とし穴にはまってしまったので、忘れないようにブログに書いておきます。

DNSラウンドロビンとは

1つのドメイン名に複数のIPアドレスを割り当て、負荷を分散させる技術のこと。

スライド1

 

メリットは、簡単に設定ができることです。

スライド2
私が行ったように急遽サーバ増設が必要になった場合でも、zoneファイル上の対象ドメイン名に増設したサーバのIPアドレスを追加するだけで負荷分散してくれます。

 

デメリットは、万が一、サーバに障害が発生しても検知することができず、負荷を分散し続けてしまうこと。結果クライアントにエラーが返されてしまいます。

はまったこと

zoneファイル上の対象ドメイン名(test.com)に、増設したサーバ2台のIPアドレスを追加しました。

下記、実際に追加したzoneファイルの中身です。

この変更を加えるまでは、問題なく4台で負荷分散できていたのですが、2台を追加したことで、この2台しか負荷分散ができなくなったしまったのです。

スライド3

原因

DNSラウンドロビンの数に制限があるかなど、色々調べてみましたが、

原因は、増設したIPアドレスの「一致長が変わったのが原因でした。※参考になったURLがこちら

スライド4

4列目のIPアドレスと問い合わせる側の自分のIPアドレス(192.168.0.1)を比較し、一致する部分の長さが最も大きくなるものが使われるようです。つまり、増設した192.168.0.6と192.168.0.7が選択され、それ以外のものは使われなくなってしまったということです。

対応策

一致長が異なるのが問題だったので、これを合わせてやる(別のIPアドレスを使う)ことで増設することができました。

まとめ

DNSラウンドロビンはとても簡単に設定ができるので、弊社でも長らく利用してきました。

今回、思わぬ落とし穴にはまってしまったのですが、DNSラウンドロビンの問題は今回のものだけではありません。例えば、DNSサーバのBINDのバージョン9.13.2(unstable版)では、そもそもラウンドロビンが動作しなくなっているようです。
DNSは名前解決に専念させ、負荷分散はロードバランサに任せるなど、今後もDNSラウンドロビンを使い続けるかどうか慎重な検討が必要のようです。