Tag: ssh

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 之後的版本了，支援度應該是沒什麼太大問題...

OpenSSH 的 scp 改用 SFTP 協定

在「By default, scp(1) now uses SFTP protocol」這邊看到的，OpenSSH 的 scp 改用 SFTP 協定了，原因也有附在文章裡：

SFTP offers more predictable filename handling and does not require expansion of glob(3) patterns via the shell on the remote side.

要注意這是 BC-break change，有些之前會動的 case 在改用 SFTP 後會爛掉，但這算是前進了一大步，scp 因為 spec 的關係很難維護安全性。

在「Deprecating scp」這邊也有提到相關的問題，另外也給出了一些範例。

很久沒出新版的 mosh...

在今天的 Hacker News Daily 上看到 mosh 的連結，看了一下 Hacker News 上的討論，發現原作者有上去跟大家討論一些目前的情況：「Mosh: The Mobile Shell (mosh.org)」。

原作者是 Keith Winstein，在 Hacker News 上的帳號名稱是 keithwinstein，可以用 Ctrl-F 翻一下他回應的東西。

關於四年沒有新版的原因，一方面是他覺得已經將後續的開發與維護交棒出去，不應該因為接手的人太忙就冒出來；另外一方面是目前的版本也沒有安全問題，沒有迫切需要丟出一個新版本：

I think the truth is that we don't feel like we need a release. We've never had a security hole, our track record speaks for itself, and I wouldn't really want us to rush anything and blow that. There are some features that it would be really nice to have in a release (like 24-bit color support, and working around a recent MacOS clock bug), but I handed over the maintainership to somebody else about six years ago and that person is currently, I think, dealing with a bunch of stuff (look around the world the last year...). I'm not eager to step back in and bigfoot them -- especially when I'm no longer particularly familiar with the codebase (and recent commits) as I used to be.

Mosh works as advertised and has never had a security hole -- we're pretty proud of that! We'll probably cut a release at some point to add those features (24-bit colors, the MacOS clock workaround) but I'm not feeling like it's urgent enough to upset what I had hoped was a transition plan.

It would feel arrogant to compare Mosh to TeX, but it doesn't seem that crazy to imagine that some software might reach a point where it has accomplished 95% of its goals, and the benefit from adding further features has to be weighed against the risk of introducing a security hole or other regression through further churn. If the TCP specification, or OpenSSH, or TeX, or GNU bash had canonical GitHub repositories, they would probably be full of a bunch of user support issues and inactive PRs too. :-)

看了一下 GitHub 上 Contributors 這頁，可能是 cgull？

的確是一個很穩定的軟體，在桌機與筆電上面都用了八九年了，解決了網路切換 (或是不穩定) 的問題：「把 SSH 換成 Mosh」。

Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能，畢竟是公司要用的，還是實際測一下數字，之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWS 的 ap-southeast-1 (Singapore) 的 EC2 測試，直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令，其他的是出自我自己 wiki 上的 Ubuntu 這頁)，然後再重開機：

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s，另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上，這樣可以捲回去看每一秒的傳輸速度，就可以看出來變化了，不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline)：

EC2 instance Baseline Burstable vCPU RAM Pricing (USD$)
c6g.medium 500Mbps 10Gbps 1 2GB 0.0392
c6g.large 750Mbps 5Gbps (claimed 10Gbps) 2 4GB 0.0784
c6g.xlarge 1.25Gbps 10Gbps 4 8GB 0.1568
t4g.small 125Mbps 5Gbps 2 2GB 0.0212
t4g.medium 255Mbps 5Gbps 2 4GB 0.0424
t4g.large 510Mbps 5Gbps 2 8GB 0.0848
t4g.xlarge 1Gbps 5Gbps 4 16GB 0.1696

這邊沒列出來的是 burstable 可以持續的時間，但這跟你機器吃的網路資源有關，我就決定只用 baseline 來做決策了，這樣可能會多花一點錢，但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead，所以就順便查了一下資料：

  • OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候)：「OpenVPN performance」。
  • SSH 也有些 overhead，大約是 6% (把來回的封包都算進去)：「What is the overhead of SSH compared to telnet?」。
  • rsync 的部份鐵定也有 overhead，但這邊就沒找到現成的文章有統計過了。
  • 另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的，會有 10% packet loss，改用預設的 CUBIC 會好很多，大約 1% 到 2% 左右。

綜合這些測試，我自己抓了 35% 的 overhead 來推估，最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量，大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠，有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多，應該是不需要降...

Mac OS 7/8/9 上的 SSH client

在 Hacker News 首頁上看到「Ssheven: A modern SSH client for Mac OS 7-9 (github.com/cy384)」這個，為了 Mac OS 7/8/9 (PowerPC 平台) 實做 SSH client。

翻了一下程式碼，看起來是透過 libssh2 實做加解密的部份，依照 libssh2 的官網，支援的演算法雖然不是超級新，但看起來還算可以 (至少有目前還算安全的演算法可以用)：

Hacker News 上有看到一些老機器跑出來玩 XD

tikwidd 8 hours ago

So far it's working well on my LC III (68030 with 36mb ram)!
I'm writing this comment from the LC III using w3m over ssh :)

SSH 對傳入參數的 quoting

昨天在 Hacker News 首頁上看到「SSH quoting」這個，看得出來作者被 OpenSSH 玩弄到不要不要的樣子...

先簡單的整理一下：

$ ssh example.com 'cd /tmp; pwd'
/tmp
$ ssh example.com 'bash -l -c "cd /tmp; pwd"'
/tmp
$ ssh example.com bash -l -c "cd /tmp; pwd"  
/home/gslin

第三個指令發生的「預期外的行為」，但寫習慣的人會把指令全部包成一個字串，就很自然的避開這個問題了。當然 OpenSSH 的設計 (讓你不用加 quote 也會動) 的確也是容易中獎的點啦...

GitHub 支援 SSH 使用 Security Key 了

GitHub 宣佈支援使用 security key 的 SSH key 操作了：「Security keys are now supported for SSH Git operations」。

也就是需要 SSH key + security key 才有辦法認證，只有拿到 SSH key 或是 security key 都是沒有辦法認證過。

目前官方支援 ecdsa-sk 與 ed25519-sk：

Now you can use two additional key types: ecdsa-sk and ed25519-sk, where the “sk” suffix is short for “security key.”

不過在 Ubuntu 20.04 下用預設的系統只能支援 ecdsa-sk，因為 ed25519-sk 會遇到類似「ed25519 problem with libressl」這邊的問題，就算你用的是 OpenSSL。

然後生完 key 後在 ~/.ssh/config 裡面指定對 github.com 使用這把 key：

Host github.com
    IdentityFile ~/.ssh/id_ecdsa_sk

接下來操作的時候就會需要碰一下 security key 了。