カテゴリー
OS 社内SE

Ubuntu www-dataにSSHでログインする方法

Ubuntu serverではwww-dataというユーザがいて、WEB系のプログラムを動作させるときのデフォルトユーザとなっている。

このwww-dataにSSHでログインしようとしたら手間取ったため、以下に方法を示す。

# rootで作業
sudo su -

# www-dataをログインユーザにする。
mkdir -p /home/www-data
chown www-data:www-data /home/www-data
chmod 755 /home/www-data
usermod -s /bin/bash www-data
passwd www-data
# 適当なパスワードを指定


su - www-data

# sshの認証鍵を作成
cd .ssh
ssh-keygen -t rsa
chmod 600 ./*
chmod 744 ~/.ssh
# sshの設定に合わせて・・
mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

exit

# sshの設定を変更(必要であれば)
vi /etc/ssh/sshd_config
---
# AllowUsersを設定してなければ不要
AllowUsers www-data
---

これでwww-dataのid_rsaを使ってSSHでログインできるようになる。ホームディレクトリの権限が755じゃないとSSHで”Permission denied (publickey)”となりはじかれるので注意。(ここがわからず時間がかかってしまった。。)

カテゴリー
OS 社内SE

さくらVPS 512MBにCode-serverを入れてみた

ここ数年、個人の開発環境はVS CodeでRemote Developmentを使って開発を行っている。これを最近話題のCode-serverでクラウド化すれば、PCを変えるたびに、ローカルにVS Codeをインストールする手間がなくなる。

ただ、開発環境はさくらインターネットのVPSの一番下の512MBプランなのでcode-serverを入れて重くなるのも嫌だな、となかなか手を付けずにいたが、今回試してみた。

OSや入っている主要プログラムは以下である。

Ubuntu 20.04 / Nginx / OpenLiteSpeed / Postfix / MariaDB / PostgreSQL / SSH / Code server (今回追加)

WEB系はNginxで受けて、裏で動いているOLSやCode-serverにproxyしている。

結論から言うと、この環境でもcode-serverはPHP程度の開発では問題ないレベルで動作している。「ローカルより若干遅いかな」、とか、「見た目が少し違うのでやりにくいな」と最初は感じたが、しばらくすると慣れて全く問題なくなった。

メモリはかなりカツカツで、コンパイルが必要な開発は無理そう。

セキュリティはクライアント認証をNginxに設定し、そこからProxyでCode-serverに繋いでいる。Code-server単体ではpassword設定しかできず若干不安があった。

同じくセキュリティ絡みで言えば、code-serverの起動オプションに[–disable-telemetry]を付けて起動している。これを付けないと、code-serverの開発元に諸処の情報が送付される。code-serverのインストール解説サイトで言及されていることがないため、たいした情報が送られているわけでもないかもしれないが念の為。

ちなみに、Code-serverのインストールに際し、HTTPのフロントエンドもApacheからNginxに変更した。理由はどうしても、ApacheのReverseProxyでCode ServerのWebsocketを通せず、やむなくNginxへの変更となった。軽い軽い言われているNginxだが、私の開発環境でProxyオンリーのフロントエンド利用ではApacheより遅く感じた。あくまで体感だが、1コアで最小限のセッティングにした場合、Apacheに分がありそう。

Apache Proxyで通らなかったCode ServerのWebsocketは「ProxyWebsocketFallbackToProxyHttp」(Apache 2.4.47)や、「ProxyWebsocketIdleTimeout」(Apache 2.5)を使えば動いた気がしたが、 Ubuntu 20.04のApacheのバージョンが2.4.41でそこまで試す気もなくあきらめた。

今回個人の開発環境を変更したが、会社の開発環境もCode server化したくなった。ただ、FreeBSD環境があったり、クローズドな社内ネットワーク内にサーバがあったりするので、保留。

カテゴリー
OS 社内SE

OpenLiteSpeedで実行ユーザを変更する

ApacheからOpenLiteSpeedへのサーバ変更で困ったことの一つが、OpenLiteSpeedの実行ユーザを変更することがうまくいかないことであった。OpenLiteSpeedのユーザとグループはApacheと同じもので動かしたい。

設定ファイル”/usr/local/lsws/conf/httpd_config.conf”を見ると、上のほうにuser/groupの設定がある。単純にこの設定を変えてOpenLiteSpeedを再起動すると、一見、正常に動いているように見えるのだが、Admin consoleからServer logやライブフィードが見られないなどPHPでファイルアクセスした際のユーザがらみと思われる異常が散見された。

解決方法は上記のファイルでユーザ、グループを変更後、以下のコマンドでOpenLiteSpeedを再インストールすることであった。

apt -y install --reinstall openlitespeed
# 念のため(不要かも)
rm -rf /tmp/lshttpd
systemctl restart lshttpd

正直、なぜ必要なのかはわからないが、これをやらないとOpenLiteSpeed経由で作成するファイルのユーザ/グループが設定ファイルのユーザ/グループにならない。

当該サーバはubuntuを使用しているため、aptでの再インストールとなっている。試していないが、Debian系特有の現象で、CentosなどのRedhat系ならこういった作業は不要なのかもしれない。

カテゴリー
OS 社内SE

OpenLiteSpeedでphp.ini Overrideが効かない

ApacheからOpenLiteSpeedにサーバを変更したのだがいくつか困ったことがあった。その一つが、OpenLiteSpeedでは”.user.ini”が効かなく、virtualhost毎にPHPの設定を微妙に変更できなくなってしまったことだ。

Admin console画面から設定を見ていると、virtualhostの[general](一般)タブの下に「php.ini Override」という設定があり、PHPの設定の一部上書きが出来ると書いているではないか。これは幸いと設定、console画面から「穏やかな再起動」をしてみたが動かない。

何度も設定をやり直した挙句、弱って直接confファイルを修正して、systemctl restart lshttpd とコマンドラインから再起動したところ、難なく動作した。

その後は、Admin consoleから設定、再起動しても問題なく設定が反映されるようになった。

理由は不明。単に何か間違えていた可能性もあるが、コマンドラインから修正と再起動を行うと動くこともあるという参考までに。

ちなみに行った設定は以下。

phpIniOverride  {
  php_value default_charset "SJIS"
  php_value mbstring.language "neutral"
  php_value mbstring.internal_encoding "SJIS"
  php_value date.timezone "Asia/Tokyo"
  php_value error_reporting E_ERROR
}

1990年代にWindowsで動かしていたコードやDBを引き継ぎ続けているため、こんな設定になっている・・・。

カテゴリー
OS 社内SE

OpenLiteSpeedでのクライアント認証

最近一部のhttpサーバをApacheからOpenLiteSpeedに変更した。ただ、問題があり、Apacheにはあるクライアント認証の機能がOpenLiteSpeedにはない。

さんざん迷った挙句、Apacheでreverse proxyを使用し、そこでクライアント認証することにした。「全部Apacheで良いじゃないか」という感じもするが、どうもApache+mpm_event+php-fmpの構成では、まれにプチフリするのが気になってしょうがない。設定が悪い気がするが、再現性がなく調査もできない。

案ずるより産むがやすし、動かしてみたら、とても軽快になった。reverse proxy分重くなるかと思ったが、杞憂であった。

以下、OpenLiteSpeedのadmin consoleをクライアント認証に設定する例。

前提

クライアント証明書は以下
 ・CA証明書:/opt/myCA/cacert.pem
 ・証明書失効リスト:/opt/myCA/crl.pem
Admin ConsoleはSSLなしで動作させ、localhost(127.0.0.1)以外は接続させない。(Admin ConsoleをSSLありのデフォルトの状態で動作させたい場合は、Apache設定のコメントを参照のほど。reverse proxyでSSLのエラーを無視させればちゃんとつないでくれる。)
以下はOpenLiteSpeedのAdmin configの設定。設定後、restart。

vi /usr/local/lsws/admin/conf/admin_config.conf
---
enableCoreDump            1
sessionTimeout            3600

errorlog $SERVER_ROOT/admin/logs/error.log {
  useServer               0
  logLevel                INFO
  rollingSize             10M
}

accesslog $SERVER_ROOT/admin/logs/access.log {
  useServer               0
  rollingSize             10M
  keepDays                90
}
# 以下のセクションを追加
accessControl  {
  allow                   127.0.0.1
}
# 以下のセクションを変更
listener adminListener {
  # addressとsecureの2行を変更
  address                 127.0.0.1:7080
  secure                  0
  #keyFile                 $SERVER_ROOT/admin/conf/webadmin.key
  #certFile                $SERVER_ROOT/admin/conf/webadmin.crt
  #clientVerify            0
}
---
systemctl restart lsws

Apach設定

Apacheでhttps://yourdomain.net:8000/にアクセスするとOpenLiteSpeedの管理コンソール(http://127.0.0.1:7080/)にアクセスする設定。ブラウザにクライアント認証の証明書が入っていないとはじかれる。SSLはLetsencryptで取得。
mod_proxy mod_proxy_httpはモジュールで入れること。

# Apacheのバーチャルホストの設定に以下を追加
<IfModule mod_ssl.c>
        <VirtualHost _default_:8000>
                ServerName yourdomain.net
                DocumentRoot /var/www/

                ErrorLog ${APACHE_LOG_DIR}/lsws/proxy_error.log
                CustomLog ${APACHE_LOG_DIR}/lsws/proxy_access.log common

                # Proxy設定
                <Proxy *>
                    Order deny,allow
                    Allow from all
                </Proxy>
                ProxyRequests Off
                ProxyPreserveHost On

                ProxyPass / http://127.0.0.1:7080/
                ProxyPassReverse / http://127.0.0.1:7080/

				# AdminConsoleをデフォルトのまま(SSLで)使用するなら以下
				#SSLProxyEngine On
                #SSLProxyCheckPeerCN off
                #SSLProxyCheckPeerName off
                #ProxyPass / https://127.0.0.1:7080/
                #ProxyPassReverse / https://127.0.0.1:7080/


                # クライアント証明書関係
                SSLEngine on
                SSLCACertificateFile /opt/myCA/cacert.pem
                SSLCARevocationFile /opt/myCA/crl.pem
                SSLCARevocationCheck chain
                SSLVerifyClient require
                SSLVerifyDepth 1

                # SSL
                SSLOptions +StdEnvVars
                Include    /etc/letsencrypt/options-ssl-apache.conf
                SSLCertificateFile /etc/letsencrypt/live/yourdomain.net/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.net/privkey.pem

        </VirtualHost>
</IfModule>

サイトへのアクセスも楽で、パスコンが盗まれたら失効すれば良いし、クライアント認証の良さは他のセキュリティには代えがたい。Google Authenticatorとかで二段階認証やると、アクセスのたびに入力しなきゃいけなくて面倒だし、フィッシングのリスクもあるし。

カテゴリー
OS 社内SE

FreeBSD : sshやtelnetでログインしたまま、ターミナルを閉じてしまった場合の対処方法

掲題ままですが、残った仮想端末のプロセスを削除する方法を書いておきます。通常、ターミナルを落としたら、プロセスも消えるのでこのような状況にはならないのですが、不安なときの確認にもなるので。。。

  1. ターミナルから切断したユーザでログインし、以下のコマンドを打ち、現在の仮想端末の番号を確認します。
    > who
    以下のような結果が出ます。
    taro  pts/0 6月 16 04:52 (xxxxxx.or.jp)
    taro  pts/1 6月 16 04:56 (xxxxxx.or.jp)
    最も新しくログインしたものが自分なので、ここではpts/1が現在のターミナルです。
     
  2. そのまま以下のコマンドを実行し、仮想端末のプロセスを探します。
    > ps -aux | grep `whoami`
  3. 以下のような結果が表示されます。
    root 27048 0.0 1.4 20428 7976 - Is 04:52 0:00.02 sshd: taro [priv] (sshd) 
    taro 27050 0.0 1.4 20432 8008 - S 04:52 0:00.02 sshd: taro@pts/0 (sshd) 
    root 27124 0.0 1.4 20428 8012 - Is 04:56 0:00.02 sshd: taro [priv] (sshd) 
    taro 27126 0.0 1.4 20432 8036 - I 04:56 0:00.00 sshd: taro@pts/1 (sshd) 
    taro 27051 0.0 0.5 12628 2880 0 Ss 04:52 0:00.01 -sh (sh) 
    taro 27132 0.0 0.4 12324 2636 0 R+ 04:57 0:00.00 ps -aux
    
  4. 古いプロセスをkillします。
    kill 27050