開発環境が複数あり、ssh keyは使いまわしている。今回もWindowsで使っていたssh keyをたまに使うLinux環境(ChromeOS)にコピーして、SSHしたところ「load key “/home/xxxxxx/.ssh/test03/id_rsa” : invalid format」で”Permission denied (publickey).”となった。
結論から言うと、keyファイルの改行コードがCRLFとなっていて、LFに直したら動作した。
vimで修正するには
:e ++ff=unix :%s/^M//g # ^Mは[Ctrl] ＋ [V] キーを押してから、[Ctrl] ＋ [M] キーを押せば入力可能
何年かに1回同じミスで時間を使うので備忘録。
家で２つほどサーバ的なものを建てている。１つはUbuntu22だが、１つはWindows 7である。Windows 7なんかやめたいのだが、録画サーバとして設置してあり、諸事情で10にもできずそのままになっている。もうほとんど録画もしていないが、稀に録画することがあり、手仕舞いできない。
そんなWin7の録画サーバの調子が悪い。HDDが古くディスクエラーが頻発しているので、SSDに乗り換えることにした。
Win7の現在のHDDの構成は300GBでCドライブに80GBを充てていて、これをWindowsの「バックアップと復元」で新しい128GBのSSDに載せ替えるつもりだったが、「ディスク容量不足」でどうしてもできない。Cドライブだけではなく、HDD全容量以上のディスクが必要らしい。あれやこれややってみたがうまく行かない。
仕方ないので、Ubuntu 22をUSBから起動（インストールディスクから「try ubuntu」）して対応した。手順としては、SSD側でfdiskでパーティション作成、HDDからSSDにパーティション単位でddコピー、SSDでWindows7起動確認後、ついでにgpartedで容量を80GBから128GBまで拡張した。
以下、備忘録として手順を示す。HDDは/dev/sda、SDDは/dev/sdbとする。
下準備
# ルートで作業 sudo su - # なんとインストールできる！次回起動しても有効！ apt install ntfs-3g
手順１：/dev/sdaの現在のパーティション容量確認コマンド
#このコマンドの結果出てくる、/dev/sda1と/dev/sda2をコピーすることになる。 #そのため、コピー先に同じパーティション容量の/dev/sdb1と/dev/sdb2を作成する必要があるため、ここで/dev/sda1と/dev/sda2の容量を控えておく。 fdisk -l /dev/sda # あまり覚えていないが以下のような感じで出てくる。 # 2048から9602のパーティションと96043から999999のパーティションを/dev/sdbに作成する。 /dev/sda1 * 2048 96042 123456 7 NTFS /dev/sda2 96043 999999 123456 7 NTFS
手順２：/dev/sdbにパーティション作成。（NTFSではなく、sdb1はFAT32 (LBA))で作成する。）最後のwコマンドをするまで、実際には書き込まれないので安心して作業する。
fdisk /dev/sdb
コマンド (m でヘルプ): n
コマンドアクション
e 拡張
p 基本領域 (1-4)
p # 基本pらしい
領域番号 (1-4): 1 #sda1のコピー先なので1
最初 シリンダ (1-652, default 1): 2048 # 上で控えた開始
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-652, default 652): 96042 # 上で控えた終了
# ２つ目を作成
コマンド (m でヘルプ): n
コマンドアクション
e 拡張
p 基本領域 (1-4)
p
領域番号 (1-4): 2 #sda2のコピー先なので2
# 上で控えた開始と終了の位置
最初 シリンダ (1-652, default 1): 96043
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-652, default 652): 9999999
コマンド (m でヘルプ): t
選択した領域 1
16進数コード (L コマンドでコードリスト表示): c # FAT32 (LBA)
コマンド (m でヘルプ): t
選択した領域 2
16進数コード (L コマンドでコードリスト表示): 7 # NTFS
# 起動パーティション指定
コマンド (m でヘルプ): a
Partition number (1-4): 1
# 現在の状況確認
コマンド (m でヘルプ): p
# なんか色々出る。
# 書き込み
コマンド (m でヘルプ): w
手順3：パーティションコピー bsオプションは値を上げればコピーが早くなるわけではないらしい。32Mとか64Mあたりでやる。
# sda1はすぐ終わる dd bs=32M if=/dev/sda1 of=/dev/sdb1 # こっちは長い・・・ dd bs=32M if=/dev/sda2 of=/dev/sdb2
これでSSDから起動してみて起動できればOKである。NGだった場合は、fdisk -l /dev/sdbをよく見てみる。MBRの調整などは基本不要である。コピーが失敗していないか、ファイルシステムが違わないか、起動(boot)パーティションが指定されているかを確認する。
このあとはやらなくても良い（起動しなくなるリスク有り）のだが、gpartedを起動してパーティションサイズを拡張した。gpartedは必ずsudoコマンドで起動すること。
sudo gparted
GUIなので説明は割愛。対象のディスクを選んで、リサイズを選択してからドラッグしてリサイズする。
ローカルネットの中だけのサーバだが、そのうちセキュリティの問題でsambaが他のデバイスから繋がらなくなりそう。そうなったら破棄するか何かで対応しよう。。。
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)”となりはじかれるので注意。（ここがわからず時間がかかってしまった。。）
ここ数年、個人の開発環境は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より遅く感じた。あくまで体感だが、１コアで最小限のセッティングにした場合、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環境があったり、クローズドな社内ネットワーク内にサーバがあったりするので、保留。
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系ならこういった作業は不要なのかもしれない。
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を引き継ぎ続けているため、こんな設定になっている・・・。
最近一部の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 lswsApacheで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とかで二段階認証やると、アクセスのたびに入力しなきゃいけなくて面倒だし、フィッシングのリスクもあるし。