SSH でインスタンスに入る

接続に必要な値は 3 つだけ

SSH（= 遠くのコンピューターに、通信を暗号化したまま安全にログインする仕組み）で入るために覚えることは 3 つです。ユーザー名・ホスト・ポート番号。vast.ai ではこのうちユーザー名が常に root に固定されているので、実際に調べるのは残り 2 つだけです。

先に釘を刺しておきます。SSH の既定のポート番号は 22 ですが、vast.ai のインスタンスに 22 番で繋ぐことはありません。1 台のマシンの公開 IP アドレスを複数の借り手が共有していて、コンテナ内部の 22 番はホスト側の別の番号に割り当て直されるからです（この仕組みは第 10 章）。だから接続コマンドには必ず -p でポート番号を渡します。ここを知らずに ssh root@… だけを打って「繋がらない」と言うのが、最初の 5 分で起きる事故です。

3 つの値を取る方法は 2 つあります。コンソールのインスタンス一覧に並ぶインスタンスカードの SSH ボタンを押すと、そのまま貼れる接続コマンド文字列が出ます。ターミナルからなら CLI です。

vastai ssh-url <INSTANCE_ID>

<INSTANCE_ID> には対象インスタンスの ID を入れます。分からなければ vastai show instances で一覧が出ます（インスタンス作成時に返ってきた JSON の new_contract の値と同じものです。id という名前ではないので探すときに注意してください）。返ってくるのは次のどちらかの形です。

ssh://root@ssh5.vast.ai:33426          # proxy 接続の場合
ssh://root@142.214.185.187:20544       # direct 接続の場合

ssh:// で始まる URL 形式なので、手で打つコマンドの形に読み替える必要があります。公式のサンプルもこの読み替えを前提に書かれています。

スクリプトから使うなら JSON で取るのが確実です。--raw を付けると機械可読な JSON が返ります。

vastai show instance <INSTANCE_ID> --raw

この JSON のうち、接続に関係するフィールドは次のものです。

• ssh_host — 接続先のホスト名または IP（例 ssh2281.vast.ai）
• ssh_port — 接続に使うポート番号（例 10882）
• public_ipaddr — インスタンスの公開 IP アドレス
• direct_port_count — direct 接続に使えるポートの数
• ports — 内部ポートと外部ポートの対応表（第 10 章で使います）

proxy 接続と direct 接続

打つコマンドは同じ 1 行なのに、そこから先の経路は 2 種類あります。proxy 接続（= vast.ai の中継サーバを経由して入る方式。既定）と direct 接続（= インスタンスが載っているホストへ直接入る方式）です。SSH 起動モードを選ぶと、vast のシステムはホストのルータに開いているポート（オープンポート）があるマシンなら両方をセットアップしようとします。proxy はバックアップとして常に用意され、direct が張れたときはそちらが使えます。

正直に書いておきます。公式ドキュメントは、この速度差を数値で書いていません。出てくる表現は「slower for data transfer」「faster and more reliable」「lower latency than proxy SSH」という定性的なものだけです。「何ミリ秒速い」と書いてある記事を見かけても、それは公式の値ではありません。

direct を掴むには、借りる前の条件が 1 つあります。ホストのルータに開いているポートが必要で、offer 検索のフィールド direct_port_count（= ホストのルータで開いているポート数）で絞れます。

vastai search offers 'gpu_name=RTX_5090 num_gpus=1 verified=true direct_port_count>=1 rentable=true' -o 'dlperf_usd-'

クエリ全体をシングルクォートで囲むのは公式の指示です（> がシェルのリダイレクト記号と衝突するため）。gpu_name の値はスペースをアンダースコアに置き換えるので RTX_5090 と書きます。RTX 5090 や 'RTX 5090' では通りません。末尾の -o 'dlperf_usd-' は「1 ドルあたりの DL 性能の降順」、つまりコスパ順の並べ替えです。

RTX 5090 に関しては、この条件で候補が枯れる心配はまずありません。2026-08-24 時点で 1 枚構成の RTX 5090 の offer 64 件を実測したところ、direct_port_count の中央値は 98 でした。借りるときは --ssh（SSH 起動モード）に --direct（jupyter と ssh の両方でより速い直接接続を使う）を添えます。

vastai create instance <OFFER_ID> \
  --image <IMAGE> \
  --disk 40 \
  --ssh --direct

<OFFER_ID> は search offers が返した offer の id、<IMAGE> は使う Docker イメージ名（第 7 章で選んだもの）です。ここで大事なのは、起動モードは作成時に決まり、後から変えられないことです。「あとで direct に切り替える」はできません。作り直しになります。

お金の目安を先に置きます。この章で新しく始まる種類の課金はありません（インスタンスはすでに動いているので、GPU の時間課金とディスク課金は第 8 章から続いています）。ただし接続を試している間も GPU の時間課金は動き続け、ファイル転送には転送量ぶんの帯域課金が乗ります。2026-08-24 時点の 1×RTX 5090 は中央値 0.4037 USD/時。接続の練習に 15 分使うなら約 0.10 USD（1 USD = 150 円として約 15 円）です。

初めて入る

順序の確認を 1 つだけ。SSH の公開鍵はインスタンスを作る前にアカウントへ登録しておく必要があります（第 8 章でやった作業です）。SSH の鍵は 2 つで 1 組です。公開鍵（= 相手のサーバに預ける側。人に見せても安全。~/.ssh/id_ed25519.pub）と秘密鍵（= 手元にだけ置く側。誰にも渡さない。~/.ssh/id_ed25519）で、vast.ai に登録するのは公開鍵だけです。公式は「it is applied at container creation time」（コンテナ作成の時点で適用される）と書いており、後から登録した鍵は既存のインスタンスには入りません。忘れて作ってしまった場合の救済手段はこの章の最後にあります。

vastai ssh-url <INSTANCE_ID>
# → ssh://root@142.214.185.187:20544

ssh -p 20544 root@142.214.185.187

The authenticity of host '[142.214.185.187]:20544 ([142.214.185.187]:20544)' can't be established.
ED25519 key fingerprint is SHA256:WTUphznpN0zikMp+L5EtZpiCH6EeZ2PA/7+DSXDRjT0.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

nvidia-smi

手元が Windows の場合

コマンドは Mac と同一です。新しめの Windows は PowerShell で ssh と ssh-keygen がそのまま動き、公式も「可能な限り CLI を使え」と推奨しています。違いは鍵の置き場所で、C:\Users\<YourUsername>\.ssh\ になります。公開鍵の中身を見るには Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub です。WSL（Windows Subsystem for Linux）を使う場合は Mac / Linux とまったく同じ手順でよい、と FAQ に明記されています。

GUI のクライアントを使いたい場合は PuTTY か MobaXterm ですが、どちらも PuTTY 形式の .ppk 秘密鍵を使う点が詰まりどころです。OpenSSH 形式の鍵をそのまま渡せません。PuTTY なら PuTTYgen で鍵を作り（緑のバーが満タンになるまでマウスを動かすよう求められます）、Session タブに IP アドレスとポート、Connection -> Data の Auto-login username に root、Connection -> SSH -> Auth -> Credentials で .ppk を選ぶ、という並びです。MobaXterm は Sessions -> New Session -> SSH で Remote Host / Specify Username（root）/ Port / Use private key の 4 項目を埋めるだけです。PuTTYgen で鍵を作るときは SSH RSA-2 形式で保存するよう公式 FAQ が注記しています。

GUI ツールの設定が面倒なら、逃げ道があります。Jupyter Terminal（= ブラウザの中で動くターミナル）です。Jupyter 起動モードで作ったインスタンスなら全台で使え、インスタンスカードの SSH ボタン（SSH connections インターフェース）からアクセスできます。公式も Windows 向けの逃げ道としてこれを挙げています。詳しくは第 10 章で扱います。

入った先は tmux になっている

入った直後に「画面の下に帯が出ている」「Ctrl+C を押したのにプロセスが残っている」と感じても、壊れてはいません。vast.ai は既定で tmux セッションの中に繋ぎます。tmux（= 1 つのターミナルの中に複数の画面を持ち、接続が切れても中の処理を生かしておく仕組み）です。公式が挙げる理由は「信頼性のため、フォアグラウンドプロセスの意図しない終了を防ぐため」。

これは初心者にとってありがたい既定値です。モデルのダウンロードや推論サーバの起動は数十分かかることがあり、その途中で Wi-Fi が切れたりノート PC の蓋を閉じたりすると、素の SSH なら処理も一緒に死にます。tmux の中なら残ります。最低限、次の 4 つを知っていれば困りません。

「サーバを起動したまま別の作業をしたい」場面が必ず来ます。そのときは Ctrl+b → c で新しいウィンドウを開いてください。Ctrl+C でサーバを止める必要はありません。

tmux を無効化する方法もあります（インスタンス内で touch ~/.no_auto_tmux）が、公式が推奨していません（SSH は不安定になりうるため）。消すと、回線が切れた瞬間に走っていた処理が道連れで落ちます。触らないでおくのが正解です。

ポートを公開せずに手元のブラウザから使う

本章で一番実用的なのがここです。llama.cpp や vLLM、Open WebUI をインスタンスで動かすと、それらはポート（= 1 台のマシンの中でサービスを区別する番号）で待ち受けます。手元のブラウザからそれを開きたい。素朴な方法は「そのポートを外に公開する」ですが、公開した瞬間、共有の公開 IP 上の外部ポートとしてインターネットから到達できる状態になります（第 10 章）。認証を付け忘れれば、誰でも自分の GPU で推論できてしまいます。

公式はこれを避ける手段を明示しています。ssh -L によるローカルポートフォワードです。公式の言葉では「しばしば見落とされる SSH の機能」であり、「公開インターフェースにポートを開けることの安全な代替。すべてのデータは SSH 接続の中を運ばれる」。

ssh -p 20544 root@142.214.185.187 -L 8080:localhost:8080 -L 5000:localhost:5000

繋いだあとは手元のブラウザで http://localhost:8080 を開けば、インスタンスの中で動いているサービスに届きます。サービス側が TLS を張っているなら https://localhost:8080 です。コンソールの SSH ボタンが出す既定のコマンド文字列にも、最初から -L 8080:localhost:8080 が入っています。

ssh -p <PORT> root@<HOST> -L 8080:localhost:8080

python -m http.server 8080

VS Code から開く・ファイルを送る

SSH 鍵が設定済みなら、エディタから直接インスタンスのファイルを編集できます。公式の手順は 4 段です。

1. 拡張機能 Remote - SSH をインストールする
2. Open Remote Window ボタンをクリックする
3. ウィンドウ上部に出る入力欄に ssh のアドレス情報を入力する
4. VS Code がインスタンス側を構成し終わるのを待つ。あとはローカルのフォルダと同じように扱える

ここも正直に書きます。入力欄に入れる文字列の正確な形式は公式ドキュメントに書かれていません（本文はスクリーンショットだけで、.ssh/config の書式や ProxyJump の設定例もありません）。まずコンソールの SSH ボタンが出すコマンド文字列をそのまま貼るのが最短です。Cursor でも同じ Remote-SSH で繋がる、と公式の移行ガイドに書かれています。

ファイル 1 つ 2 つを送るだけなら、エディタを立ち上げるより scp（= SSH の通信路を使って、手元とリモートの間でファイルをコピーするコマンド）が速いです。ディレクトリを見ながら対話的に操作したいときは sftp -P <PORT> root@<HOST> もあります。公式は「scp = 素早い単発転送、sftp = ファイル管理・複数操作向け」と使い分けを説明しています。

echo "hello vast" > memo.txt
scp -P <PORT> ./memo.txt root@<HOST>:/workspace/

cat /workspace/memo.txt
echo "edited on the instance" >> /workspace/memo.txt

scp -P <PORT> root@<HOST>:/workspace/memo.txt ./memo-back.txt
cat memo-back.txt

この scp に、公式が Note でわざわざ警告している罠があります。ポート指定は scp と sftp が大文字の -P、ssh だけが小文字の -p です。小文字で書くと別の意味のオプションとして解釈され、意図した接続になりません。最頻出の詰まりどころとして名指しされています。

速度についても公式の線引きがあります。proxy 接続経由の scp は遅いので、1 GB 未満の小さい転送に留めろ。大きい流入転送は direct SSH を使え。そしてモデルの重み（数 GB〜数十 GB）のような大物は、手元から送るのではなくインスタンスの中から wget や curl で直接落とすほうがはるかに速いことが多い、とも書かれています（第 11 章でやります）。CLI の vastai copy も使えますが、宛先に /root や / を指定してはいけません。インスタンスの ssh フォルダのパーミッションが壊れ、以後の copy 操作が失敗します。

入れないときの切り分け

症状は 3 つに分かれます。手元から出た接続がどこまで届いてから止まったかで症状が変わるので、当てずっぽうに再試行するより先に、どれなのかを見てください。ポート番号かインスタンスの状態が違えば返事そのものが来ませんし、そこを越えて相手の sshd（= 接続を受け付けるサーバ側のプログラム）まで届いていれば、返ってくるのは鍵に関するエラーです。

パスワードを聞かれる

vast.ai のインスタンスは鍵認証のみで、パスワード認証はセキュリティ上の理由で無効化されています。つまり聞かれている時点で鍵が効いていません。公式が挙げる原因は 4 つ。鍵がアカウントに正しく追加されていない／公開鍵を全文コピーしていない／SSH クライアントの設定ミス／秘密鍵が ssh-agent（= 秘密鍵を覚えておいて ssh に渡す常駐プログラム）にロードされていない。

実際に一番多いのが 2 番目です。公開鍵は 1 行の長い文字列で、先頭の種類（ssh-rsa や ssh-ed25519）から末尾のコメントまで全部が 1 つの鍵です。真ん中の英数字だけをコピーしても通りません。公式が示している完全な形はこれです。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAZBAQDdxWwxwN5Lz7ubkMrxM5FCHhVz... bob@velocity

Permission denied (publickey)

公式の切り分け順はこの 4 段です。上から順に潰します。

1. 公開鍵が Keys ページ に登録されているか確認する
2. 正しい秘密鍵を使っているか確認する（複数の鍵を持っている場合の取り違えが多い）
3. 秘密鍵のパーミッションを直す: chmod 600 ~/.ssh/id_ed25519
4. 詳細ログを取る: ssh -vv -p <PORT> root@<HOST>

原因の候補として公式が列挙しているのは、間違った秘密鍵を使っている／秘密鍵のパーミッションが不正／公開鍵がインスタンスにもアカウントにも登録されていない／間違ったポートに繋いでいるの 4 つです。最後の 1 つは意外に多いので、vastai ssh-url を取り直して番号を突き合わせてください。

鍵を登録し忘れて作ってしまった

vast.ai のインスタンスには 2 種類あります。Docker インスタンス（= Docker コンテナとして動く既定の形。本書で扱うのはこちら）と、VM インスタンス（= 仮想マシンとして動く形。作成時に指定した場合だけ）です。Docker インスタンスなら救えます。稼働中のインスタンスに鍵を後付けするコマンドがあります。

vastai attach ssh <INSTANCE_ID> ~/.ssh/id_ed25519.pub

公式の例では、公開鍵の文字列を直接渡す形・$(cat ~/.ssh/id_rsa.pub) の形・ファイルパスを渡す形の 3 通りすべてが載っています。コンソールのインスタンスカードの SSH 鍵ボタンからも同じことができます。ただし VM インスタンスは鍵の変更に作り直しが必要です（API リファレンスの注記では「VM: no recovery」）。

ここでドキュメントの矛盾に触れておきます。ガイド側は「アカウントに追加した鍵が効くのは新規インスタンスだけ」と警告する一方、API リファレンスの一部は「すべての現行インスタンスに自動追加される」と書いており、真っ向から食い違っています。どちらが実態かは公式ドキュメントからは判定できません。厳しい側（作成前に登録しておく）を前提に動けば、どちらが正しくても困りません。

そもそも状態が違う

インスタンスカードのメインボタンの表示が、そのまま状態を表しています。

• Connect — ロード完了。クリックで SSH 情報が出る
• Open — ロード完了。ブラウザからアクセスできる
• Loading — Docker イメージのダウンロード中。ホストにキャッシュ済みなら 30 秒程度、回線が遅い・イメージが巨大だと数時間かかることもある。公式は「Loading 中は課金されない」と書いていますが、別の公式ページは「ストレージ課金は作成時から、GPU 課金は running になってから」としています。止まっているのは GPU の時間課金で、ディスク課金は作成した時点から動いていると考えるのが安全です
• Connecting — Docker は動いているが接続が未検証。ポート設定が壊れている可能性がある
• Scheduling — 再起動を試みて GPU の空きを待っている。30 秒以上進まないなら、その GPU は他のユーザーに取られた可能性が高い
• Inactive — 停止中（データは保持されている）
• Offline — マシンが vast のサーバから切断されている

そして終端状態を覚えてください。actual_status が exited（コンテナがクラッシュ）・unknown（ホストからのハートビートが来ていない）・offline（ホスト切断）のどれかになったら、そのインスタンスは二度と running に戻りません。待っても直りません。しかもその間ディスク課金は続きます。公式が案内している対処は 1 つで、destroy して別の offer で作り直すことです。

最後に、SSH が使えないときの 2 つの逃げ道です。

vastai logs <INSTANCE_ID> --tail 50
vastai execute <INSTANCE_ID> 'ls -l'

vastai logs は起動時の出力を見るためのものです（既定は末尾 1000 行、--tail で行数指定）。インスタンス起動直後はログが出るまで少し待つ必要があり、待ちのメッセージが出たら少し置いて再試行します（REST API の仕様では、ログはいったん S3 にアップロードされ、その URL 経由で取り出される二段構えになっています）。vastai execute は停止中・アクセスできないインスタンスのファイルシステムを覗くための逃げ道で、使えるコマンドは ls / rm / du の 3 つだけです。bash コマンドはシングルクォートで囲み、結果の取得に数秒かかることがあります。公式が載せている例は 'ls -l -o -r' / 'rm -r home/delete_this.txt' / 'du -d2 -h' の 3 つで、いずれもパスの先頭にスラッシュを付けていません。任意のコマンドを流したいなら、execute ではなく SSH を使います。

つまずきポイント

理解度チェック

まとめ

• 接続に必要なのは ユーザー名 root・ホスト・ポート番号の 3 つ。vastai ssh-url が返す ssh://root@HOST:PORT を ssh -p PORT root@HOST に読み替える。22 番では繋がらない
• proxy と direct の違いは中継が 1 台入るかどうか。direct が推奨だが、借りる前に direct_port_count>=1 で絞り、作成時に --ssh --direct が必要。起動モードは後から変えられない。2026-08-24 時点の 1×RTX 5090 なら direct_port_count 中央値 98 で、まず困らない
• 入った先は tmux。Ctrl+b → c で画面を増やす。無効化は公式が非推奨
• 手元のブラウザから使うなら ssh -L 8080:localhost:8080。ポートを 1 つも公開せずに済み、第 10 章の露出事故がそもそも起きない
• 入れないときは症状で切る。パスワードを聞かれたら鍵の問題（パスワードは存在しない）、Permission denied は秘密鍵とパーミッション、無反応はポート番号と状態。exited / unknown / offline は待たずに作り直す

次章では、同じインスタンスをブラウザから使う道具（Jupyter・Instance Portal）と、-p でポートを外に開けたときに何が起きるかを見ます。この章で ssh -L を覚えた人は、そのほとんどを「開けずに済ませる」判断ができるようになります。

参考リンク

• vast.ai — Connect via SSH（鍵の作り方・proxy と direct・tmux・ssh -L・scp）
• vast.ai — Connection Overview（3 つの起動モードと自動で開くポート）
• vast.ai — Windows Guide（PowerShell・PuTTY・MobaXterm）
• vast.ai — FAQ: Jupyter & SSH（パスワードを聞かれる原因・鍵の全文）
• vast.ai — Manage Instances（カードの状態表示と終端状態）
• vast.ai — Data Movement（scp / sftp の使い分けと転送速度の目安）
• vast.ai CLI — Hello World（鍵は作成前に登録・--ssh --direct）
• vast.ai CLI — ssh-url（接続先の取得）
• vast.ai CLI — attach ssh（稼働中インスタンスへの鍵の後付け）
• vast.ai CLI — logs（--tail と取得の仕組み）
• vast.ai CLI — execute（ls / rm / du の 3 コマンド）
• vast.ai CLI — search offers（direct_port_count とクエリ構文）
• vast.ai — Migration Guide（Remote-SSH・ポート環境変数・tmux の扱い）