GitLabのメール設定(SendGrid)

前回「UbuntuにGitLabをインストール」の続きです。

GitLab からユーザにメールの通知ができるようにします。
メールの送信はSendGrid というメール配信サービスを利用することにしました。

はじめに

GitLab のメールを送信する方法は下記のどちらかになります。

  • Sendmail やPostfix のようなメールサーバ(MTA)をインストールして送信する
  • SMTP サーバ経由で送信する

今回、前者の方でやろうと進めていましたが手こずったので、諦めて後者の「SMTP サーバ経由で送信する」で対応することにしました。

SMTP サーバの選定

軽く使う程度なので、無料で使えることと設定がしやすさよさそうだったという点で、Twilio社のSendGrid にすることにしました。

SendGrid ロゴ

Free プランは100通/1日を上限として無料で使うことができます。
最初の3ヶ月だけ無料というような期間限定もないです。

SendGrid 料金プラン

環境について

ローカル環境

GitLab はLAN環境でのみアクセス可能(インターネット上に公開しない)

  • Raspberry Pi 4 Model B / 8GB
  • Ubuntu Server 20.04.4 LTS (64bit)
  • GitLab Enterprise Edition 14.9.3-ee (Omnibus)

ウェブサービス

  • SendGrid

SendGrid の設定

1. SendGrid のアカウントを作成

SendGrid のウェブサイトにアクセスして、Free プランでアカウントを作成します。
一般的な手順で作成できたので解説は省略します。

2. Sender Identity の作成

アカウントを作成してログインすると、下記の緑色のバー「最初のメールを送る前にsender identity の作成が必要」があるので、[Create a sender identity] をクリックします。

SendGrid > Sender Identityの作成

※ サイドバーの[Settings] > [Sender Authentication] からもSender Identity を作成することができます。

SendGrid > Sender Identityの作成 > 配信者の認証方法を選択

Sender Identity は下記の2つの方法で作成できます。(両方も可能)

  • Domain Authentication
    • 送信ドメイン認証(SPFとDKIM)。独自ドメインのDNS の設定が必要
  • Single Sender Verification
    • SendGrid を使って送信するメールの差出人の情報を登録する。メールを受信できるメールアドレスが必要

今回は、DNS の設定が不要な”Single Sender Verification” にするので、Single Sender Verification の右の[Get Started] をクリックします。

SendGrid > Sender Identityの作成 > Create a Sender

送信したメールの受信者側に表示される情報(メール差出人の名前・メールアドレス)や迷惑メールの防止に関する法律を遵守する上で必要な情報(会社の住所など)を登録します。

日本の場合は特定電子メール法に、特定電子メールの送信者に課される表示義務(特定電子メールである旨、送信者の情報:氏名・名称・住所、送信者の送信に使ったメールアドレス、送信者の受信用のメールアドレス)というのがあるので、この辺のことと思われます。

今回の使用目的はGitLab ユーザーへのメール通知なので、ここの登録を難しく考えるより、アカウントの乗っ取りを気をつける方を重視しようと思います。(→後述「4. アカウントの保護(2要素認証の設定)」)

入力にあたっては、下記のサイトが参考になりました。

入力して[Create] をクリックすると、”From Email Address” に入力したメールアドレス宛にメールが送られ、下記のページが表示されます。

SendGrid > Sender Identityの作成完了(仮)

届いたメールがこちらです。

SendGrid > Sender Identityの作成 > メール受信で認証

[Verify Single Sender] をクリックします。

SendGrid > Sender Identityの作成 > メール受信で認証完了

SendGrid を使って送信するメールの差出人のメールアドレスが認証されました。
[Return to Single Sender Verification] をクリックすると元のページに戻り、下記のように認証された差出人の情報が表示されています。

SendGrid > Sender Identityの作成完了

3. API Key の作成

サイドバーの[Settings] >[API Keys] をクリックします。

SendGrid > API Keyの作成

[Create API Key] をクリックします。

SendGrid > API Keyの作成 > 権限の選択

API Key Name” に任意の名称を入力して、下記のいずれかを選択します。

  • Full Access
  • Restricted Access
  • Billing Access

今回の使用目的はGitLab ユーザーへのメール通知なので、機能制限ができる”Restricted Access” を選択します。

SendGrid > API Keyの作成 > Restricted Access

Access Details の”Mail Send” の右にある線をクリックして”Full Access” まで青い線が引かれた状態にして[Create & View] をクリックします。

SendGrid > API Keyの作成完了(API Key表示)

作成されたAPI Key が表示されるのでコピーしてどこか安全な場所に保存しておきます。

  • 表示されているAPI Key は再度表示できない
  • 安全な場所に保存とのことなので、パスワードマネージャーに作成したSendGrid のアカウントの一項目の情報として登録しておきました

[Done] をクリックすると元のページに戻り、下記のように作成したAPI Key が表示されます。

SendGrid > API Keyの作成完了

左のAPI Key ID はAPI Key の一部で、中央のAPI KEY はマスクされた状態でクリックなどしても表示されないようになっています。

4. アカウントの保護(2要素認証の設定)

本題からそれますが、前述「2. Sender Identity の作成」の手順の途中で記載したアカウントの乗っ取りを気をつける方を重視の対応です。

サイドバーの[Settings] >[Two-Factor Authentication] をクリックして、Authy またはSMS を選択して2要素認証の設定をします。
※ 手順の解説は省略します

GitLab の設定

1. /etc/gitlab/gitlab.rb

GitLab の公式ドキュメントを参考に設定します。

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.sendgrid.net"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "apikey"
gitlab_rails['smtp_password'] = "the_api_key_you_created"
gitlab_rails['smtp_domain'] = "smtp.sendgrid.net"
gitlab_rails['smtp_authentication'] = "plain"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
# If use Single Sender Verification You must configure from. If not fail
# 550 The from address does not match a verified Sender Identity. Mail cannot be sent until this error is resolved.
# Visit https://sendgrid.com/docs/for-developers/sending-email/sender-identity/ to see the Sender Identity requirements
gitlab_rails['gitlab_email_from'] = 'email@sender_owner_api'
gitlab_rails['gitlab_email_reply_to'] = 'email@sender_owner_reply_api'

黄色いマーカーの3ヶ所に任意の値を指定します。

  • smtp_password
    • 作成したAPI Key
  • gitlab_email_from
    • 認証したSender Identity のFrom Email Address
  • gitlab_email_reply_to
    • 認証したSender Identity のReply To

設定ファイルを再読み込みして設定を反映します。

sudo gitlab-ctl reconfigure

2. テストメールの送信

下記のコマンドを実行してテストメールを送信します。

sudo gitlab-rails console

Notify.test_email('[email protected]', 'Message Subject', 'Message Body').deliver_now
→ テストメールが送信される

※ 黄色いマーカーの3ヶ所に送信先メールアドレスメールのタイトルメールの本文を指定します。

3. ユーザの作成

ブラウザでGitLab にroot ユーザなどAdministrator 権限のユーザでログインしてユーザを作成して、作成時に登録したメールアドレスにGitLab からメールが届くか確認します。
届いたメールのリンクをクリックして初期パスワードを設定することで作成したユーザが使えるようになります。
※ 手順の解説は省略します

あとがき

これで普通にGitLab を使えるようになったのではないでしょうか。管理者ユーザと一般ユーザを作って管理するという感じで。

インストール後の推奨される次のステップ、他にも何かあるので必要そうであれば対応してみようと思います。

参考

UbuntuにGitLabをインストール

UbuntuGitLab をインストールします。
筐体はRaspberry Pi で、Ubuntu をインストール直後の状態にインストールします。

環境について

  • Raspberry Pi 4 Model B / 8GB
  • Ubuntu Server 20.04.4 LTS (64bit)

ハードウェア要件

  • ストレージ(空き容量2.5 GB)
  • CPU(推奨4コア、500ユーザー)
  • メモリー(4GB RAM、500ユーザー)

今回使うRaspberry Pi は、CPU は最小要件をぎりぎり満たしていました。

準備

Raspberry Pi はUbuntu をインストールしてパソコンからSSH接続できることを確認していました。
GitLab をインストールする前に下記の作業をしておきます。

1. パッケージを最新に更新

sudo apt update
sudo apt upgrade

2. ストレージの空き領域の確認

pwd
→ /home/ubuntu
df -h ./
→ Filesystem      Size  Used Avail Use% Mounted on
   /dev/mmcblk0p2   30G  2.8G   26G  10% /

インストール

GitLabのコミュニティサイトに推奨のインストール方法として、オールインワンパッケージのインストール手順が記載されていたので、こちらを参考にGitLab のインストール作業を進めます。

オールインワンパッケージ(推奨のインストール方法)

1. 依存パッケージのインストールと設定(必須)

1行目のパッケージのアップデートは準備作業で完了しているので不要。
2行目のライブラリのインストールは、既にSSH接続できているのでOpen SSHサーバは不要ですが、実行しても失敗するだけなのでこのまま実行します。

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates

2. 依存パッケージのインストールと設定(任意)

メールの送信に使うPostfix をインストールします。
外部のSMTPサーバーを使う場合は不要です。

sudo apt-get install -y postfix
→ 設定画面が表示
   "Internet Site" を選択
   "mail name" に外部DNS名 ※今回「a.example」を入力

3. GitLabパッケージのリポジトリへの追加

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

4. GitLabのインストール

EXTERNAL_URL に自分のサーバのURLを指定します。
イントラでHTTPSにしないので、スキーム部はhttpにします。(気が向いたら後でHTTPにします)

sudo EXTERNAL_URL="http://gitlab.a.example" apt-get install gitlab-ee

インストールが完了すると、下記のメッセージが表示されました。

インストール完了

パスワードのリセットを強く推奨と書かれています。

設定のオプションを理解したければ、Omnibus GitLab readme を読めと書かれています。

5. ストレージの空き領域の確認

GitLab をインストール後の容量を確認します。
Used がインストールする前は2.8G だったので、約3.8G 増えています。
ハードウェア要件は空き容量2.5 GB でしたが、1.3G 程余分に使われたようです。
空き容量は22G と潤沢ではないですが、とりあえずはこれでよしとします。

df -h ./
→ Filesystem      Size  Used Avail Use% Mounted on
   /dev/mmcblk0p2   30G  6.6G   22G  24% /

6. rootユーザのパスワードの確認

/etc/gitlab/initial_root_password というファイルにroot ユーザのパスワードが保存されているので確認します。
このファイルは24時間後に自動削除されるようです。

sudo cat /etc/gitlab/initial_root_password
→ Password: <パスワード>

7. ブラウザでGitLab にログイン

インストール完了時に「http://gitlab.a.example」でGitLab が使えるというメッセージがありましたが、LAN環境のサーバでDNSの登録をしていないので、サーバのIPアドレスを指定した下記のURLにアクセスすると、ログインページが表示されました。

  • http://<サーバのIPアドレス>/gitlab/
ログインページ

ドメイン名でアクセスできるようにするために、パソコンのhosts ファイルにサーバの行を追加します。
※ パソコンはMacなので、/etc/hosts を更新します。

sudo vi /etc/hosts
→追加した行
  <サーバのIPアドレス>   gitlab.a.example

下記のURLにアクセスすると、ログインページが表示されました。

  • http://gitlab.a.example
ログインページ

ユーザ名root と先ほど確認したパスワードを入力するとログインに成功しました。

ログイン成功

8. GitLabのバージョンの確認

右上の?アイコンの[Help] をクリックして表示されるページでバージョンを確認すると、14.9.3-ee となっていました。

GitLab Enterprise Edition 14.9.3-ee

OSS版のCE でよかったのですが、公式サイトに推奨は有料版のEEで、ライセンス登録しななくてもCE と同じ機能が使えるとのことだったので、これでよいことにします。

9. rootユーザのパスワード変更

右上のアイコンの[Edit profile] をクリックし、左の縦長のメニューにある南京錠のアイコンをクリックして表示されるページでパスワードを変更します。

インストール直後の状態の確認

1. バンドルインストールされたライブラリの確認

cat /opt/gitlab/version-manifest.txt

大量に表示されたのでここに貼り付けませんが、ぱっと見では下記のページに掲載されている内容と一致していました。

2. 設定ファイルの確認

GitLab の設定ファイル/etc/gitlab/gitlab.rb のコメントアウトされていない行だけを抽出して確認します。(2つ目のgrepで空白行を除去)

sudo grep -v "^#" /etc/gitlab/gitlab.rb | grep -v "^$"
→ external_url 'http://gitlab.a.example'

インストール時に指定したEXTERNAL_URL=”http://gitlab.a.example” がここにセットされていました。
他は全てコメントアウトされていました。

3. サービスの状態を確認

sudo gitlab-ctl status

ちなみに、サービスの起動・停止・再起動は下記のコマンドで実行します。

sudo gitlab-ctl start
sudo gitlab-ctl stop
sudo gitlab-ctl restart

あとがき

ひとまず、インストールして正常に動作していることの確認ができました。最低限の使える状態にはなったようです。
インストール後の推奨される次のステップというのがあるので、まずはこちらを確認して必要なことがあれば対応しようと思います。

参照

OpenSSHサーバでSSH,SCP,SFTP

OpenSSHサーバを使ったSFTP について書きましたが、SSHSCP について何も書いていなかったので一応書いておきます。

環境について

サーバ側の環境

  • Ubuntu

クライアント側の環境

  • macOS Monterey

OpenSSHサーバの環境構築

OpenSSHサーバのインストール

sudo apt install openssh-server

ファイアウォール

SSHの標準ポート22/TCPを開ける

sudo ufw allow ssh

コマンドの実行後の状態を確認する

sudo ufw status verbose
→ 下記の2つが追加されている
  22/tcp (OpenSSH)           ALLOW IN    Anywhere
  22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

OpenSSHサーバの設定

設定ファイルの編集

sudo vi /etc/ssh/sshd_config

/etc/ssh/ssh_config ではなく/etc/ssh/sshd_config

設定した内容(一部抜粋)※既存の設定の変更やコメントアウトなど

AllowTcpForwarding no
X11Forwarding no
Subsystem sftp  /usr/lib/openssh/sftp-server
  • Subsystem sftp はSFTP を使えないようにしたい場合は、コメントアウトする
  • Chroot でSFTPサーバを構築する場合は、Subsystem sftp/usr/lib/openssh/sftp-server ではなくinternal-sftp を指定する→「OpenSSHサーバでSFTP」参照
  • ちなみに、Subsystem sftp/usr/lib/openssh/sftp-server でもChroot なSFTPができてしまいましたが、internal-sftp を指定するのが正しいようです

設定の有効化

OpenSSH サーバを再起動

sudo systemctl restart sshd

接続確認(SSH, SCP, SFTP)

ネットワークを経由しない、サーバ内のローカル接続による接続確認です。

ssh ubuntu@localhost
→ 接続に成功
exit

echo "testdata" > testfile.txt
mkdir temp
scp testfile.txt ubuntu@localhost:temp
ls temp
→ testfile.txt が格納されている
rm temp/testfile.txt

sftp ubuntu@localhost
put testfile.txt temp/
ls temp
→ testfile.txt が格納されている
rm temp/testfile.txt
quit

接続確認(クライアントからサーバ)

サーバは、前述のローカル接続による接続確認をした後の状態で行います。
なので、/home/ubuntu にtemp ディレクトリが作られていて、中にファイルがない状態です。

接続確認(SSH)

ssh ubuntu@<hostname またはipaddress>
→ 接続に成功
exit

接続確認(SCP)

echo "testdata" > testfile.txt
scp testfile.txt ubuntu@<hostname またはipaddress>:temp

scp ubuntu@<hostname またはipaddress>:temp/testfile.txt ./testfile1.txt
ls testfile1.txt
→ testfile1.txt が格納されている
rm testfile1.txt

接続確認(SFTP)

sftp sftpuser@<hostname またはipaddress>
put testfile.txt temp/
ls temp
→ testfile.txt が格納されている
rm temp/testfile.txt
quit

あとがき

単にOpenSSHサーバを使ってSSH、SCP、SFTP を使える状態にするのは簡単にできました。

ただ、サーバを安全に管理する上では運用面をしっかりする必要がありそうです。
例えば、開発したコンテンツのアップロードだけを行う要員には、Chroot でアクセスできる範囲を制限したSFTPしか使えないユーザを割り当てるなど。

今回ははじめにのようなことを書きたかったので、この辺にしておきます。

OpenSSHサーバでSFTP(公開鍵認証)

直前の投稿「OpenSSHサーバでSFTP」の続きです。
前回はパスワード認証だったので、今回は公開鍵認証でユーザ認証できるようにします。

環境について

※ 前回と同じ、サーバはUbuntu を使っています。

クライアントの環境構築

キーペアの生成

公開鍵認証で使うデジタル署名Ed25519のキーペアを生成

ssh-keygen -t ed25519
→ Your identification has been saved in /Users/xxx/.ssh/id_ed25519
   Your public key has been saved in /Users/xxx/.ssh/id_ed25519.pub
  • 任意のパスフレーズを設定します
  • 生成されるキーペアは、id_ed25519 が秘密鍵、id_ed25519.pub が公開鍵
  • キーペアのファイル名を指定したい場合は、-f オプションを使って指定します(今回は指定しなかったのでデフォルトの”id_ed25519″で作成されました)

公開鍵をサーバにアップロード

前回設定したSFTP(パスワード認証)を使ってアップロードします。
※ 公開鍵 id_ed25519.pub/var/sftp/sftpuser にアップロードします。

sftp sftpuser@<hostname またはipaddress>
→パスワードを入力してユーザ認証

cd sftpuser
put ~/.ssh/id_ed25519.pub
quit

OpenSSHサーバの環境構築

前回作成したユーザ「sftpuser」のユーザ認証の方式をパスワード認証から公開鍵認証に変更します。

公開鍵の設置

SSH接続できるユーザでサーバにSSH接続して、公開鍵を設置します。

su - sftpuser
mkdir ~/.ssh
chmod 700 ~/.ssh
cat /var/sftp/sftpuser/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
exit

sudo rm /var/sftp/sftpuser/id_ed25519.pub

OpenSSHサーバの設定

設定ファイルの編集

sudo vi /etc/ssh/sshd_config

設定した内容(一部抜粋)

PubkeyAuthentication yes
AllowTcpForwarding no
X11Forwarding no
Subsystem sftp  internal-sftp

Match User sftpuser
    ChrootDirectory /var/sftp
    ForceCommand internal-sftp
    PasswordAuthentication no
    AuthorizedKeysFile /home/sftpuser/.ssh/authorized_keys
  • PasswordAuthentication no により、パスワード認証ができないようにする
  • AuthorizedKeysFile で公開鍵を指定する

設定の有効化

OpenSSH サーバを再起動

sudo systemctl restart sshd

接続確認(クライアントからサーバ)

SFTP接続の確認(成功)

Mac のターミナルを使ってネットワーク経由でSFTP接続の確認

echo "test" > testfile.txt

sftp -i ~/.ssh/id_ed25519 sftpuser@<hostname またはipaddress>
→パスフレーズを入力して公開鍵認証

cd sftpuser
put testfile.txt
ls
quit

SSHとSCP接続の確認(失敗)

SSHの接続を試してみると失敗します

ssh -i ~/.ssh/id_ed25519 sftpuser@<hostname またはipaddress>
→パスフレーズを入力して公開鍵認証
→ This service allows sftp connections only.

SCPの接続を試してみると失敗します

scp -i ~/.ssh/id_ed25519 testfile.txt sftpuser@<hostname またはipaddress>:
→パスフレーズを入力して公開鍵認証
→ This service allows sftp connections only.

あとがき

パスワード認証の場合、パスワードが漏洩すると第三者がログインできてしまいますが、公開鍵認証はクライアント上に保存した暗号鍵とパスフレーズの両方が第三者の手に渡らなければ第三者によるログインが成功しないので、より安全なユーザ認証の方式といえると思います。

設定がパスワード認証に比べると面倒かもしれませんが、なるべく公開鍵認証を使うようにした方がよいのでしょう。

OpenSSHサーバでSFTP

クライアント上のファイルをサーバにSFTPでアップロードできるようにします。
今回解説する手順は、SFTP専用のユーザを作成して、Chrootにより限定された場所にファイルをアップロードできるようにする手順となります。

環境について

サーバ側の環境

  • Ubuntu
  • OpenSSHサーバ ※インストール済み

クライアント側の環境

  • macOS Monterey

OpenSSHサーバの環境構築

SFTP専用ユーザーの作成

sudo adduser sftpuser

ユーザ認証はパスワード認証を使うので、任意のパスワードを設定します。
※ 公開鍵認証も可能ですが、SFTP中心の解説にしたいので省略します。

SFTP専用グループの作成

sudo groupadd sftponly

ユーザをグループに追加 ※セカンダリグループ

sudo adduser sftpuser sftponly

SFTP専用ディレクトリの作成

SFTP専用ディレクトリの作成 ※Chrootディレクトリ

sudo mkdir /var/sftp
sudo chown root:root /var/sftp

SFTP専用ユーザのディレクトリの作成 ※ここにアップロードする

sudo mkdir /var/sftp/sftpuser
sudo chown sftpuser:sftponly /var/sftp/sftpuser
sudo chmod 755 /var/sftp/sftpuser

OpenSSHサーバの設定

設定ファイルの編集

sudo vi /etc/ssh/sshd_config

/etc/ssh/ssh_config というファイルもあるけれども、設定するのは/etc/ssh/sshd_config

設定した内容(一部抜粋)※既存の設定の変更やコメントアウトなど

AllowTcpForwarding no
X11Forwarding no
Subsystem sftp  internal-sftp

設定した内容 ※末尾に追記

Match User sftpuser
    ChrootDirectory /var/sftp
    ForceCommand internal-sftp
    PasswordAuthentication yes
  • ChrootDirectory は、SFTP接続した際のルートディレクトリを/var/sftp に設定する
  • ForceCommand internal-sftp により、SFTP の利用に限定する(SSHとSCPが使えない)
  • ChrootDirectoryForceCommand internal-sftp の両方を設定することでChroot とSFTP 限定が有効になるようです

設定の有効化

OpenSSH サーバを再起動

sudo systemctl restart sshd

接続確認

サーバのローカル環境上でのSFTP接続の確認

sftp sftpuser@localhost

接続確認(クライアントからサーバ)

SFTP接続の確認(成功)

Mac のターミナルを使ってネットワーク経由でSFTP接続の確認

echo "test" > testfile.txt

sftp sftpuser@<hostname またはipaddress>
→パスワードを入力してユーザ認証

pwd
→ Remote working directory: /
put testfile.txt
→ remote open("/testfile.txt"): Permission denied
cd sftpuser
put testfile.txt
ls
quit
  • 接続した時点のカレントディレクトリは/var/sftp がルートディレクトリとなっていて、ディレクトリの所有者とグループがroot なのでput でファイルをアップロードしようとすると失敗します。
  • cd でカレントディレクトリを/var/sftp/sftpuser に変えてからput するとアップロードが成功します。

SSHとSCP接続の確認(失敗)

SSHの接続を試してみると失敗します

ssh sftpuser@<hostname またはipaddress>
→ This service allows sftp connections only.

SCPの接続を試してみると失敗します

scp testfile.txt sftpuser@<hostname またはipaddress>:
→ This service allows sftp connections only.

あとがき

ChrootDirectory/var/sftp としましたが、ユーザのホームディレクトリ/home/sftpuser を指定してもよさそうです。

SFTPでファイルのアップロード・ダウンロードをするのが専用のユーザなので、SSH接続できるユーザがそのファイルのコピー等をするのにどこが運用上望ましいかで判断する感じでしょうか。

%d人のブロガーが「いいね」をつけました。