余談
7年間、様々なレンタルサーバを行き来していました。
FC2ブログを2017年に開設し、数ヶ月後WordPressに移行する際に初めてレンタルサーバ（WordPress専用サーバ）を契約しました。
ある程度運営した2019年頃、併せてウェブアプリや検証を行いたかったのですが、専用サーバでは、そもそもWP以外乗せられなかったので、別のレンタルサーバを契約しました。
2023年、専用サーバに乗せていたブログのドメインパワーの恩恵及び、アドセンス等広告の審査を省略したく、サブドメインを活用しようと考えました。
しかし、サブドメインのSSL化をするにはドメイン移管が必要でした。
（ドメイン移管しないと、無償SSLサービスが受けられない等デメリットが大きい）
コスト削減のため、いずれは専用サーバを解約して一本化したくこのタイミングでブログやコンテンツの統合し、ドメインも本サーバに移管しました。
が、、、このお引越しは成功とは言えず、速度が圧倒的に遅くなりSEO評価もガタ落ちしました。
こういった不満やNode.jsの稼働、SSR化など自由な環境を求めVPSを契約しました。
もちろん自由度が上がる一方で、セキュリティ面など周辺設定にも気を配らなければなりません。
学習の一環も込めて、移管をしていきます。
はじめに
VPSサービスは、多くのサービスがありますが、さくらインターネットのVPSにしました。
法人の名が通っていますし、コスパが良く文献も多いので、こちらで契約しました。
本記事では、契約からSSH公開鍵認証による接続までの内容を記します。
契約からSSH公開鍵認証による接続を行った。
サーバ契約・会員登録
私はUbuntuの24.04 amd64（2024年6月時点で最新）を選択し、1GBプランにしました。
管理ユーザのパスワードを設定します。
SSHキーの設定は任意です。
公開鍵をサーバにインストールするには、事前に会員登録、SSHキー（秘密鍵、公開鍵）の作成が必要です。
この項目に関しては契約後に管理画面から追加できるので、無理に契約時設定する必要はありません。
契約に関して、現時点では2週間お試しで無料体験期間を得られます。
その期間中は転送速度等制限があるため、制限解除したい場合はお試し期間を無効にすることもできます。
何かしらイベントがあると3ヶ月無料やら、大きな特典があるそうですが、
今回は何もなかったので2週間お試しを有効にして登録しました。
次に、さくらインターネットの会員登録を行います。
会員登録後に管理画面を開き、VNCやシリアルコンソールからOSへ接続できれば問題ないでしょう。
キーペアの発行
VPSには、公開鍵認証を使用してSSHに接続します。
さくらインターネットのVPSは、SSHへのパスワード認証での接続を禁止しています。
そもそもパスワード認証方式はセキュリティに懸念されるため非推奨です。
そのため、まずはSSHのキーペアを発行する必要があります。
ローカルのPCから以下コマンドを実行します。
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa万一秘密鍵が漏れてしまう場合を想定してパスフレーズを設定します。
Enter passphrase (empty for no passphrase): *****公開鍵と秘密鍵が生成されたので、
秘密鍵はローカルマシン、公開鍵はリモートに配置します。
今回は、公開鍵をid_rsa.pub、秘密鍵をid_rsaとして発行しました。
秘密鍵は、Windowsであればユーザプロファイル直下の .ssh、
MacやLinuxであればホームディレクトリ直下の .ssh に保管するのが一般的です。
不要なファイル権限が付与されていたら、解除しましょう。
公開鍵は、さくらVPS管理画面の「SSHキー管理」の「SSHキー追加」から追加できます。
SSH接続する
初期設定では、SSHは22番ポートで、リモート先も初期設定では22番ポートを0.0.0.0で開放しています。
秘密鍵を収めたPCから以下を実行します。
ssh -i .\.ssh\id_rsa ユーザ名@サーバホスト名 -p 22※カレントディレクトリはユーザ（ホーム）ディレクトリとして、秘密鍵を参照しています。
Enterを押すと、パスフレーズが求められるのでパスフレーズを入力します。
これで問題なく接続できます。
なお、SSH接続可能な初期ユーザは、使用OSによって異なります。
Ubuntuの場合は「ubuntu」です。
備考
セキュリティに関して、rootユーザでのSSHログイン、パスワード認証については、
さくらVPS(Ubuntu)のドキュメントにもある通り、標準でブロックされています。
明記したい場合は、.sshのconfに以下を指定しましょう。
PermitRootLogin no
PasswordAuthentication noポート変更については、メモリフットポイントの節約に影響を受けると記述があります。
そのため、接続元のグローバルIPが固定されている場合は、ファイアウォールで接続可能アドレスをホワイトリストに追加し、ポート変更をしない方が恩恵を受けられます。
GitHub ActionsなどDevOpsを使用する場合でグローバルIPが動的であれば、接続元を制限するのが難しいケースもあるかもしれません。
そういった場合は、ポート変更を行った方がよいでしょう。
いずれにせよ、fail2banなどを使用して、試行制限や検知の設定をするべきです。