ssh forwarding

ちょっとsshを利用したポートフォワーディングについても、調べておく。

sshポートフォワーディングの使い方

ssh接続のポートフォワーディングは3種類ある！

SSHポートフォワード：OpenSSH の -L と -R オプションの動作を図解

Windows10 でも簡単にsshdがインストールできるけど、設定は何処にあるのとかファイアーウォールに穴を開けるとか、面倒で躊躇しちゃうぞ。

上の例に出てたncを利用した通信事例。ホスト間は、sshで暗号化されている。サーバー側をfbに、クライアント側をobとして実験してみる。

server sideで、ncのサーバー(受け)をたてる。

sakae@fb:~ $ nc -4 -kl 11111

client sideで、フォワーディングしつつ、サーバーにログイン。単に暗号路を確保する為だ

ob$ ssh -L 22222:fb:11111 fb
(sakae@fb) Password for sakae@fb:

Welcome to FreeBSD!

sakae@fb:~ $

クライアントからssh経由(暗号路にデータを載せる)で、サーバー側に送信。

ob$ nc -4 localhost 22222
12345

この時のサーバー側

sakae@fb:~ $ netstat -f inet
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 fb.11111               fb.64578               ESTABLISHED
tcp4       0      0 fb.64578               fb.11111               ESTABLISHED
tcp4       0      0 fb.ssh                 ob.16058               ESTABLISHED

クライアント側

ob$ netstat -f inet
Active Internet connections
Proto   Recv-Q Send-Q  Local Address          Foreign Address        TCP-State
tcp          0      0  localhost.41277        localhost.22222        ESTABLISHED
tcp          0      0  localhost.22222        localhost.41277        ESTABLISHED
tcp          0      0  ob.16058               fb.ssh                 ESTABLISHED

暗号路が必要なければ、直接サーバー側のncに接続すれば良い。

ob$ nc -4 fb 11111

ただし、事前にsshを停止し、ncは再起動しておく事。

X11-forwarding

X Windowの利用について科学技術計算システムを利用するには?

WSL上にXサーバをインストールしてGUIを実現する（VcXsrv編）

OpenBSDからFreeBSDにsshして、FreeBSD側のXを使ってみる。って、何もないので、pkg install xorgしたよ。そしたら、llvm15まで、侵入してきたぞ。 xorgってメタパッケージなんだな。おかげでfirefoxを入れる余裕がなくなった。しょうがないので、アプリの代表として、xtermでお茶を濁すことにした。

fb側で、export DISPLAY=ob:0 して、表示には、OpenBSDのXを利用してねって設定を行ない。そして、

ob$ ssh -XY fb xterm

これでOpenBSD側に、FreeBSD由来のxtermが表示された(つくづく、firefoxじゃないのが残念であります)。この時の接続状況。

sakae@fb:~ $ netstat -f inet
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 localhost.x11-ssh      localhost.41989        ESTABLISHED
tcp4       0      0 localhost.41989        localhost.6010         ESTABLISHED
tcp4       0      0 fb.ssh                 ob.6404                ESTABLISHED

psすれば、ちゃんとxtermは存在するけど、その姿形は、OpenBSD上に表われている。x11-sshってのが表示されているけど、これは、6010の事だ。なんで、表示がちぐはぐ？そりゃ、ローカル側は、自分で把握できるけど、外部側の事は、よう知らんわって主張なんだろね。

sakae@fb:~ $ grep x11 /etc/services
x11             6000/tcp   #6000-6063 are assigned to X Window System
x11             6000/udp   #X Window System
x11-ssh         6010/tcp   #Unofficial name, for convenience
x11-ssh         6010/udp

FreeBSDだと/usr/src/crypto/openssh こんな所に鎮座してる。*.cだけで、軽く11万行を越える巨大なやつだ。隣には、opensslが鎮座してた。

OpenBSDなら、/usr/src/usr.bin/ssh に、族が集結している。やはり巨大で10 万行を越えてた。ソースをちら見すると、debug printが強い見方になりそうなので、、

ob$ ssh -vv -X fb xterm
OpenSSH_9.7, LibreSSL 3.9.0
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "fb" port 22
debug1: Connecting to fb [xx.xx.xx.xx] port 22.
 :
debug2: client_x11_get_proto: xauth command: /usr/X11R6/bin/xauth -f /tmp/ssh-9d
GSLghUwNbs/xauthfile generate :0 MIT-MAGIC-COOKIE-1 untrusted timeout 1260 2>/dev/null
debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-9dGSLghUwNbs/xauthfile list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending command: xterm
debug2: channel 0: request exec confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
 :
debug2: X11 forwarding request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 19945
debug2: fd 7 setting O_NONBLOCK
debug1: channel 1: new x11-connection [x11] (inactive timeout: 0)
debug1: confirm x11
debug2: channel 1: rcvd adjust 65536
 :
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 1
Transferred: sent 3248232, received 58552 bytes, in 26.3 seconds
Bytes per second: sent 123601.0, received 2228.0
debug1: Exit status 0

xauth

なんだか、xauth なんてのが出てたので調べてみる。

Xのウィンドウで別のデスクトップを表示するには

WSL2からアクセス制御(Xauthority)を有効にしたX Serverに接続する

Q: X11-forwardingする時に利用されるマジッククッキーは、どんな目的で利用されるのですか？

A: X11-forwardingで利用される「マジッククッキー」は、セキュリティのために使われます。具体的には、以下の目的で利用されます：

認証: マジッククッキーは、一意の認証トークンとして機能します。Xサーバーに接続しようとするクライアントは、正しいマジッククッキーを持っている必要があります。これにより、不正なクライアントがXサーバーに接続するのを防ぎます。
アクセス制御: Xサーバーは、接続を許可するかどうかを決定する際にマジッククッキーをチェックします。クライアントが提供するマジッククッキーがXサーバーの設定と一致しない場合、そのクライアントの接続は拒否されます。これにより、信頼できるクライアントのみがXサーバーに接続できるようになります。
通信の保護: X11-forwardingを利用する際、SSHプロトコルを使ってX11データを暗号化して送信しますが、マジッククッキーは通信の開始時にクライアントを認証するために使われます。これにより、セッション中にクライアントの正当性が確保されます。

このように、マジッククッキーはX11-forwardingにおける重要なセキュリティ機構の一部として機能し、クライアントの認証とアクセス制御を行うために利用されます。

Q: 誰がこのクッキーを作成してくれるのですか？

A: マジッククッキーは通常、以下のプロセスを通じて作成されます：

Xサーバーの起動時: ローカルでXサーバーを起動する際、Xサーバー自身がマジッククッキーを生成します。これは一般的に`~/.Xauthority`ファイルに保存されます。このファイルには、Xサーバーに接続するために必要な認証情報が含まれています。
SSHサーバー: X11-forwardingを利用する場合、リモートのSSHサーバーがローカルのXサーバーからマジッククッキーをコピーし、リモート環境に適用します。このプロセスは通常、SSHクライアントによって自動的に行われます。
- SSHクライアントが接続されると、リモートの環境にマジッククッキーが設定され、クライアントがリモートXサーバーに対して認証を行えるようにします。
- このクッキーは一時的にSSHセッションの間だけ使用されます。SSH接続が終了すると、クッキーは無効になります。

### 具体的な流れ

ローカルでの生成: Xサーバーが起動すると、`xauth`ツールを使ってマジッククッキーが生成されます。

xauth generate :0 . trusted
リモートへの転送: SSH接続時に、SSHクライアントがローカルのマジッククッキーをリモートにコピーします。

ssh -X user@remotehost
リモートでの利用: リモートマシン上で`DISPLAY`環境変数が設定され、リモートアプリケーションがローカルのXサーバーに接続できるようになります。

このようにして、マジッククッキーは自動的に生成され、必要な場所に転送されます。通常、ユーザーが手動で行う必要はなく、SSHクライアントとXサーバーがその役割を果たします。

GPT-4o が利用できると言う大盤振舞いが来てたので、切り替えてみた。

A': X11マジッククッキーは通常、Xサーバーの設定時に自動的に生成されます。具体的な生成と管理は以下のように行われます：

Xサーバーの起動時: Xサーバー（通常は`Xorg`や`XFree86`など）は起動時にマジッククッキーを生成します。このクッキーはランダムなバイト列であり、一意性が保証されます。
`xauth`コマンド: クライアント側で認証情報を管理するために、`xauth`コマンドが使われます。`xauth`コマンドは、認証情報（マジッククッキー）をユーザーの`~/.Xauthority`ファイルに保存します。これにより、クライアントはXサーバーに接続する際に適切な認証情報を提供できます。
SSHのX11-forwarding: SSHを使ってX11-forwardingを行う場合、SSHサーバーが接続時に一時的なマジッククッキーを生成し、それをクライアントに提供します。この一時的なマジッククッキーは、SSH接続が終了すると無効になります。

### 手順の例

Xサーバーの起動:

startx

または

systemctl start display-manager

`xauth`による管理:
- クッキーのリスト表示:
  
  xauth list
- クッキーの追加:
  
  xauth add <displayname> . <hexkey>
- クッキーの削除:
  
  xauth remove <displayname>

SSH経由のX11-forwarding:
- SSH接続時にX11-forwardingを有効にする:
  
  ssh -X user@remote_host
  
  この時、SSHサーバーが一時的なマジッククッキーを生成してクライアントに渡します。

### まとめ

X11マジッククッキーは、Xサーバー起動時や`xauth`コマンド、またはSSH接続時に自動的に生成されます。これにより、ユーザーは特別な操作をしなくても安全にX11-forwardingを利用できます。

ためしてみた。

ob$ xauth list
ob.my.domain/unix:0  MIT-MAGIC-COOKIE-1  faed9de84eb3bdfd1cc91b0123456789
ob.my.domain:0  MIT-MAGIC-COOKIE-1  faed9de84eb3bdfd1cc91b0123456789

WSL2/Debianへssh

無駄と言えば無駄だけど、やってみる。DebianはNATの中だけど、外側 (Windows)からssh接続できる。その準備として、debianでsshdを起動しとくのが前提になる。

Windows側からlocalhost:22へ接続すると、ポートフォワーディングされて、 debianに入いれる。挙動としては、ポートフォワーディングと言うより(IP)アドレス変換だな。localhostを変動する172.21.xx.xxに自動変換して、接続してくれる。Windows側でのOpenSSHはMSが用意してくれているので、簡単な操作でイネーブルに出来る。至れり尽くせずな準備がされているぞ。

この時に使うのは、慣れたPuTTYだ。このPuTTYの設定で、ssh/x11の所にあるX 転送をonにしておくと、VcXsv X Serverが利用出きる。

Windowsのポートプロキシを使った接続

UbuntuをWindows11上で動かすその12: 外部から接続する

またまたMSの大発明(名前だけ)です。さて、ポートフォワーディングと何が違うのでしょう？

etc

ImageFlux Live StreamingでAIアシスタントを作ってみた

VMware製品「OEM廃止」の衝撃、ブロードコムはNECなど国産勢を切り捨て

気紛れで将来VMWareが公開されなくなった時の逃げを模索しておくか。WSLが候補になるけど、 WSL2のUbuntu 22.04.3 LTSにリモートデスクトップ接続する。（その３：ブリッジ接続）によると、Windows11 Proだけみたい。 Windows11 Homeで仮想環境（Hyper-V）を作成する方法こんなの有った。

ChatGPT

朝5時頃は曇っていて、10時ぐらいにスーパーへ行っても大丈夫、日焼けしないかなと思っていると、何時も裏切られる。気象予報士もどききに聞いてみたぞ。

Q: 日中は晴れることが多いのに、朝は曇りがちです。何故ですか？

A: 朝が曇りがちな理由はいくつかあります。以下に主要な理由を挙げます。

地表の冷却: 夜間は地表が放射冷却によって冷えます。これにより地表付近の空気も冷やされ、相対的に湿度が高まります。冷えた空気が露点に達すると、水蒸気が凝結して霧や低い雲が発生しやすくなります。
風の影響: 夜間や早朝は風が弱くなりがちです。これにより大気の混合が少なく、地表付近の湿った空気がそのまま残りやすくなります。これも霧や雲の形成を助けます。
放射霧: 晴れた夜は放射冷却が強くなりやすく、その結果として放射霧が発生することがあります。放射霧は朝日が昇るにつれて消散しますが、朝のうちはまだ残っていることが多いです。
海風の影響: 海に近い地域では、夜間に冷えた空気が海上に流れ込み、朝方に海風として戻ってくることがあります。この風が冷たく湿った空気を運び、曇りや霧を引き起こすことがあります。

これらの要因が組み合わさることで、日中が晴れていても、朝が曇りがちになることが多いのです。

README

バッタを倒すぜ　アフリカで

著者は、前野ウルド浩太郎博士。日本人には珍しくミドルネームをお持ち。モーリタリアから贈呈されたとか。なんでも、◯◯の子孫と言う意味らしい。

大量発生して、全ての緑を食べつくしてしまうやっかいなバッタ。これが発生してるアフリカに渡る著者。ある時、そのバッタの婚活現場に運よく遭遇。

不思議な事に、その男女比率が1:1に近い事を発見。何故そうなる？普通は男の方が多くて、比率は異るはずだろう。

仮説を立てる。成熟するまで、男女は別居して生活してるんではなかろうか？そして、発展場所に集合すれば、ほぼ全員がペアになれるという、効率よい繁殖戦略をとっているんではなかろうか？

ある時、論文集を眺めていたら、そういう形態が普通らしい事を知る。教科書で習ったはずなんだけど、すっかり忘却の彼方だったらしい。

ここから、色々とアイデアが湧いてきて、地道な観測と、実験が始まる。研究者って、こういう風に悩んで手を動かして、その成果を論文にするんだなあ。その一端をかい間みられて、とっても楽しかったよ。それにコボレ話もふんだんに盛りこまれていて、飽きないぞ。

This year's Index

Home

ssh forwarding

Table of Contents

init

qemu

ssh forwarding

X11-forwarding

xauth

WSL2/Debianへssh

Windowsのポートプロキシを使った接続

etc

ChatGPT

README