穿越 Firewall 的作法

先看到「SSH over HTTPS (trofi.github.io)」這篇,原文「SSH over HTTPS」講怎麼利用 HTTPS 加上 CONNECT 指令穿過去。

作者有先介紹背景,他需要在醫院待個幾天,而醫院有免費的 WiFi 可以上網,但限制很多,基本上 TCP 的部分只有 80/tcp 與 443/tcp 會通,另外他有行動網路可以用 (但應該不是吃到飽的?),可以當作在現場直接設定 bypass 機制的工具:

I planned to spend 1-2 days in the hospital and did not plan to use the laptop.But now I am stuck here for the past two weeks and would like to tinker on small stuff remotely. The hospital has free Wi-fi access.

The caveat is that hospital blocks most connection types. It allows you only to do HTTP (TCP port 80) and HTTPS (TCP port 443) connections for most hosts. DNS (UDP port 53) and DoT (TCP port 853) seem to work as well at least for well-known DNS providers.

But SSH (TCP port 22 or most other custom ports) is blocked completely.

I wondered how hard would it be to pass SSH through HTTP or HTTPS. I had a GSM fallback so I could reconfigure remote server and try various solutions.

作者的方法就是在 TLS/SSL connection 上面跑 SSH,以前幹過,但就如同 comment 裡面提到的,Cisco 的 AnyConnect (主要是用 open-source client 的 OpenConnect 以及 open-source server 的 ocserv) 比較彈性,而且 AnyConnect 的協定會自動嘗試 UDP-based 的 DTLS,傳輸效率會比 TCP-based 的協定好,另外在 iOS 上可以直接裝 app store 裡面 Cisco 官方的 client 來用。

但從作者的其他文章看起來應該也是熟門熟路了,會這樣做應該是手上有 HTTPS 的 apache server 可以設定來用。

另外作者雖然沒寫出來,但想法應該是有 SSH 就可以在 command line 透過 -D 生出 SOCKS 服務當 proxy 讓其他程式使用,常見的應用程式大多都支援。

應該就是臨時要在醫院裡面待個一兩天時的暫時性方案,如果常態會遇到的話應該是會架 ocserv 來繞...

scp -3:直接對兩個 remote host 複製檔案

剛剛找資料才發現的,scp 指令早就可以針對兩個遠端複製檔案了:「scp from one remote server to another remote server」。

可以加上 -3,像是這樣:

scp -3 src:/foo/bar/a.zip dst:/tmp/

不過依照說明可以不用加,因為這是 default 值:

Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that, when using the legacy SCP protocol (via the -O flag), this option selects batch mode for the second host as scp cannot ask for passwords or passphrases for both hosts. This mode is the default.

看了 Stack Exchange 上的回答日期,是 2014 年十月回的,所以至少 Ubuntu 16.04 就有這個功能了?(沒有去查這個功能多早...)

之前一直都是查怎麼用 rsync 搬,然後發現做不到所以都還是傻傻的透過 jump server 轉運檔案,沒想到隔壁棚早就給了解法...


OpenSSH 加入了 noise (keystroke timing obfuscation) 功能

Hacker News 上看到在 OpenSSH 裡加入 keystroke timing obfuscation 的功能:「Keystroke timing obfuscation added to ssh(1) (undeadly.org)」。

如同 commit log 裡面提到的,這個功能會想要故意沒事就送一些沒用的資料 (增加一些噪音),降低從 side channel 被判讀的資訊量:

This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword/

基於 OpenSSH 算是 SSH 這塊的 de-factor standard 了,接下來看其他家像是 Dropbear 會不會也實作?

SSH 的各種好用的功能

在「An Excruciatingly Detailed Guide To SSH (But Only The Things I Actually Find Useful)」這篇看到在介紹 SSH 的各種好用的功能。

其中當然會提到 tunnel,這部份裡面提到了一張圖,原始文章是「A Visual Guide to SSH Tunnels: Local and Remote Port Forwarding」這邊,圖解 SSH tunnel 的功能 (不過只有 -L-R 的):

回到原來這篇文章,這篇講的東西比較多一點,關於 tunnel 相關的還包括了 -D-J

另外提到了 -A-t-g~? 的用法,以及其他各種跟 SSH 有關的工具。

翻了一輪後應該就 -g 還不熟,另外發現 -J (ProxyJump) 居然可以用逗號 , 指定一串跳板機,一路跳進去... 翻了 manpage 發現有寫:

Multiple jump hops may be specified separated by comma characters.

Tailscale SSH 可以啟動側錄功能

Tailscale 宣布 Tailscale SSH 可以側錄:「Announcing session recording for Tailscale SSH in beta」,這主要是對於 compliance 需求會有幫助,以前有類似需求的話會透過 jump server 類的方式來側錄...

這次提供的是 asciinema 格式,很容易可以 replay:

When a member of your tailnet initiates a connection over Tailscale SSH, our client on the server records all of the terminal output in asciinema format, and streams it to a dedicated recorder node on your tailnet.


Session recording for Tailscale SSH is available in beta on our Free and Enterprise plans.

舊的 SSH session logging 則是宣布在八月會停掉:

This feature replaces a legacy version of local SSH session logging that saves recordings directly to the SSH server’s filesystem. We are deprecating that feature, and anyone using it should migrate to the new SSH session recording feature. The legacy functionality will remain active until at least August 1, 2023.

Hacker News 的討論「Session recording for Tailscale SSH in beta (tailscale.com)」裡面有一些有趣的東西,像是 sudo 也有提供類似的功能:「Sudoreplay」。

之前有遇過一些商用方案,有提供類似的功能,像是 CyberArk 的「Configure recordings and audits (PSM for SSH)」。

另外 2016 年時 AWS 的人也有寫過「How to Record SSH Sessions Established Through a Bastion Host」。

算是稽核上常見的需求,先前就有不少方法了,Tailscale 提供的工具等於是簡化了一些步驟。

OpenSSH 與 Dropbear 對 Ed25519 的支援

查了一下這兩個 server 端的軟體支援 Ed25519 的時間點。

OpenSSH 是在 2014/01/30 的 6.5 就支援了:

* ssh(1), sshd(8): Add support for Ed25519 as a public key type. Ed25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys.

算是相當久以前就支援了。對應到第一個支援的 Debian 版本是 Jessie 使用的 OpenSSH 6.7:「sshd(8) — openssh-server — Debian jessie — Debian Manpages」;第一個支援的 Ubuntu (LTS) 版本是 Trusty (14.04) 用的 OpenSSH 6.6:「openssh source package in Trusty」。

Dropbear 這邊就晚不少,在 2020/06/15 的 2020.79 版本才支援:

- Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav Grishenko. This also replaces curve25519 with a TweetNaCl implementation that reduces code size.

所以對應到第一個支援的 Debian 版本是 Bullseye 的 2020.81:「Debian -- Details of package dropbear in bullseye」;第一個支援 Ubuntu (LTS) 的版本是 Jammy (22.04) 的 2020.81:「Ubuntu – Details of package dropbear in jammy」。

這樣看起來如果就是想要用 Ed25519 的話,變成 server 端的軟體得配合:預設裝的 sshd 應該都是 OpenSSH,如果想要換 Dropbear 的話要看 distribution 內給的版本夠不夠新,或是透過 PPA 之類的方法裝新版。

但大多數採用 BusyBox 的機器應該沒有採用新版 Dropbear (像是 AP 刷機),這邊還是得使用其他 key format,如果要避開 NIST 有介入的格式,就還是得用 ssh-rsa 了。

GitHub 更換 github.com 的 SSH host key (RSA 部份)

看到 GitHub 宣佈更換 SSH key (RSA 的部份):「We updated our RSA SSH host key」。

Hacker News 上的「We updated our RSA SSH host key (github.blog)」這邊有人提到官方文件 (原文裡面也有提到),裡面會列出對應的 key:「GitHub's SSH key fingerprints」。

只是看起來這些大公司依然對 DNSSEC + SSHFP 這樣的組合沒興趣...

OpenSSH 9.0 的 scp 與 sntrup761x25519 (Streamlined NTRU Prime)

OpenSSH 9.0 發行了,從 release-9.0 這邊可以看到重點,首先是 scp 的底層換掉,改用 SFTP 了,這點在先前「OpenSSH 的 scp 改用 SFTP 協定」這邊也有提到過:

This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default.

另外一個是將 OpenSSH 8.9 引入的 post-quantum cipher 放入 default:

ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default ("sntrup761x25519-sha512@openssh.com"). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo.

We are making this change now (i.e. ahead of cryptographically-relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.

查了一下 Streamlined NTRU Prime 發現有 djb 參與,而且發現頭銜上面有掛中研院:

Daniel J. Bernstein, University of Illinois at Chicago, USA, and Ruhr University Bochum, Germany, and Academia Sinica, Taiwan


Ming-Shing Chen, Academia Sinica, Taiwan

Bo-Yuan Peng, National Taiwan University and Academia Sinica, Taiwan


Bo-Yin Yang, Academia Sinica, Taiwan


Taiwanese authors were supported by Taiwan Ministry of Science and Technology Grants 108-2221-E-001-008 and 109-2221-E-001-009-MY3, Sinica Investigator Award AS-IA-109-M01, Executive Yuan Data Safety and Talent Cultivation Project (AS-KPQ-109-DSTCP).

Cloudflare 預定推出 SSH command logging 功能

Cloudflare 預定要推出 SSH command logging 功能:「Introducing SSH command logging」。

看起來是 Cloudflare Zero Trust 產品線:

We’re excited to announce SSH command logging as part of Cloudflare Zero Trust.

翻了 Zero Trust 的 Pricing 資訊,Free Plan 看起來是 50 users 以下不用錢,但不確定這個功能會被放到 Core Features 內還是會被放到另外要收費的部份。

早在 AWS 在 2016 年的時候有用 script 整合了一個方案出來,裡面提到的方法不限於 AWS 上才能用:「How to Record SSH Sessions Established Through a Bastion Host」。

翻了一下 open source 專案,看起來有一些 open source 方案可以用:

另外這個需求在資安要求比較高的行業算是很常見,非 open source 的方案就有不少,先隨便抓兩個:

SSH 的 StrictHostKeyChecking=accept-new

OpenSSH 在連到新的 host 時會跳出 key fingerprint 的資訊讓使用者確認,有時候為了自動化會用 StrictHostKeyChecking=no 避開,在 Lobsters Daily 上則看到了新的選項可以用,StrictHostKeyChecking=accept-new

就如同選項的名字所描述的,查了一下 OpenSSH Release Notes 可以看到這是在 OpenSSH 7.5 導入的參數,是在 March 20, 2017 引入的:

* ssh(1): expand the StrictHostKeyChecking option with two new settings. The first "accept-new" will automatically accept hitherto-unseen keys but will refuse connections for changed or invalid hostkeys. This is a safer subset of the current behaviour of StrictHostKeyChecking=no. The second setting "off", is a synonym for the current behaviour of StrictHostKeyChecking=no: accept new host keys, and continue connection for hosts with incorrect hostkeys. A future release will change the meaning of StrictHostKeyChecking=no to the behaviour of "accept-new". bz#2400

對於一些自動化的流程應該夠用了,不需要到用 no 完全關掉。

翻了「Ubuntu – Package Search Results -- openssh-client」可以看到 18.04 之後都是 7.5 之後的版本了,支援度應該是沒什麼太大問題...