「社内LinuxサーバーのローカルLLMをリモートワーク中に使いたいが、ポートを開放するのはリスクがある」
そんな悩みを抱えるLinuxエンジニアや情シス担当者は多いはずです。この記事では、SSHポートフォワーディングを使ってOllamaのAPIをリモートから安全に呼び出す手順を解説します。Nginxリバースプロキシとは異なり、サーバー側に新たなポートを公開せず、既存のSSH接続をトンネルとして使うだけで外出先からローカルLLMが使えるようになります。VPSや社内サーバーへのSSHアクセスさえ確保されていれば、追加のミドルウェアなしに今日から実現できます。Ubuntu 22.04～24.04 LTS・Rocky Linux 9系を想定環境として説明します。
この記事のポイント
・ssh -L 11434:127.0.0.1:11434 でOllamaのAPIをローカルに転送できる
・~/.ssh/config に LocalForward を書けば短いコマンドで常用設定になる
・ServerAliveInterval でキープアライブを設定し長時間推論中の切断を防ぐ
・autossh を使うと接続断時の自動再接続まで自動化できる
・Open WebUI（3000番）も同時にトンネリングしてブラウザUIをリモートで使える
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
SSHポートフォワーディングとOllamaの組み合わせを使う理由
Ollamaは起動時にデフォルトで127.0.0.1:11434 にバインドします。ローカルホストのみへのバインドは「意図しない外部公開」を防ぐ安全な設計ですが、その分、リモートからAPIを呼び出すには何らかの中継手段が必要です。リモートアクセスの手段として代表的な選択肢が2つあります。1つはNginxなどのリバースプロキシを使って11434番ポートをHTTPSで外部公開する方法、もう1つがSSHポートフォワーディングでトンネルを張る方法です。前者はチームメンバー全員に常時APIを提供する用途に向いています。後者は自分一人が使う、あるいはテスト目的で一時的に接続したいという場合に適しています。
アクセス方法ごとの安全性と設定の手間を比較すると、SSHポートフォワーディングが最もシンプルな選択肢になります。
| アクセス方法 | 安全性 | 設定の手間 | 主な用途 |
|---|---|---|---|
| Ollamaポートを直接外部公開（0.0.0.0:11434） | 低（攻撃リスクあり） | ファイアウォール設定が必要 | 不推奨（テスト用途以外は避ける） |
| Nginxリバースプロキシ+HTTPS | 高（SSL暗号化＋認証設定可） | Nginx設定・SSL証明書取得が必要 | チームメンバー全員への常時提供 |
| SSHポートフォワーディング | 高（SSH暗号化通信を使用） | コマンド1本で接続できる | 個人利用・一時的なリモートアクセス |
| 転送の種類 | コマンド形式 | 主な用途 |
|---|---|---|
| ローカルポートフォワーディング | ssh -L ローカルport:リモートhost:リモートport user@server |
VPS側のサービスを手元PCから使う（Ollama・DBなど） |
| リモートポートフォワーディング | ssh -R VPS側port:localhost:ローカルport user@server |
手元PCのサービスをVPS経由で外部に一時公開する |
| 動的ポートフォワーディング（SOCKSプロキシ） | ssh -D 1080 user@server |
複数の転送先を動的に切り替えるSOCKSプロキシ |
ssh -L コマンドの基本構文は ssh -L ローカルポート:転送先ホスト:転送先ポート user@server です。各部分の役割を把握しておくと、Ollama以外のサービスにも応用できます。・ローカルポート：手元のPCで待ち受けるポート番号（Ollamaの場合は11434）
・転送先ホスト：サーバー上での転送先ホストアドレス（127.0.0.1はサーバー自身のループバック）
・転送先ポート：サーバー上でOllamaが動いているポート番号（デフォルト11434）
・user@server：SSHで接続するユーザー名とサーバーのIPアドレス
OllamaとUbuntu Serverのセットアップがまだの方は、Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイドで基本構成を先に確認してください。
Ollamaのデフォルトネットワーク設定を確認する
SSHトンネルを張る前に、サーバー上のOllamaが正しくローカルホストにバインドされていることを確認します。この確認を飛ばすと、トンネルを正しく設定してもAPIが意図せず外部からアクセス可能な状態になっていることがあります。手順1: バインドアドレスを確認する
サーバーにSSHでログインし、以下のコマンドを実行します。
# Ollamaのリスニングアドレスを確認する $ ss -tlnp | grep 11434 # 期待する出力（ローカルバインドの状態） LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=1234,fd=3))
127.0.0.1:11434 と表示されていれば、外部からは直接到達できない安全な状態です。もし 0.0.0.0:11434 と表示されている場合は全インターフェースに公開されています。その場合は後述するsystemd設定で OLLAMA_HOST=127.0.0.1:11434 を明示してください。手順2: systemdサービスの環境変数を確認する
Ollamaをsystemdサービスとして動かしている場合、
OLLAMA_HOST 環境変数でバインドアドレスを制御します。
# Ollamaのsystemd設定を確認する $ sudo systemctl cat ollama | grep -i "OLLAMA_HOST\|Environment" # 設定されていない場合は以下でoverride.confに追記する $ sudo systemctl edit ollama # [Service] # Environment="OLLAMA_HOST=127.0.0.1:11434"
sudo systemctl daemon-reload && sudo systemctl restart ollama で反映します。バインドアドレスの確認はセキュリティ運用上の基本事項です。サーバー設定を変更した後は、必ずこの手順で再確認する習慣をつけましょう。
SSHローカルフォワーディングでOllama APIをPC手元に転送する
サーバー側の設定確認ができたら、手元のPCからSSHトンネルを張ります。手順1: 基本的なSSHポートフォワーディングコマンドを実行する
手元のPCでターミナルを開き、以下のコマンドを実行します。
user@your-server-ip の部分は実際のSSHユーザー名とサーバーIPに置き換えてください。
# ローカルの11434番ポートをリモートのOllama APIへトンネリングする $ ssh -L 11434:127.0.0.1:11434 user@your-server-ip -N # -L ローカルポート:転送先ホスト:転送先ポート の形式で指定する # -N コマンド実行なしでトンネルだけを張るオプション
-L の各値を分解すると、左の 11434 が手元のPCで待ち受けるポート番号、127.0.0.1 がサーバー上の転送先ホスト（サーバー自身のループバック）、右の 11434 がOllamaのポート番号です。手元にもOllamaをインストールしていて11434番が使用中の場合は、左のポートを 11435 などの別番号に変えることで衝突を回避できます（APIアクセス時は localhost:11435 で呼び出します）。このコマンドを実行したまま、別のターミナルウィンドウを開いてAPIを呼び出します。
手順2: トンネルが確立していることを確認する
別のターミナルで以下を実行し、11434番ポートがLISTEN状態になっていることを確認します。
# 別のターミナルでポートの状態を確認する（LISTEN が出ていればトンネル確立済み） $ ss -tlnp | grep 11434 LISTEN 0 128 127.0.0.1:11434 0.0.0.0:* # 出力が空の場合はsshコマンドが実行されていないか終了している
LISTEN が表示されていれば、手元のPCの11434番ポートからSSHトンネル経由でサーバーのOllamaへのルーティングが確立されています。接続確認をトンネルを張るたびに行う習慣をつけておくと、「トンネルが切れているのにAPIを呼んで失敗する」というトラブルを防げます。手順3: 別ターミナルからOllamaを動作確認する
トンネルが張られている状態で、手元のPCからlocalhost:11434へリクエストを送ります。
# トンネル越しにOllamaのモデル一覧を取得する $ curl http://localhost:11434/api/tags # トンネル越しにLlama3.3へプロンプトを送る（ストリームなし） $ curl http://localhost:11434/api/generate \ -d '{"model":"llama3.3:70b-instruct-q4_0","prompt":"SSHポートフォワーディングを100字で説明してください","stream":false}' \ | python3 -m json.tool
~/.ssh/configで接続を自動化・常用設定にする
毎回ssh -L 11434:127.0.0.1:11434 user@your-server-ip -N と打つのは手間です。~/.ssh/config に設定を書いておくと、短いエイリアスで接続できるようになります。手順1: ~/.ssh/configにホスト設定を追記する
手元のPCで
~/.ssh/config をエディタで開き、以下を追加します。ファイルが存在しない場合は新規作成します。
# ~/.ssh/config に追記する内容 Host ollama-server HostName your-server-ip User user Port 22 IdentityFile ~/.ssh/id_rsa LocalForward 11434 127.0.0.1:11434 ServerAliveInterval 60 ServerAliveCountMax 3 ExitOnForwardFailure yes
ServerAliveInterval 60 と ServerAliveCountMax 3 は、アイドル状態でも接続を維持するキープアライブ設定です。Ollamaで大きなモデルを動かしていると推論に数分かかることがあり、その間にトンネルが切断されるトラブルを防ぎます。ExitOnForwardFailure yes はポート転送に失敗した際にSSHが即座に終了するオプションで、ハング状態を防ぎます。手順2: 設定後の接続コマンドを確認する
# エイリアスで接続（フォアグラウンドでトンネルのみ起動） $ ssh -N ollama-server # バックグラウンドで起動する場合は -f を追加する $ ssh -fN ollama-server # バックグラウンドプロセスを停止する $ pkill -f "ssh -fN ollama-server"
ps aux | grep ssh でプロセスが生きていることを確認できます。pkill が使えない環境では、ps aux | grep ssh でプロセスIDを確認し、kill <PID> で個別に停止する方法でも構いません。
Open WebUIとOllamaをまとめてトンネリングする
Open WebUI（通常3000番ポートで動作）も合わせてリモートから使いたい場合、フォワーディングを複数設定します。OllamaとOpen WebUIを同時にトンネリングすることで、ChatGPT風のブラウザUIも手元のPCからそのまま利用できます。手順1: 複数ポートを同時にトンネリングする
# OllamaとOpen WebUIを同時にトンネリングする（コマンドで直接指定する場合） $ ssh -L 11434:127.0.0.1:11434 -L 3000:127.0.0.1:3000 user@your-server-ip -N
LocalForward 行を複数追加します。
# ~/.ssh/config に複数のポート転送を追記する Host ollama-server HostName your-server-ip User user IdentityFile ~/.ssh/id_rsa LocalForward 11434 127.0.0.1:11434 LocalForward 3000 127.0.0.1:3000 ServerAliveInterval 60 ServerAliveCountMax 3
http://localhost:3000 を開くとOpen WebUIが表示されます。Open WebUI上での操作はすべてSSHトンネル経由でサーバーのOllamaへ届くため、機密データを外部に出さずにブラウザUIを使えます。社内でのChatGPT代替として導入を検討している方は、社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢も参考にしてください。手順2: 接続後の動作確認
# OllamaのAPIが応答するか確認する $ curl http://localhost:11434/api/tags | python3 -m json.tool # Open WebUIのHTTPレスポンスを確認する $ curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 # 200 が返れば接続成功
-D）という選択肢もあります。ssh -D 1080 user@your-server-ip でSOCKSプロキシを立ち上げ、ブラウザのプロキシ設定を向けると、サーバー上の複数サービスへ柔軟にアクセスできます。ただしOllamaのAPIクライアントでSOCKS対応が必要になるため、ポートが決まっている場合は -L で個別指定する方がシンプルです。
SSHの認証セキュリティを強化する
SSHトンネルの安全性はSSH接続そのものの堅牢さに依存します。Ollamaサーバーへの不正アクセスを防ぐため、SSH認証設定を見直します。手順1: 公開鍵認証を有効にしてパスワード認証を無効にする
パスワード認証が有効なままだとブルートフォース攻撃にさらされます。公開鍵認証に一本化します。
# 公開鍵をサーバーへコピーする（手元のPCで実行） $ ssh-copy-id user@your-server-ip # サーバー側のsshd_configでパスワード認証を無効にする $ sudo grep -E "^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin)" /etc/ssh/sshd_config PubkeyAuthentication yes PasswordAuthentication no PermitRootLogin no # 設定を反映する $ sudo systemctl restart sshd
手順2: fail2banでブルートフォース対策を強化する
パスワード認証を無効にしても、ログイン試行自体は来続けます。fail2banを入れておくと繰り返し失敗したIPを自動でbanできます。
# fail2banをインストールして有効にする $ sudo apt install fail2ban $ sudo systemctl enable --now fail2ban # SSH保護の状態を確認する $ sudo fail2ban-client status sshd
よくあるSSH接続トラブルと対処法
トラブル1: 「Address already in use」エラーが出るローカルポート11434が既に使用中です。手元のPCにもOllamaをインストールしている場合によく起きます。
# 手元のOllamaサービスを停止してから再接続する $ sudo systemctl stop ollama # Linux の場合 # または別のローカルポートを使う（11435番に転送する例） $ ssh -L 11435:127.0.0.1:11434 user@your-server-ip -N # APIアクセス時は localhost:11435 を指定する # 使用中のプロセスを確認する（ssコマンドを使う場合） $ ss -tlnp | grep 11434 # lsofが使える環境では以下でも確認できる（環境により異なります） $ lsof -i :11434
pkill -f "ssh -L 11434" で停止してから再実行してください。トラブル2: トンネル接続後もAPIが応答しない
まずサーバー上でOllamaが動いているか確認します。
# サーバー側でOllamaの状態を確認する（サーバー上のターミナルで実行） $ sudo systemctl status ollama $ curl http://127.0.0.1:11434/api/tags # ローカル転送が機能しているか手元で確認する $ ss -tlnp | grep 11434 # LISTEN状態になっていればトンネルは確立している
ssh -v -N ollama-server でデバッグ出力を確認します。debug1: Local forwarding listening on 127.0.0.1 port 11434 の行が出ていれば転送は設定されています。また、Ollamaのバインドアドレスが意図せず変更されていないか（ss -tlnp | grep 11434 でサーバー側のバインドアドレスを再確認する）も合わせて確認してください。トラブル3: トンネルが途中で切断される
長時間の推論中に接続が切れる場合、autosshを使うと自動再接続が可能になります。
# autosshをインストールする $ sudo apt install autossh # 自動再接続つきでトンネルをバックグラウンド起動する $ autossh -M 0 -fN \ -o "ServerAliveInterval=60" \ -o "ServerAliveCountMax=3" \ -L 11434:127.0.0.1:11434 \ user@your-server-ip # 起動確認 $ ps aux | grep autossh
-M 0 は監視ポートを無効にして ServerAliveInterval に接続確認を任せるオプションです。autosshをsystemdサービスとして登録すれば、サーバー再起動後も自動的にトンネルが復旧します。トラブル4: 「open failed: administratively prohibited」が出る
SSH接続自体は成功しているのにポート転送が拒否される場合、サーバー側の
sshd_config でポートフォワーディングが無効化されています。
# サーバー側でポートフォワーディングの許可設定を確認する $ sudo grep -i "AllowTcpForwarding\|PermitTunnel" /etc/ssh/sshd_config # AllowTcpForwarding が no になっている場合は yes に変更する $ sudo nano /etc/ssh/sshd_config # AllowTcpForwarding yes # 設定を反映する $ sudo systemctl restart sshd
AllowTcpForwarding no が設定されている場合があります。その場合はサーバー管理者に変更を依頼するか、ProxyJump（踏み台サーバー経由）など別のアクセス方式を検討してください。
まとめ
SSHポートフォワーディングは、Nginxを立てるほどではない個人利用や一時的なリモートアクセスに最適な方法です。サーバー側でポートを新たに開放せず、既存のSSH接続をそのまま流用できるため、セキュリティリスクを最小に保ちながらOllamaをリモートから使えます。本記事で解説した手順の要点をまとめます。
| 設定・操作 | コマンド・設定値 |
|---|---|
| 基本トンネル起動 | ssh -L 11434:127.0.0.1:11434 user@server -N |
| バックグラウンド起動 | ssh -fN ollama-server（config設定後） |
| API動作確認 | curl http://localhost:11434/api/tags |
| トンネル確立確認 | ss -tlnp | grep 11434（LISTEN が出ていれば確立済み） |
| キープアライブ設定 | ServerAliveInterval 60 / ServerAliveCountMax 3（~/.ssh/config） |
| 自動再接続 | autossh -M 0 -fN -L 11434:127.0.0.1:11434 user@server |
| パスワード認証無効化 | PasswordAuthentication no（/etc/ssh/sshd_config） |
| 複数ポート同時転送 | ssh -L 11434:127.0.0.1:11434 -L 3000:127.0.0.1:3000 user@server -N |
| ポート転送の許可確認 | AllowTcpForwarding yes（/etc/ssh/sshd_config） |
SSHトンネルで動かしてみたら、次は本番クラスター構成やRAGパイプラインまで発展させたくなる方が多いはずです。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を少人数（最大8名）ZOOMハンズオン形式で開催しています。
ローカルAIマスターセミナーの詳細を確認する ＞＞
＜PR＞手元に置いて学びを深める1冊
まず無料メルマガでSSH・Linuxの基礎を固めるのが第一歩。OllamaのSSHトンネル活用からさらに踏み込んで、ローカルLLMの環境構築・実践運用を体系的に身につけたい方に手元に置いてほしい1冊です。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます