ネットワーク技術 on AIによる技術記事備忘録

DeepSeek Harness入門：Clineとの違いからリモート実行環境の構築・トラブルシュートまで

Wed, 28 Oct 2026 01:57:29 +0900

自律型AIエージェントの実行環境として登場した DeepSeek Harness（CLI名：dsh）は、これまでエディタ統合型ツールを利用してきた開発者にとって、運用の前提を大きく変える存在です。VSCodeと拡張機能の組み合わせ（Clineなど）による開発スタイルと何が異なるのか、その設計思想からローカルネットワーク越しの安全な運用環境の構築手順、初期導入時のトラブルシュートまでを論理的に解説します。

1. エージェントの実行台座「ハーネス」の概念とClineとの違い

工学において「ハーネス（Harness）」は本来、馬を御する馬具や電気配線を束ねるワイヤーハーネス、あるいはソフトウェアの テストハーネス（テスト対象を包み込み、入力を与えて出力を観測する台座）を指す言葉です。

大規模言語モデル（LLM）は単体ではテキストの入出力を行う計算機構に過ぎず、ファイルを読み書きする権限もシェルを実行する手段も持ちません。エージェント工学におけるハーネスとは、モデルを作業環境（ファイルシステム、OS、シェル、ネットワーク）に接続し、その 思考と実行の自律ループを制御・記録・検証するための外枠（実行・観測台座） を意味します。

これまで広く使われてきた VSCode + Cline と DeepSeek Harness の決定的な違いは、その設計思想にあります。

VSCode + Cline：人間のエディタ操作に寄り添う「ペアプログラミング型」のアシスタントです。エディタ上で差分を目視確認しながら対話的にコードを修正する用途に適していますが、VSCodeのGUIセッションに強く依存し、履歴は一本道のチャットとして蓄積されます。
DeepSeek Harness：モデルの自律タスク実行と挙動検証を主眼に置いた「独立型テストベンチ」です。エディタから独立したプロセス（CLIおよびWeb UI）として動作し、エージェントの挙動を Trajectory（実行軌跡） と呼ばれる構造化データとして記録します。過去の任意のステップに戻って別の指示を与える分岐実行（Fork）や、一連の実行ログをそのままトレースする完全再現（Replay）が可能です。

2. macOSでのセットアップと運用設計の思想

macOS上で動作させる場合、Node.js 22.19以上（または24系）の環境を用意し、作業対象のディレクトリから起動します。

# 環境変数の設定（~/.zshrc 等）
export DEEPSEEK_API_KEY="sk-xxxxxxxxxxxxxxxxxxxxxxxx"

# ワークスペースディレクトリで起動
cd /path/to/project
npx @deepseek-ai/dsh web

Web UIを開くと、VSCodeのような人間向けの対話型ターミナルが存在しないことに気づきます。これは制限ではなく、状態の再現性を担保するための意図的な設計 です。人間が裏で自由にシェルコマンドを叩いてファイルや環境の状態を変更してしまうと、Harnessが記録しているTrajectoryと実際のファイルシステムとの整合性が崩れ、過去ステップへの巻き戻しや分岐の正確性が失われます。そのため、すべてのコマンド実行はエージェントのツール呼び出しとして扱われ、人間はそれを承認（Approve）するかどうかを判断する形を取ります。

また、Harnessを利用する際は トークン消費の累積構造 を意識する必要があります。自律エージェントのコンテキスト長 $C_t$ は、ステップ数 $t$ に対し、初期プロンプト $I$、各ステップの思考 $T_i$、ツール実行ログやコマンド出力 $O_i$ の総和として累積します。

$$C_t = I + \sum_{i=1}^{t} (T_i + O_i)$$

巨大なテストログの出力やファイル全体の読み込みが発生すると、1回のリクエストで送信される入力トークンが急増します。タスクごとにセッションを細かく切り替えることや、DeepSeek Platform側のダッシュボードで利用上限額（Hard Limit）を事前に設定しておく運用が推奨されます。

3. セキュリティ境界の設計：専用マシンとリモート運用の可能性

Harnessは外部アクセス機能を持たないローカルWebサーバーとして動作しますが、外出先から利用するために Cloudflare Tunnel と Cloudflare Access（Zero Trust）を組み合わせる構成は非常に合理的です。ルーターのポート開放を行うことなく、Cloudflareのエッジで強固なゼロトラスト認証（Google認証やメールPIN）を通過した通信のみをローカルの 127.0.0.1:3080 へ安全に転送できます。

しかし、エージェント環境のリモート常時稼働には固有のリスクが存在します。エージェントは「任意のシェルコマンド実行権限」を持つため、設定不備や不測の脆弱性が生じた際の影響範囲（Blast Radius）が、個人データや各種秘密鍵を保管しているメインの作業マシン全体に波及しかねません。

このリスクを根本的に排除するためには、使わなくなったPCやミニPC、隔離された仮想マシン（VM）を DeepSeek Harness専用マシン として切り出し、メインの開発端末と物理的・論理的に分離するアプローチが極めて有効です。専用マシン上には必要最小限のリポジトリとAPIキーのみを配置し、万が一のインシデント時にもメインの環境を安全に保つ構成が取られます。

4. LAN内別マシン（Windows）からのアクセスと認証トークンの解決

家庭内やオフィス内のLANにおいて、Mac上で動くHarnessのWeb UIに対して別のWindowsマシンからアクセスしたい場合、SSHポートフォワーディングを利用するのが最も簡潔で安全です。

Windows 10/11には標準で OpenSSH クライアントが統合されているため、WSL2を起動する必要はありません。WSL2内部でSSHトンネルを張ると、仮想マシンのNATやlocalhostフォワーディングの不整合によってブラウザから通信が届かないトラブルの原因になりやすいため、WindowsネイティブのPowerShell から直接コマンドを実行します。

# WindowsのPowerShellで実行
ssh -N -L 3080:127.0.0.1:3080 <Macのユーザー名>@<MacのローカルIP>

このコマンドを維持した状態でWindowsのブラウザから [http://127.0.0.1:3080](http://127.0.0.1:3080) にアクセスすると、次のようなエラーが表示されることがあります。

dsh web authentication required; reopen the URL printed by dsh web.

これは不具合ではなく、同一LAN内の他者やローカルの別プロセスによる不正操作（CSRF等）を防ぐための ワンタイム認証トークン仕様 によるものです。

解決手順

Mac側で dsh web を起動した際、ターミナルの出力ログの末尾にクエリパラメータが付与されたURLが表示されています。

http://127.0.0.1:3080/?token=abcdef1234567890...

Windows側ブラウザのアドレスバーに、単なる [http://127.0.0.1:3080](http://127.0.0.1:3080) ではなく、この ?token=... を含めた完全なURL を入力して開くことで認証が完了し、以降は別マシンのブラウザからMac上のHarnessを安定して操作できるようになります。

Mac miniをホストにしてAntigravityの作業環境を複数マシンでシームレスに引き継ぐ方法

Mon, 24 Aug 2026 07:41:46 +0900

Google AntigravityでAIコーディングを行う際、課題となるのが「チャットセッションや作業状態が単一マシン内に閉じてしまう」という点です。メインのデスクトップMacで進めていた作業を、手元のWindowsノートPCや別端末からそのまま継続しようとすると、文脈の引き継ぎが難しくなります。

この問題を解決するため、常時稼働させているデスクトップMac（Mac mini）を開発ホストとして集約し、ノートPC等の別端末からはSSH経由でAntigravity CLI（agy）とtmuxを組み合わせて操作する構成を採用することにしました。本記事では、この構成を選定した理由と、環境構築にあたって遭遇したトラブルの回避手順を備忘録としてまとめます。

なぜMacホスト＋Antigravity CLIの構成を選んだのか

最初に検討したのは、GUI版Antigravity（VS Codeフォーク）の内蔵Remote-SSH拡張機能を使ってMacに接続する方法でした。しかし、実際に接続を試みると内部スクリプトがLinux環境を前提としたコマンド（flock 等）に依存しており、現時点ではmacOSをSSHホストとしてGUI接続することはできません。

また、自前の低スペックLinuxサーバーをホストにする案もありましたが、重いビルド処理やコンテナの運用を考慮すると、CPU性能やメモリに余裕があるMac miniを活用するほうが快適です。

そこで、GUIのリモート接続に拘るのではなく、CUI環境で完結する公式CLIツールagyを採用し、ターミナルマルチプレクサであるtmux上で稼働させるアプローチに落ち着きました。この構成であれば、OSの互換性問題を完全に回避しつつ、どの端末からでも同一のセッションに再接続してAIとの対話を再開できます。

鍵認証とセッション分離の注意点

構築時にまず直面したのが、SSH接続時の認証エラーでした。サーバー上でGiteaなどをホストしている場合、Git操作用に登録された公開鍵でログインを試みるとシェルアクセスが拒否されます。そのため、通常のシェルログイン専用となる新しいSSH鍵ペアを作成し、接続設定で明示的に指定する必要があります。

クライアント端末（Windows等）で開発用の鍵を生成し、ホスト側の ~/.ssh/authorized_keys に登録します。

# 鍵ペアの生成
ssh-keygen -t ed25519 -f ~/.ssh/id_dev_server -C "dev-login"

クライアント側の ~/.ssh/config には、他の鍵が自動送信されないよう IdentitiesOnly yes を含めて設定を記述します。

Host dev-server
 HostName 192.168.0.xxx
 User your_user
 IdentityFile ~/.ssh/id_dev_server
 IdentitiesOnly yes

Windows環境から接続する場合は、PowerShellネイティブのコンソールよりもWSL2（Linux環境）経由で接続したほうが、文字コード（UTF-8）や端末制御（PTY）の互換性が高く、表示崩れや文字化けを起こさず安定します。

tmuxとagyによるセッション永続化と運用

agy 単体で起動するとSSH切断時にセッションが切れてしまうため、ホスト側のMac上で tmux を起動し、その中で対話セッションを実行します。

ホストのMac側では、マウススクロールの有効化と文字コードの安定化のため、あらかじめ ~/.tmux.conf に設定を追加しておきます。

set -g mouse on
set -g default-terminal "screen-256color"

日常的な運用で必要な操作はシンプルです。作業を開始する際は、既存セッションへの再接続（存在しない場合は新規作成）をまとめて行うワンライナーで接続します。

tmux attach -t dev || tmux new -s dev

セッション内で agy を起動すれば、直前までのプロジェクト構造を読み取った状態でAIコーディングを開始できます。過去の会話セッションを再開したい場合は、起動時に --resume フラグを付与するか、対話画面で /resume コマンドを実行して履歴を選択します。

# 直前の対話を再開して起動
agy --resume

作業を中断したい時は、キーボードで Ctrl + b を押した後に d を押してデタッチします。これによりMac側でプロセスが保持され、後から別のノートPCを開いて再び tmux attach -t dev を実行するだけで、全く同じ画面・対話状態へと即座に復帰できます。

SSH鍵方式の変遷とEd25519への移行メモ

Mon, 27 Oct 2025 18:58:20 +0900

長年SSH鍵を生成する際には ssh-keygen -t rsa が定番であった。しかし近年、セキュリティ界隈では「Ed25519」方式が推奨されるようになっている。本記事ではRSAからEd25519への変遷を整理し、その背景と注意点を備忘録としてまとめる。

RSAの現状と課題

RSAは公開鍵暗号の古典的方式であり、長年にわたって安定して使われてきた。現在でも2048bitまたは4096bitの鍵長を採用すれば、現実的な攻撃に対して十分な強度を持つ。しかしRSAには次のような課題がある。

第一に、鍵生成・署名・検証の計算コストが大きい。特に組み込み機器や仮想環境ではパフォーマンス低下が無視できない。第二に、十分な安全性を確保するには鍵長を増やす必要があり、その結果として鍵サイズや通信オーバーヘッドが増加する。第三に、量子計算の実用化が進めばRSAも楕円曲線暗号も同様に破られる可能性があるため、将来的な耐性は限定的である。

このようにRSAは依然として安全ではあるが、効率面で時代遅れとなりつつある。

Ed25519とは何か

Ed25519は楕円曲線暗号の一種であり、正式には「Edwards curve over the prime field 2²⁵⁵−19」を指す。この“25519”という数字は、基礎となる素数体の法 2^255 - 19 に由来する。Daniel J. Bernsteinによって設計され、高速性・安全性・実装の簡潔さを兼ね備えている点が特徴である。

Ed25519の主な利点は次の通りである。

鍵と署名のサイズが小さい（64バイト程度）
署名と検証が高速
タイミング攻撃などの実装依存の脆弱性に強い
鍵長の指定が不要で、常に固定長で安全な設計になっている

このため、OpenSSH 6.5以降ではデフォルト推奨方式としてEd25519が採用されている。

注意すべき点とトレードオフ

Ed25519は優れた方式であるが、RSAの完全上位互換ではない。まず、古いシステムではEd25519鍵に対応していないことがある。特にレガシーなネットワーク機器や古いクラウド環境では、接続できない可能性がある。次に、Ed25519は鍵長を調整できないため、「より長い鍵を使いたい」という要求には応えられない。また、Ed25519の署名方式（EdDSA）はRSAのようにX.509やPGP証明書体系と互換性がない。

したがって現実的には、新規環境ではEd25519を採用し、古い環境との互換性を保つためにRSAも併用するのが妥当である。

Ed25519鍵の作成方法

Ed25519鍵を生成する手順はRSAとほとんど同じである。違いは-tオプションだけである。

ssh-keygen -t ed25519 -C "your_email@example.com"

上記コマンドを実行すると、~/.ssh/id_ed25519（秘密鍵）と ~/.ssh/id_ed25519.pub（公開鍵）が生成される。公開鍵を接続先サーバーの ~/.ssh/authorized_keys に追記すれば、すぐに利用可能になる。RSA鍵を残しておきたい場合も問題なく共存でき、SSHクライアントは自動的に適切な鍵を選択する。

接続先ごとに鍵を明示的に切り替えたい場合は、~/.ssh/config に以下を記述する。

Host myserver
 HostName example.com
 User username
 IdentityFile ~/.ssh/id_ed25519

どの鍵が使用されているか確認するには、次のように実行する。

ssh -v myserver

ログに Offering public key: /home/you/.ssh/id_ed25519 と表示されれば、Ed25519鍵が使われている。

まとめ

Ed25519は、RSAと比較して速度・安全性・実装の簡潔さの点で優れている。とはいえ、RSAも現状では十分な安全性を維持しており、量子計算機が登場するまではどちらも有効である。結局のところ、SSHで困らない範囲ではどちらを選んでもよいが、これから新しく鍵を作るならEd25519が自然な選択である。

ARPを使ってネットワーク内の特定機器のIPアドレスを効率的に見つける方法

Sun, 21 Sep 2025 21:11:22 +0900

ネットワーク管理において、特定の機器のIPアドレスを素早く特定する必要がある場面は多い。特にMACアドレスは分かっているが、DHCPによって動的にIPアドレスが割り当てられている環境では、従来のIPアドレス総当たり方式では非効率である。このような状況でARP（Address Resolution Protocol）テーブルを活用することで、効率的に目的の機器を発見できる。

ARPは、同一ネットワークセグメント内でIPアドレスとMACアドレスの対応関係を管理するプロトコルである。ネットワーク通信が発生する際、OSは自動的にARPテーブルを更新し、最近通信した機器の情報を保持している。この仕組みを利用することで、ネットワーク全体をスキャンした後、ARPテーブルから目的のMACアドレスを持つ機器のIPアドレスを直接抽出できる。

実行環境と前提条件

本記事の手順はmacOS、Linux、Windowsの各環境で実行可能である。ただし、一部のコマンドには管理者権限が必要となる。また、対象機器は同一ネットワークセグメント内に存在し、ファイアウォール等でICMPパケット（ping）をブロックしていないことが前提となる。

基本的なARP発見手順

最も基本的な手順は、まずネットワーク全体に対してping応答を送信し、その結果生成されるARPテーブルから目的の機器を抽出する方法である。

# ネットワーク全体の生存確認
nmap -sn 192.168.1.0/24

# ARPテーブルから特定MACアドレスを検索
arp -a | grep "b8:27:eb"

上記の例では、192.168.1.0/24のネットワークレンジに対してping応答確認を実行し、その後ARPテーブルからb8:27:ebで始まるMACアドレスを検索している。nmap -snオプションは、ポートスキャンを実行せずにホストの生存確認のみを行うため、処理が高速である。

nmapが利用できない環境では、標準的なpingコマンドを使用したスクリプトでも代替可能である：

for i in {1..254}; do
 ping -c 1 -W 1 192.168.1.$i >/dev/null 2>&1 &
done
wait
arp -a | grep "b8:27:eb"

このスクリプトでは、IPアドレスの範囲を並行処理でpingし、完了後にARPテーブルを確認している。ただし、処理時間の観点からnmapの使用が推奨される。

arp-scanツールを使用した高速検出

より確実で高速な検出を実現するには、専用ツールであるarp-scanの使用が効果的である。arp-scanは、ARPリクエストを直接送信するため、pingに応答しない機器でもMACアドレスベースでの検出が可能である。

macOSでのインストール：

brew install arp-scan

Linux（Ubuntu/Debian）でのインストール：

sudo apt install arp-scan

基本的な使用方法：

# ローカルネットワーク全体をスキャン
sudo arp-scan --local | grep "b8:27:eb"

# 特定のネットワークレンジを指定
sudo arp-scan 192.168.1.0/24 | grep "b8:27:eb"

arp-scanの利点は、ICMPパケット（ping）がブロックされている環境でも動作することである。ARPは同一セグメント内での通信に必須のプロトコルであるため、通常のファイアウォール設定でブロックされることは稀である。また、arp-scanは結果を構造化された形式で出力するため、スクリプト処理にも適している。

Raspberry Pi機器の特定における実践的応用

Raspberry Piを例とした具体的な応用例を示す。Raspberry Piは、製造時期やモデルによって異なるMACアドレスプリフィックスを使用している。

主要なRaspberry PiのMACアドレスプリフィックス：

b8:27:eb - 初期のRaspberry Pi（Pi 1, 2, 3の初期モデル）
dc:a6:32 - 新しいRaspberry Pi（Pi 3後期モデル以降、Pi 4、Pi Zero 2W等）
e4:5f:01 - 一部のPi 4モデル
d8:3a:dd - 最新の一部モデル

複数のプリフィックスを同時に検索する場合：

sudo arp-scan --local | grep -E "(b8:27:eb|dc:a6:32|e4:5f:01|d8:3a:dd)"

実際の出力例：

192.168.1.105 b8:27:eb:12:34:56 Raspberry Pi Trading Ltd
192.168.1.108 dc:a6:32:78:9a:bc Raspberry Pi Trading Ltd

この結果から、192.168.1.105と192.168.1.108にRaspberry Pi機器が存在することが確認できる。さらに詳細な情報が必要な場合は、検出されたIPアドレスに対してSSH接続やWebブラウザでのアクセスを試行することで、具体的なサービス内容を確認できる。

トラブルシューティングとパフォーマンス最適化

ARPテーブルベースの検出で問題が発生する場合の対処法について説明する。最も一般的な問題は、ARPテーブルエントリの有効期限切れである。多くのOSでは、ARPエントリは数分から数十分で自動的に削除される。そのため、スキャン実行から時間が経過した後にARPテーブルを確認しても、目的の機器が見つからない場合がある。

この問題を回避するには、スキャンとARPテーブル確認を連続して実行する必要がある：

nmap -sn 192.168.1.0/24 && arp -a | grep "target_mac_prefix"

また、一部の機器はICMPパケットをブロックしている場合がある。このような環境では、arp-scanの使用が必須となる。arp-scanでも検出できない場合は、対象機器のネットワーク設定やファイアウォール設定を確認する必要がある。

パフォーマンスを向上させるには、nmapの並行処理オプションを調整できる：

nmap -sn -T5 --min-parallelism 100 192.168.1.0/24

ただし、過度な並行処理は、ネットワーク機器に負荷をかける可能性があるため、環境に応じて適切な値を設定することが重要である。

セキュリティ考慮事項と運用上の注意点

ARPスキャンは、ネットワーク上のすべての機器に対してパケットを送信するため、ネットワーク管理者の許可なく実行すべきではない。企業環境や公共のネットワークでは、事前に適切な許可を取得することが必要である。

また、頻繁なARPスキャンは、ネットワーク監視システムによって異常なトラフィックとして検出される可能性がある。定期的な機器発見が必要な場合は、スキャン間隔を適切に調整し、ネットワーク負荷を最小限に抑える運用を心がけることが重要である。

検出された機器への不正アクセスは法的な問題を引き起こす可能性があるため、発見した機器に対するアクセスは、適切な権限を持つ範囲内でのみ実行するべきである。特にSSHやWebサービスへのアクセス試行は、正当な理由と適切な権限なしに実行してはならない。

ghqでLAN内のプライベートGiteaサーバーのリポジトリを/etc/hostsで定義したドメインで管理する設定方法

Tue, 16 Sep 2025 02:15:07 +0900

プライベートGiteaサーバーとghqを連携させることで、自宅のリポジトリ管理を効率化できる。この記事では、ローカルネットワーク上のGiteaサーバーをghqで管理するための設定手順を記録する。

検証環境

macOS（ghq導入済み）
Giteaサーバー：192.168.0.100（HTTPSなし、SSH接続可能）
対象リポジトリ：user@192.168.0.100:org/repository.git

hostsファイルによるエイリアス設定

プライベートサーバーにわかりやすい名前を付けるため、/etc/hostsでエイリアスを設定する。これにより、IPアドレスではなく意味のあるドメイン名でリポジトリにアクセスできるようになる。

sudo vi /etc/hosts

以下の行を追加する：

192.168.0.100 code.example.com

この設定により、192.168.0.100への接続がcode.example.comとして扱われる。ドメイン名を使うことで、後からサーバーのIPアドレスが変更されても設定変更が容易になるメリットがある。

ghqでのHTTPS接続エラーとその対処

初回のghq実行では、HTTPSでの接続エラーが発生する場合がある。これは、プライベートGiteaサーバーでHTTPS証明書が設定されていないことが原因である。

$ ghq get code.example.com/org/repository.git
error failed to get "code.example.com/org/repository.git": unsupported VCS, url=https://code.example.com/org/repository.git: Get "https://code.example.com/org/repository.git?go-get=1": dial tcp 192.168.0.8:443: connect: connection refused

このエラーメッセージから、ghqがデフォルトでHTTPS（ポート443）での接続を試行していることがわかる。プライベートサーバーではHTTPS設定を行わないことが多いため、SSHまたはHTTPでの接続に切り替える必要がある。

gitconfigによるプロトコル変換設定

最も効率的な解決方法は、Gitの設定でプロトコル変換を行うことである。~/.gitconfigに以下の設定を追加することで、HTTPSのURLが自動的にSSHに変換される。

[ghq]
 vcs = git
[url "ssh://code.example.com/"]
 insteadOf = https://code.example.com/

この設定のurl.insteadOfは、Gitが特定のURLパターンを別のURLに自動変換する機能である。https://code.example.com/で始まるURLがssh://code.example.com/に置き換えられるため、HTTPSでアクセスしようとしても実際にはSSH接続が行われる。

設定後は、HTTPSのURLを指定してもSSHで接続されるようになる：

$ ghq get code.example.com/org/repository.git
 clone ssh://code.example.com/org/repository.git -> /Users/username/ghq/code.example.com/org/repository

リポジトリの配置とアクセス

ghqによってクローンされたリポジトリは、以下のパスに配置される：

~/ghq/code.example.com/org/repository/

この階層構造により、複数のGitサーバーやオーガニゼーションのリポジトリを整理して管理できる。ghqは常にホスト名/ユーザー名またはオーガニゼーション名/リポジトリ名の形式でディレクトリを作成するため、リポジトリの所在が明確になる。

日常的な操作では、以下のコマンドが有用である：

# 管理しているリポジトリ一覧の表示
ghq list

# リポジトリの完全パス表示
ghq list --full-path

# 特定リポジトリへの移動
cd $(ghq root)/code.example.com/org/repository

まとめ

プライベートGiteaサーバーとghqの連携において、/etc/hostsによるエイリアス設定と.gitconfigでのプロトコル変換設定を組み合わせることで、効率的なリポジトリ管理環境を構築できる。特に.gitconfigのurl.insteadOf設定により、HTTPSとSSHの違いを意識することなく、統一されたURLでリポジトリにアクセスできるようになることが重要である。この設定により、プライベート開発環境でのリポジトリ管理が大幅に改善される。

VSCodeでリモートサーバーのコードをSSH経由で編集する方法

Wed, 20 Nov 2024 16:36:45 +0900

リモートサーバー上のコードをVSCodeで直接編集したいとき、「Remote - SSH」拡張機能を使えば簡単に設定できます。この記事では、その手順を初心者向けにわかりやすく解説します。

📌 前提条件

VSCodeがインストールされていること。
SSHでリモートサーバーにアクセスできること（公開鍵認証またはパスワード認証）。
インターネット接続があること。

📖 手順

1. 「Remote - SSH」拡張機能をインストール

VSCodeを起動します。
左側の「拡張機能」アイコン（四角が飛び出すマーク）をクリックします。
検索バーに「Remote - SSH」と入力。
Microsoft製の「Remote - SSH」拡張機能をインストールします。

2. SSH設定ファイルの準備

SSH接続には、~/.ssh/configファイルを使用します。この設定ファイルでリモートサーバーへの接続を定義します。

ターミナルを開き、以下のコマンドを実行して設定ファイルを作成または編集します:

nano ~/.ssh/config

以下のように、リモートサーバーの情報を記述します:

Host my-remote-server
 HostName 192.168.1.100 # サーバーのIPまたはホスト名
 User my-username # リモートサーバーのユーザー名
 IdentityFile ~/.ssh/id_rsa # SSH鍵のパス（鍵認証を使用する場合）

ファイルを保存して閉じます。

💡 ヒント: Hostの値（例: my-remote-server）は任意の名前でOK。後で接続時にこの名前を使用します。

3. リモートサーバーに接続

VSCode左下の緑色の「リモートアイコン」をクリック。
「Connect to Host」を選択。
先ほど設定したエイリアス名（例: my-remote-server）を選択。
初回接続時に「このホストのSSHキーを信頼するか」と聞かれるので「Yes」を選択。

リモートサーバーに接続されると、VSCodeのウィンドウが再起動し、リモート環境として動作します。

4. リモートフォルダを開く

接続後、リモートサーバー上の作業ディレクトリを開きます。

左側のエクスプローラーで「Open Folder」をクリック。
リモートサーバー上のディレクトリ（例: /home/my-username/project）を選択。

これで、リモートサーバー上のコードがVSCodeで編集可能になります！

5. リモート環境での開発

リモート環境に必要な拡張機能（例: Python、Node.js関連）をインストールする際は、「Install in SSH: [Host名]」を選択してください。
ターミナルを開くには、Ctrl +（バッククォート） ``を押します。リモートサーバーのターミナルが利用できます。

🛠 トラブルシューティング

Q1. SSH接続エラーが発生する

SSH設定ファイル（~/.ssh/config）の記述を再確認。
ターミナルで以下を実行してSSH接続が可能か確認:

ssh my-remote-server

Q2. 拡張機能がインストールされない

拡張機能画面で「Install in SSH」を選択しているか確認。

Q3. 権限エラーが発生

リモートサーバー上のファイル・フォルダの権限設定を確認します:

chmod -R u+w /path/to/directory

これで、リモートサーバーでの開発作業が快適になるはずです！
VSCodeと「Remote - SSH」を使って、効率的なリモート開発を楽しんでください。

ディレクトリベースで複数のGitHubアカウントを管理する方法

Thu, 04 Jul 2024 18:56:23 +0900

この記事では、個人用と仕事用のGitHubアカウントを、プロジェクトディレクトリごとに自動的に切り替えて使用する方法を詳しく解説します。具体的には、~/projects/personal ディレクトリ下のプロジェクトでは個人のGitHubアカウントを使用し、~/projects/work ディレクトリ下では仕事用のアカウントを使用する状況を想定します。コマンドラインでのGit操作だけでなく、VSCodeなどのIDEでも適用されるようにします。

前提条件

Gitの基本的な知識があること。
アカウントごとにSSHキーを生成しており、それぞれのGitHubアカウントに登録していること。
基本的なGit操作に慣れていること。
Git 2.13以降であること。

Git設定の基本

.gitconfigファイルはGitの設定を管理するための中心的なファイルで、ユーザ名やメールアドレス、エイリアス、スクリプトの実行設定などを含みます。全体的なユーザー設定（グローバル設定）は通常、ユーザのホームディレクトリに位置する.gitconfigファイルに記述されます。

ディレクトリごとのGit設定

Git 2.13以上では、includeIfディレクティブを使用して、特定のディレクトリに基づいてGit設定を動的に適用することができます。これを利用して、異なるプロジェクトディレクトリで異なるGitHubアカウントを使い分ける設定を行います。

基本的な`.gitconfig`設定

ホームディレクトリの.gitconfigに以下の設定を追加します。

[user]
 name = default_name
 email = default_email@example.com

[includeIf "gitdir:~/projects/personal/"]
 path = ~/.gitconfig-personal
[includeIf "gitdir:~/projects/work/"]
 path = ~/.gitconfig-work

各ディレクトリ用の`.gitconfig`ファイル

~/.gitconfig-personalファイルには次のように記述します：

[user]
 name = personal_username
 email = personal_email@example.com
[core]
 sshCommand = "ssh -i ~/.ssh/id_rsa_personal -F /dev/null"

~/.gitconfig-workファイルには次のように記述します：

[user]
 name = work_username
 email = work_email@example.com
[core]
 sshCommand = "ssh -i ~/.ssh/id_rsa_work -F /dev/null"

まとめ

ディレクトリベースでGitHubアカウントを管理することで、複数のアカウントを効率的かつ安全に運用することが可能です。設定は初めに少し時間がかかりますが、一度設定してしまえば、その後は自動で適切なアカウントが使用されるため、非常に便利です。

ネットワーク技術 on AIによる技術記事 備忘録