概要

　筆者がRackspaceなどのクラウドサーバでCentOS8を導入した直後にする初期設定を備忘録として残します。

ステップ１　最初の作業

　まずは、いくつかのチェックとSE Linuxの停止を行います。

端末ソフトを用意する

筆者はputty本家英語版を使用していますが、好きな端末ソフトを使用して、ひとまずはクラウドでサーバを立ち上げたときに表示されたパスワードを使ってrootユーザーでログインをします。しばらくはこのrootログイン状態の端末を使って作業しますので、閉じないようにしましょう。また長時間放置してしまうとセッションがタイムアウトしますので、後述しているKeepAlive（キープアライブ）の設定はやっといたほうが無難です。

導入したCentOSのバージョンを確認する

[root@web02 ~]# cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)

SE Linuxを停止する

これは人によって意見が分かれるところです。より厳密なセキュリティでサーバを運営したい人は、この操作はスキップしてください。

[root@web02 .ssh]# setenforce 0
[root@web02 .ssh]# getenforce
Permissive

次に、このSELinuxの設定を永続化します。

[root@web02 .ssh]#vi /etc/sysconfig/selinux
ここで「SELINUX=permissive」を設定する

ステップ２　一般ユーザー

　これからこのサーバで主に使用する一般ユーザーの作成と、そのユーザーだけが実行できる制限を設定していきます。制限は具体的には以下のようなものがあります。

• このユーザーだけがsuコマンドでrootユーザーになれるようにする
• SSHを使ってこのユーザーだけが当サーバにリモートからログインできるようにする

ユーザーグループを作成する

　ここで作成するユーザーグループに、自分とHTTPDなどを入れておけば、WebRootフォルダなどがユーザーのホルダの配下にある場合などに、WordpressなどでWEBサーバとして書き込みをする必要が出たときなどに便利です。今回は筆者の会社名スターズ・システム㈱からとった「stars」というグループを作ります。

[root@web02 ~]# groupadd stars

一般ユーザーを作成する

　通常つかう一般ユーザーアカウントを作ります。このユーザーのみがRootユーザーになることができ、さらにこのユーザーのみが秘密鍵を使ってこのサーバに唯一アクセスできるユーザーにします。今回は「sptest」という一般ユーザーを作りました。

[root@web02 ~]# useradd -g stars sptest

ユーザーのパスワードを設定する

[root@web02 ~]# passwd sptest
Changing password for user sptest.
New password: 《新しいパスワードを入力》
Retype new password: 《確認のためパスワードを再度入力》
passwd: all authentication tokens updated successfully.

sptestからしかrootユーザーになれなくする

　誰でもsuコマンドを使えてしまうのは良くないので、今回作成した一般ユーザー「sptest」からしかrootユーザーになれないように設定します。

ユーザーをwheelグループに追加する

[root@web02 ~]# usermod -G wheel sptest

ユーザーのsu制限を有効にする

[root@web02 ~]# vi /etc/pam.d/su

viエディタが起動して、「/etc/pam.d/su」ファイルの内容が表示されますので、下記の強調表示した行の先頭の「＃」を取り除きます。

#%PAM-1.0
auth            required        pam_env.so
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            substack        system-auth
auth            include         postlogin
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         include         postlogin
session         optional        pam_xauth.so

　変更したら「：ｗｑ」コマンドで保存してｖｉエディタを終了します。次に、

ステップ３　SSHを設定

ユーザーsptestがssh経由でサーバにログインできるようにする

　この特別な一般ユーザーsptestが、端末ソフトputtyを使って自宅からサーバにアクセスできるように設定します。sshではこのユーザーのみがシステムに秘密鍵を使ってログインできるようにします。rootユーザーのログインや、秘密鍵ファイルを持っていないユーザーのログインを禁止します。

puttygen.exeを使って公開鍵・秘密鍵を作成する

今回は端末ソフトに無料のPuttyを使用しますので、putty.exeに付属しているキー作成ソフトの「puttygen.exe」を使って、SSH用の公開鍵と秘密鍵を作ります。

puttygen.exeを起動し、一番左の「RSA」または古いバージョンでは、「SSH-2 RSA」を選択した状態で、「Generate」または「生成」ボタンを押下してください。そして「Key」または「鍵」と書かれたなにもない領域にマウスを動かし続けてください。このマウスのランダムな動きを利用して鍵を生成しています。鍵の生成が終わると、次のような画面になります。

「Key PassPhrase」または「鍵のパスフレーズ」欄に、自分の好きなパスワードを設定します。次の欄「confirm passphrase」か「パスフレーズの確認」の欄には、もう一度パスワードーを入力します。
　入力ができたら、「公開鍵の保存」または「Save public key」で公開鍵を、「秘密鍵の保存」または「save private key」で秘密鍵を保存してください。秘密鍵は誰にも渡さないように気をつけて保管してください。
　また、上記画面の「Public key for pasting into OpenSSH authorised_keys file」と書かれているパネル内に表示されている情報をすべて選択した状態でCtrl+Cを押してコピーし、テキストエディタに貼り付けてOpenSSH用公開鍵として保存しておいてください。

公開鍵をサーバに設定する　その１　puttyの公開鍵を使う

puttygenで「公開鍵の保存」ボタンを押して保存したputty形式の公開鍵を使って、サーバ側で以下の操作を行う例です。

[root@web02 .ssh]# cd /home/sptest
[root@web02 .ssh]# mkdir .ssh
[root@web02 .ssh]# chmod 0755 .ssh
[root@web02 .ssh]# cd .ssh
[root@web02 .ssh]# vi src.txt
	      　　　puttyの公開鍵はテキストファイルなので
	      　　　パソコン側で開いて内容をviエディタへコピペして保存する
[root@web02 .ssh]# ssh-keygen -i -f src.txt > authorized_keys
[root@web02 .ssh]# rm src.txt
[root@web02 .ssh]# chmod 0644 authorized_keys

公開鍵をサーバに設定する　その２　opesshの公開鍵を使う

puttygenで「Public key for pasting into OpenSSH authorised_keys file」と書かれているパネル内に表示されてい他情報を使ってサーバ側で以下の操作を行う例です。すでにOpenSSH形式なので、ssh_keygenツールは必要ありません。

[root@web02 .ssh]# cd /home/sptest
[root@web02 .ssh]# mkdir .ssh
[root@web02 .ssh]# chmod 0755 .ssh
[root@web02 .ssh]# cd .ssh
[root@web02 .ssh]# vi authorized_keys
	      　　　ここに情報を貼り付ける。
[root@web02 .ssh]# chmod 0644 authorized_keys

リモートからログインできるか実験－準備編

puttyを設定する　その１

putty.exeを起動します。すると左のような画面が立ち上がります。筆者は英語版を使っていますが、日本語版の人も入力箇所は同じなので、参考にしながら設定を進めてください。
入力する箇所は３つです。

• Host Name (or IP address)
  サーバのFQDNかIPアドレスを入力します。
• Connection Type
  ここは「SSH」にチェックを入れてください
• Saved Sessions
  ここには適当な名前を入れてください

３つの入力項目を入力したら青枠で示した「Save」ボタンを押してひとまず保存しておきます。

puttyを設定する　その２

　保存ボタンを押したら、そのまま「Category（カテゴリ）」メニューの「Connection（接続）」をクリックして画面を切り替えます。すると、左のような画面になります。
　ここでは、なにもしていないときにタイムアウトしないようにキープアライブの設定を行います。

• Seconds between keepalive (0 to turn off)
  日本語環境では「Keepaliveの間隔（秒、０でオフ）」みないな感じだったと思います。ここに適当な秒数を指定しておいてください。だいたい３０秒前後で好きな間隔を選び、それでもタイムアウトでセッションが切れてしまうようなら間隔を短くすれば良いと思います。

puttyを設定する　その３

　今度は「Auth（認証）」メニューの、「Private key file for authentication」です。日本語だと「認証のためのプライベートキーファイル」みたいな表示になっていると思います。

• 「Browse（参照）」ボタンを押下して、puttygen.exeで作った秘密鍵のファイルを指定します。

puttyを設定する　その４

　カテゴリーメニューで「session」を選択して、「puttyを設定する　その１」で紹介した起動直後の画面に戻り、「Save（保存）」ボタンを押して設定を保存します。

コラム：最初の端末画面は閉じちゃダメ

Rackspaceなどでクラウドにサーバを立ち上げた直後は、端末ソフトに何も設定しない状態で「rootユーザーでログイン」をすると思いますが、このrootログインした端末だけは最後まで閉じないでおいたほうが無難です。もしも設定をミスってリモートからのログインができなくなってしまっても、この画面を開いていればリカバリがやりやすいので。

リモートからログインできるか実験－実行編

putty.exeの設定が終わったらいよいよサーバにインターネット経由で接続できるかどうかテストします。putty.exeで保存したセッションを指定して「Open（開く）」を選択してください。

login as: sptest
Authenticating with public key "rsa-key-20131025"
Passphrase for key "rsa-key-20131025":《パスワードを入力》
Activate the web console with: systemctl enable --now cockpit.socket

Last failed login: Sun Oct 25 00:55:25 UTC 2020 from 149.245.188.122 on ssh:notty
There were 2 failed login attempts since the last successful login.
[sptest@web02 ~]$
[sptest@web02 ~]$

リモートからログインできるか実験－トラブルシューティング編

Server Refused our keys

　SSHでよくあるトラブルのトップ５に入る問題がこれです。たいていは、サーバ側の.sshフォルダ以下のパーミッション設定がおかしいか、ファイルそのものが無いか、open ssh形式での公開鍵になっていないか、SE Linuxに阻まれているかだとおもいます。

• ファイルやフォルダが適正な位置にない
  要するに/home/《ユーザー名》/.ssh という決まった場所に.sshフォルダがあることと、「authorized_keys」ファイルのファイル名が正しいかをチェックします。.sshを置くユーザー名がそもそも間違っていたということも多々ありますので、よくチェックしてください。
• ファイルのパーミッションが間違っている
  .sshフォルダのパーミッションは「７５５」
  authorized_keysファイルのパーミッションは「６４４」
• 公開鍵がopen sshの形式になっていない
  puttyの公開鍵はそのままだとLinuxで認識できない形式です。前述のSSH設定の章でも説明しましたが、「ssh-keygen」ツールを使って、putty形式の公開鍵をopenssh形式に変換してから「authorized_keys」ファイルに入れなければなりません。これもかなりの「よくあるトラブル」です。
• SE Linuxにひっかかっている
  SE Linuxにひっかかる場合も多々あります。本稿ではすでに最初の段階でSE Linuxは無効になっているので必要ありませんが、SE Linuxを有効にしている人で、上記のチェックが全部正しそうで行き詰まってしまったら、一度SE Linuxを無効にしてみるのも手です。

そもそも接続ができない

　そもそもputtyで接続すらできない場合もあります。そんな時は下記を疑ってみてくだし。

• サーバのIPアドレスを入れ間違えている
  ポカミスってやつですね。puttyの画面は小さいのでしっかり確認してみてください。
• ファイヤーウォールが閉じている
  普通はクラウドでサーバを購入したらSSHは標準で入った状態で開放されます。しかし、なんらかの原因でSSHのポート番号２２番が閉じていることも考えられます。CentOS8では、以下のコマンドで調べることができます。「firewall-cmd --list-services」もしも、sshが入っていなかったら、以下のコマンドで追加できます。「firewall-cmd　--add-service=ssh」

ステップ４　SSH設定を強化する

　ステップ３で行った設定は、サーバのSSH機能を使ってかろうじて自宅のパソコンからクラウドのサーバへログインできるようしたという程度のものです。まだrootユーザーが秘密鍵ファイルを使わないでパスワードでログインすることもできてしまいますし、どのユーザーでもSSHでログインできてしまいます。そこで、SSHによるログインをもっと強固なものにしたいと思います。やることは以下のとおりです。

• rootユーザーが直接ログインできないようにする
• 秘密鍵を持ったユーザーしかログインできないようにする
• 特定のユーザー「sptest」しかログインできないようにする

sshd_configの変更

エディタでsshdの設定ファイルを変更します。

[root@web02 .ssh]# vim /etc/ssh/sshd_config

sshd_configファイルの以下の部分を修正します。

PermitRootLogin yes を no に変更
PasswordAuthentication yes を no に変更
GSSAPIAuthentication yes を no に変更
UsePAM yes を no に変更

念の為、以下の項目も確認します。

KerberosAuthentication no（デフォルトでno）
ChallengeResponseAuthentication no（デフォルトでno）

そして、公開鍵認証だけ有効にします。
筆者の環境ではデフォルトでYesでした。
PubkeyAuthentication yes

ファイルの最後に追加

sshd_configファイルの末尾に、次の行を追加することで、sptestユーザーのみがこのシステムにリモートログインできるようになります。

AllowUsers sptest

sshdを再起動

[root@web02 .ssh]# systemctl restart sshd

ステップ５　WEBコンソールを入れる

　CentOS８では、ウェブコンソールというウエブベースの管理画面が使えるようになっています。ソフトウエアの更新やファイヤーウォールの設定などもこのWebConsoleから行えます。
　ただ、このような管理画面を外部からのアクセスが出来るように設定するのは怖いので、puttyのSSHトンネリング機能を使って実現したいと思います。

Web Consoleのインストール

　下記の水色の部分が入力したものです。

[root@web02 .ssh]# yum install cockpit
Last metadata expiration check: 0:00:57 ago on Sun 25 Oct 2020 11:10:27 AM UTC.
Package cockpit-196.3-1.el8.x86_64 is already installed.
Dependencies resolved.
======================================================================================
 Package            Architecture      Version                 Repository         Size
======================================================================================
Upgrading:
 cockpit            x86_64            211.3-1.el8             BaseOS             71 k

Transaction Summary
======================================================================================
Upgrade  1 Package

Total size: 71 k
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] cockpit-211.3-1.el8.x86_64.rpm: Already downloaded
warning: /var/cache/dnf/BaseOS-xxxxxxxxxxxxxxxx/packages/cockpit-211.3-1
.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID xxxxxxxx: NOKEY
CentOS-8 - Base                                       1.6 MB/s | 1.6 kB     00:00
Importing GPG key 0xxxxxxxxx:
 Userid     : "CentOS (CentOS Official Signing Key) "
 Fingerprint: 99DB XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX C65D
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
Is this ok [y/N]: y
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                 1/1
  Upgrading        : cockpit-211.3-1.el8.x86_64      1/2
  Cleanup          : cockpit-196.3-1.el8.x86_64      2/2
  Running scriptlet: cockpit-196.3-1.el8.x86_64      2/2
  Verifying        : cockpit-211.3-1.el8.x86_64      1/2
  Verifying        : cockpit-196.3-1.el8.x86_64      2/2

Upgraded:
  cockpit-211.3-1.el8.x86_64

Complete!
[root@web02 .ssh]#

Web Consoleを起動

[root@web02 .ssh]# systemctl enable --now cockpit.socket

puttyにトンネリングを設定

 Web Consoleは、9090番のポートでWebサービスを実行しますので、puttyにはサーバの9090番ポートをローカルホストの9090番にトンネリングしてあげるように設定します。

　Category（カテゴリー）メニューのSSHの下の「Tunnels（トンネル）」を選択します。「Source Port（ソースポート）」には、トンネリングしたいサーバのポート番号を入力します。この場合は「9090」と入力します。
　次に、ローカルホスト側のポート番号を指定します。「Destination」の欄に「localhost : 9090」と入力して、「Add（追加）」ボタンを押します。すると、一覧に入力した9090番のポートの情報が反映されたと思います。
　設定ができたら、カテゴリーメニューの「Session（セッション）」に戻って、設定を忘れずに保存してください。

WebCpnsoleを使ってみる

　まず、puttyを新たに起動して、サーバにログインしておきます。これで9090番ポートのポートフォワードができたはずです。次に、パソコン側でウェブブラウザを立ち上げて、アドレス欄に「localhost:9090」と入力します。

ステップ６　RackspaceMonitorAgent

　Rack Spaceでクラウドサーバを借りた場合、サーバの情報が表示されるパネルで、サーバの状態をモニターすることができます。Monitorエージェントをインストールしていない状態でサーバの管理画面を見ると、モニタリングエージェントの項目の横に、「Install Agent」か「How to install Rackspace monitor agent」のようなリンクがあるとおもいます。このリンクをクリックすると、そのサーバに特化した設定サンプルを見ることが出来ます。

現在は CentOS-7までしかないが・・・

　２０２０年１０月現在では、このヘルプページで選択できるCentOSは、CentOS-7までしかないのですが、筆者が試したところ、少し変更するだけで使えましたので、ここで共有したいと思います。まずは、サーバの管理画面のモニタリングエージェントの項目の「Install Agent」リンクをクリックしてください。

　まず、「Choose Your Platform」の欄で「Linux」を選択します。次に、「Step by Step」というタブをクリックします。そして最後に「Choose Your Distro」で「ContOS-7」を選択します。
　すると、あなたのサーバ向けの設定サンプルが表示されます。

この設定サンプルの通りに作業すれば、Rackspaceモニタリングエージェントをインストールすることができますが、CebtOS8では２つだけサンプルと違う部分があります。
１．まず設定サンプルの中の「centos-7」の記述は全て「7を8に置き換える」ことが必要になります。
２．次に、全てのインストール作業が終了すると、最後にモニタリングエージェントの起動方法のヒントが表示されますが、これがヘルプページで書かれているものとは違っています。筆者はインストール後に表示された「service rackspace-monitoring-agent start」を使用しました。

同一カテゴリの記事一覧

• 【テクニカル】CentOs8 インストール後にすべきことメモ
• 【テクニカル】一番簡単なCentOS PHP7.3から7.4への移行方法
• 【テクニカル】パソコンへのLinuxの導入
• 【テクニカル】Open Graph 手書きのウエブサイトをSNSでシェアできるよう…
• 【テクニカル】C# NotifyIconの実装
• 【テクニカル】一番わかりやすいBracketsの導入とトラブルシューティング
• 【テクニカル】無料SSL Let's EncryptでWordpressサイトをSSL化する
• 【テクニカル,未分類】【Windows10】ホテルのWiFi接続時に「インターネット接続…
• 【テクニカル】Let's Encryptのトラブルシューティング
• 【テクニカル】C# で Task を使う
• 【テクニカル】MacBookProにBootcampでWindows10を入れる際のポイント
• 【テクニカル】PHPMailer導入とトラブル対策
• 【テクニカル】PHPMailerのログをSYSLOGに出力
• 【テクニカル】Visual Studio 2017で使うSSHの秘密鍵をputtygenで作成す…
• 【テクニカル】Wordpressの投稿一覧で要らない項目を削除する方法
• 【テクニカル】Google SEO の要点 - Better Google SEO
• 【テクニカル】wordpressを始める前に絶対すべき準備 - Things you need …
• 【テクニカル】Wordpress URL設定間違い・サイト移動のトラブル対応 - Ho…
• 【テクニカル】VisualStudio2013セットアッププロジェクトを戻す！ - Vis…
• 【テクニカル】C# でWindowsサービスの「説明」の文を取得する方法 - C# …
• 【テクニカル】動画配信に最低限必要なモノ（動画配信環境）
• 【テクニカル】動画配信のトラブル対処（ブーンというノイズが乗る）
• 【テクニカル】client denied by server configuration: