タグ: Ubuntu Page 6 of 15

Growi v7でページ編集時に空白になる問題に対処(Apache リバースプロキシのWebSocket設定)

事象の内容

  • Growiのバージョンをv6.3.5→v7.0.11にアップグレード後、既存のページを編集しようとすると編集エリアが空白になってしまう。
  • 新規ページを作成する際に、テンプレートが適用されない。

先のエントリーで述べたようにWikiとしては致命的な弱点だったため、やむなくv6.3.5に戻したという経緯があります。

ですが、回避策が見つかりましたのでメモとして残します。

事象が発生した環境

  • Ubuntu 22.04
  • Apache 2.4
  • Growi v7.0.11をDockerではなくオンプレ環境で利用。
  • Apacheによるリバースプロキシを設定

同一事象をネットで確認。

How to reproduce? (再現手順)

2台のHostPCでそれぞれGrowiを立ち上げています。A環境・B環境と呼称します。

「データ移行」機能を用いて、A環境からB環境にデータをインポートする
B環境のGrowiに他のPCからアクセスする
記事の編集画面を表示する

What happens? (症状)

記事の編集画面が白紙になっており、そのまま保存しても記事の内容が失われる(添付画面参照)

と、事象が一致。

事象の原因

上記issueのツリーに

私の環境でも編集画面が空白になる現象が観測されました。

私は https-portal を使ってデプロイしているのですが、 growi-docker-compose/examples/https-portal にある WEBSOCKET: 'true' の環境変数を設定し損ねていたのが原因でした。
私の環境では、これを設定すると通常通り編集を行えることを確認しております。逆に、コメントアウトすると空白に戻ります。

とあります。

これを原因と断定し、対処に臨みます。

対応方法のさっくりとした手順

  1. 現状のgrowiのリバースプロキシの設定を確認。
  2. 設定ファイルのバックアップ。
  3. 設定ファイルを修正。
  4. 修正を反映。
  5. 事象の解決確認。

参考にしたURL

How to Reverse Proxy Websockets with Apache 2.4

現段階でのリバースプロキシの設定を確認します。

  • Apacheのバーチャルファイルを確認
cat /etc/apache2/sites-available/growi.conf

自分の環境に合わせます。

  • 内容の一部抜粋
    # socket.io の path を rewrite する
    RewriteEngine On
    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
    RewriteRule /(.*) ws://localhost:3000/ [P,L]

    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/

設定そのものはgithubのgrowi公式ドキュメントに沿ったものでしたが、これが引っかかっていたようです。

設定ファイルのバックアップを取ります。

  • バックアップ
sudo cp -pi /etc/apache2/sites-available/growi.conf /path/to/backup/directory/growi.conf.$(date +%Y%m%d)

ファイル名は自分の環境に合わせます。適宜、任意のバックアップディレクトリを指定します。

  • バックアップ確認
diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf

差分が無いこと(エラーがないこと)でバックアップを確認します。

ファイルを修正します。

上記、バックアップを取ったファイルを教義・信仰に沿ったエディタで編集します。(要管理者権限)

  • 削除する内容
    # socket.io の path を rewrite する
    RewriteEngine On
    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
    RewriteRule /(.*) ws://localhost:3000/ [P,L]
  • 削除した箇所に追記する内容
     # WebSocketのための設定
     RewriteEngine On
     RewriteCond %{HTTP:Upgrade} =websocket [NC]
     RewriteCond %{HTTP:Connection} upgrade [NC]
     RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

編集後、差分を取ります。

  • 差分確認
diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf
  • 差分結果
-    # socket.io の path を rewrite する
-    RewriteEngine On
-    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
-    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
-    RewriteRule /(.*) ws://localhost:3000/ [P,L]
+     # WebSocketのための設定
+     RewriteEngine On
+     RewriteCond %{HTTP:Upgrade} =websocket [NC]
+     RewriteCond %{HTTP:Connection} upgrade [NC]
+     RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

設定を反映します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動前確認
systemctl status apache2.service

active (running)を確認します。

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動後確認
systemctl status apache2.service

active (running)を確認します。

事象の解決を確認します。

上記、設定を行ったGrowiサイトにアクセスします。

編集後、左ペイン(エディタ部分)がそのまま残っていれば対処完了です。

apacheで特定のユーザーエージェントからのアクセスを拒否。

概要

自分のサーバのアクセスログを見たら

"GET /picture.php?/6797/category/73 HTTP/1.1" 200 14394 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"

と、クローラーが大量にアクセスしてきました。robots.txtも意に介さない悪名高いbotのようなので、このアクセスを、サーバで拒否します。

環境

  • Ubuntu 20.04
  • Apache 2.4 (aptでインストールしたため、ディレクトリは/etc/apache2配下にあります。

また、バーチャルサイトによる複数のサイトを運用しているので、そのうちの1つだけを弾きます。

さっくりとした手順

  1. Apacheのバーチャルサイトの設定ファイルのバックアップを取ります。
  2. 設定ファイルを追記します。
  3. 設定を反映します。
  4. 拒否されていることを確認します。

設定ファイルのバックアップ

  • ディレクトリ移動
cd /etc/apache2/sites-available && pwd
  • ファイルバックアップ
sudo cp -pi hoge.conf /path/to/backup/directory/hoge.conf.$(date +%Y%m%d)

設定を行いたい自分の設定ファイルを、任意のバックアップディレクトリにバックアップします。

  • バックアップ確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf

差分が無ければ(エラーがなければ)バックアップは成功です。

設定ファイル追記

上述した設定ファイルを教義・進行に則ったエディタで編集します。(要管理者権限)

  • 追記例
    DocumentRoot /var/www/html/hoge
    <Directory /var/www/html/hoge>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
     ## GoogleBOTを拒否(正常bot不正bot両方拒否)
     SetEnvIfNoCase User-Agent "Googlebot" bot
     ## Facebookのクローラーを拒否
     SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" fb_bot
     <RequireAll>
      Require all granted
      Require not env bot
      Require not env fb_bot
     </RequireAll>

/var/www/html/hogeは自分の環境に合わせます。

※ついでにGoogleBOTも拒否します。

  • 差分確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf
  • 差分例
-        Require all granted
+     ## GoogleBOTを拒否(正常bot不正bot両方拒否)
+     SetEnvIfNoCase User-Agent "Googlebot" bot
+     ## Facebookのクローラーを拒否
+     SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" fb_bot
+     <RequireAll>
+      Require all granted
+      Require not env bot
+      Require not env fb_bot
+     </RequireAll>

設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動確認
systemctl status apache2.service

active(running)を確認します。

設定反映確認

設定を行ったアクセスログを開きます。

403 3772 "-" "facebookexternalhit/1.1 

のように、ステータスコードが「403」になっていれば、アクセス拒否されています。

UbuntuサーバのSwap処理頻度を変更。

Ubuntuサーバを運用中、実メモリに余裕があるにもかかわらずスワップアウトが出ている事象を確認。

これを変更してみます。

環境

  • Ubuntu 20.04
  • メモリ4GB
  • スワップ6GB

事象と設定変更

現状確認

  • メモリ使用量の確認
free -h
  • 自分の環境の確認
              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       1.8Gi       694Mi       176Mi       1.3Gi       1.6Gi
Swap:         6.0Gi       6.0Mi       6.0Gi
  • swappiness確認
cat /proc/sys/vm/swappiness

60を確認しました。

設定変更

sudo cp -pi /etc/sysctl.conf /path/to/backup/directory/systtl.conf.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • バックアップ確認
diff -u /path/to/backup/directory/systtl.conf.$(date +%Y%m%d) /etc/sysctl.conf

差分がなければ(エラーなく実行できれば)バックアップ成功です。

  • sedによるファイル追記
sudo sed -i '$ a\vm.swappiness = 10' /etc/sysctl.conf

上記の参考サイトを元に、swappinessを10に指定します

  • 設定変更確認
diff -u /path/to/backup/directory/systtl.conf.$(date +%Y%m%d) /etc/sysctl.conf
  • 差分
+vm.swappiness = 10
  • 設定反映
sudo sysctl -p

vm.swappiness = 10と結果が返ってくることを確認します。

設定反映確認

cat /proc/sys/vm/swappiness

10に変更されていることを確認します。

まずはこの値で様子を見てみようと思います。

ufwのエラーに対処(ufwでipv6を無効化)

Linuxサーバのセキュリティを保つため、ufwの遮断スクリプトを用いています

ところが、「UFWが有効になっていない」というメッセージが出始めたため、その対処を行いました。

事象確認

  • ufw のステータス
sudo ufw status
  • 結果
ERROR: problem running ip6tables

対処

参考URL:https://www.reddit.com/r/linux4noobs/comments/nlb4ul/ufw_status_keeps_returning_problem_running/?rdt=58511

ファイルのバックアップを行います。

  • ufwファイルのバックアップ
sudo cp -pi /etc/default/ufw /path/to/backup/directory/ufw.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • バックアップ確認
diff -u /etc/default/ufw /path/to/backup/directory/ufw.$(date +%Y%m%d)

差分が無いことでバックアップができていることを確認します。

ファイルの書き換えを行います。

  • sedによるファイル書き換え
sudo sed -i 's/IPV6=yes/IPV6=no/' /etc/default/ufw
  • 書き換え確認
diff -u /path/to/backup/directory/ufw.$(date +%Y%m%d) /etc/default/ufw

差分

-IPV6=yes
+IPV6=no

設定を反映します。

  • ufwリロード
sudo ufw reload
sudo ufw status
  • 結果
状態: アクティブ

となっていればOKです。

考えられる原因

パッケージ全体のアップデートなどを行った関係で、IPv6の設定が強制になったためと思われます。

NextcloudのExternal StorageサービスでのArray to string conversionエラーに対処。

エラー概要

Nextcloud 28.x以降にバージョンアップしてから、ログで以下が大量に出力され続けていました。

Array to string conversion at /var/www/html/nextcloud/lib/private/Files/Cache/Scanner.php#224

こちらの対処を行います。

エラーが出る要件

  1. Nextcloud 28.x以降を利用している。
  2. External Storageプラグインを利用している。
  3. このプラグインで、S3(乃至はS3互換のオンラインストレージ)をマウントしている。
  4. マウントしたストレージにファイルやフォルダを保存した。

詳細:Nextcloud Hub 8, copying files to an External Storage configured as primary storage isn't reliable

環境

  • Ubuntu 20.04
  • Nextcloud 29.0.0
  • PHP 8.1
  • Apache 2.4
  • オンラインストレージサービスとしてwasabiを利用

解決策

上記issueに

Pretty sure this would be fixed by #43794. At least in my limited testing using the merge request as a patch: https://patch-diff.githubusercontent.com/raw/nextcloud/server/pull/43794.diff

とあったので、この通りに実施します。

さっくりとした手順

  1. rootに昇格します。
  2. パッチファイルを入手します。
  3. ファイルを適用します。
  4. Apacheを再起動します。

root昇格

sudo su -

Nextcloudはwww-dataユーザーのみアクセス可能と、厳しめのアクセス権が設定されているので、ここで昇格させます。

ディレクトリ移動

  • Nextcloudのルートディレクトリに移動
cd /var/www/html/nextcloud && pwd

自分の環境に合わせます。

cd lib/private/Files/Cache

ファイルバックアップ

  • Scanner.phpファイルのバックアップ
cp -pi Scanner.php /path/to/backup/directory/Scanner.php.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • バックアップ確認
diff -u Scanner.php /path/to/backup/directory/Scanner.php.$(date +%Y%m%d)

差分がなければバックアップは成功です。

パッチ適用

  • wgetでパッチ入手
sudo -u www-data https://patch-diff.githubusercontent.com/raw/nextcloud/server/pull/43794.diff
  • パッチ適用
sudo -u www-data patch < 43794.diff 

patching file Scanner.phpと返ってくればOKです。

パッチ適用確認

  • 差分確認
diff -u /path/to/backup/directory/Scanner.php.$(date +%Y%m%d) Scanner.php
  • 差分結果
                                                }

                                                // Only update metadata that has changed
-                                               $newData = array_diff_assoc($data, $cacheData->getData());
-
+                                               // i.e. get all the values in $data that are not present in the cache already
+                                               // NOTE: we serialize then unserialize here because array_diff_assoc() doesn't 
+                                               // support multidimensional arrays on its own (and otherwise internally casts any 
+                                               // embedded array elements to attempt to compare them - not only generating warnings 
+                                               // like "Array to string conversion" but also, as a resut, overlooking real differences)
+                                               $newData = array_diff_assoc(
+                                                       array_map('serialize', $data), 
+                                                       array_map('serialize', $cacheData->getData())
+                                                       );
+                                               $newData = array_map('unserialize', $newData);
+                                        
                                                // make it known to the caller that etag has been changed and needs propagation
                                                if (isset($newData['etag'])) {
                                                        $data['etag_changed'] = true;
  • Apache再起動
systemctl restart apache2.service

既にrootに昇格しているので、sudoは不要のはずです。

  • パッチファイルを削除
rm 43794.diff 

エラー解消確認

  1. ブラウザでNextcloudサイトに管理者権限でログインします。
  2. 管理メニュー→ログへと進み、適用時刻以降に冒頭のログが出力されていないことを確認します。

Ubuntu 22.04にmkcertをインストール。

これを使わずとも、Ubuntu 22.04にはapt(aptitude)からインストール可能でした。

概要

  • ローカルDNSで証明書を作りたい
  • 或いはローカルホスト(127.0.0.1)をhttps化したい

場合に役立つコマンド、mkcertをインストールします。

インストール方法

aptitude (apt)によるインストール

sudo aptitude install mkcert

ローカルルート証明書を作成

  • ルート証明書の作成
mkcert -install
  • ローカルのルート証明書作成確認
ls -l ~/.local/share/mkcert/
  • rootCA-key.pem → 秘密鍵
  • rootCA.pem → ルート証明書

ホスト名に追記・修正

ファイル /etc/hosts をルート顕現で、以下のように修正します。

127.0.0.1  agnes-luce

※ Ubuntu系はホスト名に指定したIPがなぜか127.0.1.1になっています。

証明書作成

  • ディレクトリ移動
cd /hoge && pwd

任意のディレクトリに移動します。

  • 証明書作成
mkcert -key-file ドメイン名.key.$(date +%Y%m) -cert-file ドメイン名.crt.$(date +%Y%m) ドメイン名
  • 作成例
mkcert -key-file agnes-luce.key.$(date +%Y%m) -cert-file agnes-luce.crt.$(date +%Y%m) agnes-luce
Created a new certificate valid for the following names 📜
 - "agnes-luce"

The certificate is at "agnes-luce.crt.202404" and the key at "agnes-luce.key.202404" ✅

It will expire on 14 July 2026 🗓

証明書の整合性を確認

  • 証明書から公開鍵のハッシュ値を取り出す
openssl x509 -pubkey -in 証明書ファイル -noout | openssl md5
  • 秘密鍵から公開鍵のハッシュ値を取り出す
openssl pkey -pubout -in 秘密鍵ファイル | openssl md5

それぞれのハッシュ値が同じであることを確認します。

こうしてできた一式は2年半有効です。

書き直し:Ubuntu 22.04系にRedmine5.1をインストール。(手順書の基準)

こちらの記事を、現在の自分の手順書の基準に直しました。

心がけている基準

  • 1区切りで1コマンド。
    • コピペする際に連続で実行する際のエラーを防ぎます。
    • 特に、SQLを操作する際は1行ずつ、確実に行いたいのでこれで書き直しです。
  • 可能な限りテキストエディタは用いない。
    • 設定ファイルの書き換えや追記はsedやteeを使います。
    • 使用する必要がある場合はその旨を追記します。

こうしてできたのがこちら。

前提

  • Ubuntuサーバの初期設定が終わった直後の状態を想定します。
  • DNSでドメインの名前が解決できることを前提としています
  • 環境は以下の通りです。
  • Apache系
  • MySQL
  • Ruby 3.0
  • また、パッケージ管理としてaptitudeを用いています。aptが好みの方はこちらに読み替えてください。

特記事項

  • 本手順ではRedmine 5.1をインストールします。
  • よほどのことがない限り、Ubuntu22.04にインストールするのはこのバージョンになります。
  • 本記事のredmineの格納ディレクトリは/home/www-data/redmineです。一般的なディレクトリ(/var/lib/redmine)と異なることを最初に注記します。
  • ほぼコピペだけで済むような構成にしていますが、一部、テキストエディタを使用する箇所があります。
  • また、自身の環境に合わせたりパスワードを設定する項目がありますのでそこは注意してください。

手順

Apacheのレポジトリを追加します。

sudo add-apt-repository ppa:ondrej/apache2

必要なパッケージをインストールします。

  • パッケージ全体のアップデート
sudo aptitude update
  • 必要なパッケージのインストール
sudo aptitude install build-essential zlib1g-dev libssl-dev libreadline-dev libyaml-dev libcurl4-openssl-dev libffi-dev mysql-server mysql-client apache2 apache2-dev libapr1-dev libaprutil1-dev imagemagick libmagick++-dev fonts-takao-pgothic subversion git ruby libruby ruby-dev libmysqlclient-dev

apacheの追加モジュールをインストールします。

sudo aptitude install libapache2-mod-passenger

apacheのバージョンを確認します。

apache2ctl -v

Apache/2.4.59以降であることを確認します。2.4.58には、http/2プロトコルへの脆弱性があるので、左記のバージョンであることを確認します。

rubyのパッケージ管理(gem)を用いて必要なライブラリをインストールします。

sudo gem install bundler racc mysql2

「3 gems installed」が表示されればインストール成功です。

必要に応じてmysqlの初期設定を行います。

mysql_secure_installationによる初期設定を行います。

うまくいかない場合は以下を参照してください。

https://barrel.reisalin.com/books/bbf94/page/mysql-secure-installation

mysqlでDBとユーザーを設定します。

sudo mysql -u root -p

上記で設定した「mysqlのrootパスワード」を入力し、mysqlにログインします

CREATE DATABASE redmine character set utf8mb4;

DB "redmine" を作成します

CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'password';

ユーザ "redmine"を作成し、パスワードを設定します。
この'password'は任意のパスワードに変更してください

GRANT ALL ON redmine.* TO 'redmine'@'localhost';
flush privileges;
exit

設定したDBでログインできることを確認します。

mysql -u redmine -p
SHOW DATABASES;
exit
  • 配置ディレクトリ作成
sudo mkdir -p /home/www-data/redmine

自分の環境に合わせます。

  • 所有者変更
sudo chown -R www-data:www-data /home/www-data
  • Redmine 5.1を入手
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.1-stable /home/www-data/redmine

Redmineのコンフィグを設定します。

  • サンプルファイルをコピーしてコンフィグを編集
sudo cp -pi /home/www-data/redmine/config/database.yml.example /home/www-data/redmine/config/database.yml

/home/www-data/redmine/config/database.yml

このファイルを教義・信仰に従ったエディタで編集してください。

database.yml 編集内容(要:テキストエディタ)

production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  # rootからredmineに変更します
  password: "redmine用のパスワード"
  encoding: utf8mb4
# 本番環境(production)のみ設定を行います

Redmineのマイグレーションを行います。

  • Redmineのルートディレクトリに移動
cd /home/www-data/redmine/ && pwd

/home/www-data/redmine/ (Redmineを配置したディレクトリ)であることを確認します

  • bundle install
sudo -u www-data bundle install --without development test --path vendor/bundle
  • シークレットトークンの発行
sudo -u www-data bundle exec rake generate_secret_token
  • DBマイグレーション
sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate
  • 日本語化
sudo -u www-data RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data

Apacheの設定ファイルを作成します。

【】を自分の作成したRedmineのサーバ名/ドメイン名に変更します。

cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/redmine.conf
<VirtualHost *:80>
    ServerName 【hoge.example.com】
    # ServerNameは自身が設定したredmineに読み替えてください。
    DocumentRoot /home/www-data/redmine/public
    <Directory /home/www-data/redmine/public>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
__EOF__

設定を反映させます。

  • ファイル作成確認
ls -l /etc/apache2/sites-available/redmine.conf
  • 設定ファイル有効化
sudo a2ensite redmine.conf
  • 初期サイト設定を無効化
sudo a2dissite 000-default.conf
sudo a2dissite default-ssl.conf
  • コンフィグファイル整合性確認
sudo apache2ctl configtest

Syntax OK を確認します

  • 設定反映前のapacheステータス確認
systemctl status apache2.service

active(running)を確認します

  • apache再起動
sudo systemctl restart apache2.service
  • 設定反映後のapacheステータス確認
systemctl status apache2.service

active(running)を確認します

Webページの表示を確認します。

http://設定したRedmineドメイン

でRedmineのトップページが表示されれば成功です。

直ちにadmin/adminでログインし、強固なパスワードを設定し直します。

Ubuntu 20.04 / 22.04で稼働しているApache HTTP Server 2.4の脆弱性対応。

2024年4月に発表された脆弱性への対処を行います。

脆弱性内容

  • Apache HTTP Serverのコア機能におけるHTTPレスポンス分割の問題(CVE-2023-38709)
  • 複数のモジュールにおけるHTTPレスポンス分割の問題(CVE-2024-24795)
  • HTTP/2 CONTINUATIONフレームの検証不備に起因したメモリ枯渇の問題(CVE-2024-27316)

https://jvn.jp/vu/JVNVU99032532

環境

  • Ubuntu 20.04 および Ubuntu 22.04
  • Apache 2.4系を利用

Apacheのレポジトリを追加します。

sudo add-apt-repository ppa:ondrej/apache2

Apacheのバージョンアップを行います。

  • パッケージ全体のアップデート
sudo aptitude update
  • パッケージのアップグレード
sudo aptitude upgrade

このリストの中にapache2とapache2関連パッケージが更新される(2024/04/10現在)ため、それぞれアップグレードを行います。

バージョンアップを確認します。

apache2ctl -v

Apache/2.4.59以降であることを確認します。2.4.58には、http/2プロトコルへの脆弱性があるので、左記のバージョンであることを確認します。

対応を行った日付

2024/04/10

ソースコードからインストールしたOpenSSHを9.6.1p→9.7.1にアップデート(Ubuntu 20.04)

この記事の続きです。

概要

ソースコードからインストールしたOpenSSH9.6p1を、更にOpenSSH9.7p1にバージョンアップします。

前提

Ubuntu 20.04での動作確認です。

上記手順を用いて、ソースコードからOpenSSHをインストールしています。

さっくりとした手順

  1. 作業用ディレクトリに移動します。
  2. ソースをダウンロードします。
  3. OpenSSHをソースからビルドします。
  4. バージョンアップを確認します。

バージョンアップ前の確認

ssh -V
OpenSSH_9.6p1, OpenSSL 3.2.1 30 Jan 2024

作業用ディレクトリ移動

cd /hoge && pwd

任意のディレクトリを指定します。

ソースのダウンロードと展開

  • ソース取得
wget -c http://mirror.exonetric.net/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz

2024/04/04現在の最新版を指定しています。

  • ソース展開
tar -xzf openssh-9.7p1.tar.gz
  • ディレクトリ移動
cd openssh-9.7p1

コンフィグ

  • OpenSSLの位置を確認
which openssl
  • 結果確認
/usr/local/ssl/bin/openssl

筆者の環境です。

  • コンフィグ
./configure --with-kerberos5 --with-md5-passwords --with-pam --with-selinux --with-privsep-path=/var/lib/sshd/ --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/ssl

--with-ssl-dir=/usr/local/sslは、opensslのヘッドディレクトリを指定します。

  • make
make
  • インストール
sudo make install

バージョンアップ確認

※別にターミナルを開いて確認します。

  • バージョン確認
ssh -V
OpenSSH_9.7p1, OpenSSL 3.2.1 30 Jan 2024

バージョンアップされていることを確認します。

  • SSHサービス再起動
sudo systemctl restart ssh.service
  • サービス再起動確認
sudo systemctl status ssh.service

active(running)を確認します

必要に応じてサーバの再起動を行ってください。

ソースコードからインストールしたOpenSSL 3.1.1を3.2.1にアップグレード。

こちらの記事から、OpenSSLのバージョンが上がっていたので対応します。

概要

脆弱性やバグフィックス版のOpenSSL3.2.1にアップグレードします。

環境、前提

  • Ubuntu 20.04
  • ソースコードからOpenSSL3.1.1をインストール・設定済み

さっくりとした手順

  1. rootに昇格します。
  2. 作業用ディレクトリにソースコードを取得・展開します。
  3. ソースからインストール(アップグレード)を行います。
  4. バージョンアップを確認します。

作業前にバージョン確認

openssl version -a

OpenSSL 3.1.1 30 May 2023 (Library: OpenSSL 3.1.1 30 May 2023)
built on: Thu Jun 22 05:19:59 2023 UTC
platform: linux-x86_64
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/ssl/lib64/engines-3"
MODULESDIR: "/usr/local/ssl/lib64/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0xfffa3203578bffff:0x7a9

rootに昇格

この手の作業はrootで行った方が手間が少ないです。その分、注意を払いましょう。

sudo su -

作業用ディレクトリに移動

cd /hoge && pwd

任意のディレクトリを指定します。

ソースコードの取得

  • git clone
git clone https://github.com/openssl/openssl -b openssl-3.2.1

2024/04/02時点での最新安定版を指定します

  • ソースコードのディレクトリに移動
cd openssl

ソースからアップグレード(インストール)

  • コンフィグ設定
./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlib
  • make
make

makeは時間がかかります。状況を時折確認しながら待ちましょう。

  • 整合性確認
make test

同様にmake testも時間がかかります。

  • アップグレード(インストール)
make install

アップグレード後のバージョン確認

  • SSLのバージョンアップ確認
openssl version -a

OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 Jan 2024)
built on: Tue Apr 2 01:28:56 2024 UTC
platform: linux-x86_64
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/ssl/lib64/engines-3"
MODULESDIR: "/usr/local/ssl/lib64/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0xfffa3203578bffff:0x7a9

バージョンが上がっていることを確認します。

必要に応じてサーバの再起動を行い、作業完了です。

Page 6 of 15

Powered by WordPress & Theme by Anders Norén