Categories
デジタルノマドエンジニア、または何百台もの社内コンピューターの“ベビーシッター”として、さまざまなクライアントデバイスからサーバーへ接続し設定を行うのは日常的な作業です。エンジニアの中には、よく使うソフトウェアやツールを事前にインストールしたノートパソコンを持ち歩き、同僚や共有コンピューター利用時の制限を回避する人もいます。
しかし、QNAP NAS への接続はさらに簡単です。NAS はデフォルトでブラウザベースの GUI による管理を採用しているため、ウェブブラウザが動作するパソコンやモバイルデバイスならどれでも NAS にアクセスしてリモート操作が可能です。
エンジニアが“ロマン”を感じる場所、それがターミナル
コマンドラインやターミナルモードへアクセスしたい場合はどうでしょうか？Windows、macOS、Linux オペレーティングシステムには通常、標準で SSH クライアントが組み込まれているため、特に問題になることはありません。
しかし、慣れないコンピューターで SSH 接続を開始する場合、以下のような不便がつきものです：
1. 古いオペレーティングシステムやモバイルデバイスは非対応
2018 年以前にリリースされた古いオペレーティングシステムや、Android、iOS デバイスでは、SSH クライアントとしてサードパーティ製アプリケーションが必要です。多くのセキュリティ重視の環境や工場では、依然として古いオペレーティングシステムが使われています。
2. セキュリティ
SSH 接続自体は安全ですが、接続確立前に入力した認証情報はローカルで監視されたりキーロギングされる可能性があります。QNAP NAS のグラフィカル管理インターフェースはログイン時に二要素認証を提供しますが、SSH はデフォルトでこの機能を備えていません。
さらに、外部ネットワークから NAS にアクセスする場合、該当ポート経由で接続できないことがあります。たとえば、NAS が外部に 8080 ポートの QTS ウェブインターフェースのみ公開している場合、SSH 接続は通過できません。
3. セッションの持続性
デフォルトでは、SSH 接続でサーバー上で実行したタスクは接続が切れると終了します。大容量ファイルのダウンロードや時間のかかる処理を行う場合、クライアント PC の前にずっといることや、公共の PC でセッションを開いたままにするのは現実的ではありません。
上記の課題はどのように解決できるでしょうか？私たちの目標は以下の通りです：
1. ウェブブラウザ経由でターミナルモードにアクセスする
2. クライアントの切断に関係なくセッションが継続して実行されること。
まず、タスクが中断されないことを確認しましょう
セッションの維持は比較的簡単に対処できます。QTS 自体にはセッション関連の問題はなく、重要なのはターミナルインターフェースです。これは screen などのターミナル多重化ツールや、Tmux のようなサードパーティーツールを使うことで実現できます。QNAP NAS のターミナルモードでは screen が削除されていないため、セッションを維持する最も簡単で便利な方法です。
screen の使用は非常に簡単です。ターミナルで「screen」と入力するだけで新しいセッションが作成されます。コマンドプロンプトは変わりません。たとえば、元々 [user1@TS-464 ~]$ であれば、screen セッション内のシェルもまったく同じように表示されます。
この時点で、たとえ screen で作成したセッションがまだ実行中でも、SSH 接続が切断されても影響を受けません。
次回 SSH 接続を確立した際は、「screen -r」で既存のセッションに再接続するだけです。screen では複数のセッションを作成できます。「screen -list」でセッションの pID を確認し、-r pID で該当セッションに再接続できます。
次のステップは 2 つ目の課題、つまりウェブブラウザ経由で QNAP NAS のターミナルモードにアクセスすることです。QTS にはこの機能が標準ではありません。最も簡単な方法は、ssh-client 機能を持つ Docker アプリケーションを Container Station で実行することです。その後、QTS のウェブインターフェースから直接コンテナのターミナルインターフェースを開くことができます。
Docker アプリケーションを作成する最速の方法は、既存の Docker イメージを利用することです。必要なのは ssh-server サービスではなく ssh-client ですが、直接Docker Hub で利用可能な openssh-serverをインストールできます。これにはクライアント機能も含まれています。公式ページには YAML 構成ファイルが用意されており、より便利にデプロイできます。
参考用の公式 YAML サンプル：
services:
openssh-server:
image: lscr.io/linuxserver/openssh-server:latest
container_name: openssh-server
hostname: openssh-server #optional
environment:
– PUID=1000
– PGID=1000
– TZ=Etc/UTC
– PUBLIC_KEY=yourpublickey #optional
– PUBLIC_KEY_FILE=/path/to/file #optional
– PUBLIC_KEY_DIR=/path/to/directory/containing/only/pubkeys #optional
– PUBLIC_KEY_URL=https://github.com/username.keys #optional
– SUDO_ACCESS=false #optional
– PASSWORD_ACCESS=false #optional
– USER_PASSWORD=password #optional
– USER_PASSWORD_FILE=/path/to/file #optional
– USER_NAME=linuxserver.io #optional
– LOG_STDOUT= #optional
volumes:
– /path/to/openssh-server/config:/config
ports:
– 2222:2222
restart: unless-stopped
作成後、Container Station インターフェイスで「実行」をクリックします。
その後、ターミナルインターフェイスを使用して NAS ホストシステムに SSH で接続できます。
追加のセキュリティのために二要素認証を有効にする
ファイアウォールの制限がなければ、コンテナにはその URL から直接アクセスできます。ただし、本記事の冒頭で強調したように、セキュリティは常に考慮する必要があります。そのため、QTS の Web インターフェイスから Container Station を起動する方が安全です。
では、パスワードをキーロガーからどのように保護できるでしょうか？見知らぬコンピューターを使用する際は常に細心の注意が必要です。画面キーボードを有効にしてマウスで認証情報を入力する以外に、現時点ではキーロガーによる認証情報の取得を防ぐ有効な方法はありません。現実的な対策は、二要素認証を有効にし、定期的にパスワードを変更することです。
QTS は、ログインセキュリティを強化するために二要素認証および認証アプリベースの認証を提供します。ただし、このシナリオでは SSH キー認証は適用されません。
Container Station で構築されたこのブラウザベースのゲートウェイと Screen のセッション永続性を組み合わせることで、セキュリティ、利便性、継続性のバランスを効果的に取ることができます。この組み合わせにより、特定のクライアントソフトウェアに依存する必要がなくなり、ネットワーク切断による進捗の喪失も心配ありません。次回、緊急対応時に普段のノートパソコンがなくても、Web ブラウザにアクセスできれば生産性を維持できます。
権限の許可を得て転載CyberQ
