ssh – Page 2 – Gea-Suan Lin's BLOG

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 了。

還原被碼掉的 PEM 資訊 (SSH RSA key)

在「Recovering a full PEM Private Key when half of it is redacted」這邊看到的，起因是 _SaxX_ 幫客戶做滲透測試時找到客戶公開在網路上的 SSH key，然後他就碼掉一部分貼出來：

This morning, I began another #pentest for a client. After some google-fu dorking combine with the major search engines, I found the id_rsa key that gave me access to the server and a bunch of others 😬😬

another mistake under their radar... pic.twitter.com/K99UyjKTzW

— S. A. X. X. (@_SaxX_) March 24, 2021

原圖是這樣，接下來就開始被還原 XD

首先是 OCR 的過程，被稱為是整個還原過程最難的一部分 (哭爸啊)：

Ironically, this was the hardest part of the challenge. It took the longest time of all the steps and was the easiest to make errors in.

接下來就是解讀 PEM 檔的格式，可以藉此得到裡面的參數。

然後是套公式，窮舉運算裡面的值，可以看到迴圈 kp 只算了 3 到 65537，就推算出可能的 p：

e = 65537
q = 0xc28871e8714090e0a33327b88acc57eef2eb6033ac6bc44f31baeac33cbc026c3e8bbe9e0f77c8dbc0b4bfed0273f6621d24bc1effc0b6c06427b89758f6d433a02bf996d42e1e2750738ac3b85b4a187a3bcb4124d62296cb0eecaa5b70fb84a12254b0973797a1e53829ec59f22238eab77b211664fc2fa686893dda43756c895953e573fd52aa9bb41d22306135c81174a001b32f5407d4f72d80c5de2850541de5d55c19c1f817eea994dfa534b6d941ba204b306225a9e06ddb048f4e34507540fb3f03efeb30bdd076cfa22b135c9037c9e18fe4fa70cf61cea8c002e9c85e53c1eaac935042d00697270f05b8a7976846963c933dadd527227e6c45e1
dp = 0x878f7c1b9b19b1693c1371305f194cd08c770c8f5976b2d8e3cf769a1117080d6e90a10aef9da6eb5b34219b71f4c8e5cde3a9d36945ac507ee6dfe4c146e7458ef83fa065e3036e5fbf15597e97a7ba93a31124d97c177e68e38adc4c45858417abf8034745d6b3782a195e6dd3cf0be14f5d97247900e9aac3b2b5a89f33a3f8f71d27d670401ca185eb9c88644b7985e4d98a7da37bfffdb737e54b6e0de2004d0c8c425fb16380431d7de40540c02346c98991b748ebbc8aac73dd58de6f7ff00a302f4047020b6cd9098f6ba686994f5e043e7181edfc552e18bce42b3a42b63f7ccb7729b74e76a040055d397278cb939240f236d0a2a79757ba7a9f09

for kp in range(3, e):
    p_mul = dp * e - 1
    if p_mul % kp == 0:
        p = (p_mul // kp) + 1
        if isPrime(p):
            print(f"Possible p: {p}")

後面就是跑驗證確認，就被打出來了...

OpenSSH 8.4 預設停用 ssh-rsa

前幾天 OpenSSH 8.4 釋出了：「Announce: OpenSSH 8.4 released」。

比較重要的改變是 ssh-rsa 預設變成停用，因為是使用 SHA-1 演算法的關係：

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

官方給了三個方案：

The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.
The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5.
The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7.

掃了一下 ~/.ssh/known_hosts，看起來目前大多都是 ssh-ed25519 了，還有少數還是 ssh-rsa。

翻了一下 Ubuntu 這邊的版本，16.04 是 7.2p2，看起來目前有支援的版本都可以用這三個。

官方有提到可以在 command 上強制關閉 ssh-rsa 測試的方法：

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

現在看起來比較麻煩的是 Dropbear 的部份，我自己之前是有包 PPA 來用 (2019.78)，但看起來還是不夠新支援 ssh-ed25519 (要今年六月的 2020.79 才支援)，所以也許要找時間來把 PPA 更新到 2020.80...

另外一種方法是走 ecdsa-sha2-nistp{256,384,521} 這些演算法，不過從名字就可以知道裡面演算法的由來，卡個 NIST 在那邊看起來就不太舒服，但還是寫一下方法好了：

先用 dropbearkey 產生對應的 ecdsa host key：

sudo dropbearkey -t ecdsa -f /etc/dropbear/dropbear_ecdsa_host_key -s 256

再來在 /etc/default/dropbear 裡面把 DROPBEAR_EXTRA_ARGS 加上對應的 ecdsa host key 資訊，這邊直接用 -r 是因為他可以重複指定，不會影響到其他的 host key 設定：

# any additional arguments for Dropbear
DROPBEAR_EXTRA_ARGS="-r /etc/dropbear/dropbear_ecdsa_host_key"

然後重跑 dropbear 就可以了。

另外有興趣的人可以用 ssh -Q key 看 openssh client 支援的演算法。

把 SSH Key 放進 Secure Enclave 裡保護

看到 Secretive 這個專案，是利用蘋果的 Secure Enclave 機制，把 SSH private key 放進去在裡面進行運算，避免 private key 檔案被惡意程式讀取就洩漏出去了。

從 Secure Enclave 的介紹頁面可以看到這個需要有 T1 或是 T2 晶片才有 Secure Enclave 功能：

Mac computers that contain the T1 chip or the Apple T2 Security Chip

而從 Apple Silicon 這邊可以看到 Apple T1 chip 是 2016 年後的機種引入的：

The Apple T1 chip is an ARMv7 SoC (derived from the processor in S2 SiP) from Apple driving the System Management Controller (SMC) and Touch ID sensor of the 2016 and 2017 MacBook Pro with Touch Bar.

然後對於沒有 Secure Enclave 的古董機，可以透過有支援 smart card 的硬體掛上去，像是 YubiKey：

For Macs without Secure Enclaves, you can configure a Smart Card (such as a YubiKey) and use it for signing as well.

照著他講的建議去翻了「YubiKey Smart Card Deployment Guide」這邊的資料，看起來 YubiKey 在 4 系列之後就有產品支援 Smart Card 了，不過要注意純 U2F 的版本沒支援。

OpenSSH 的三個進階用法：CA 架構、透過 Jump Server 連線、2FA

在「How to SSH Properly」這篇裡面講了三個 OpenSSH 的進階用法：CA 架構、透過 Jump Server 連線，以及 2FA 的設定。

之前蠻常看到使用 -o StrictHostKeyChecking=off 關閉檢查，但 OpenSSH 有支援 CA 架構，可以先產生出 Root CA，然後對 Host 的 Public Key 簽名，在連線的時候就可以確保連線沒有被調包 (通常是 MITM)，但得設計一套機制，自動化機器生出來後的步驟。

另外一個可能的方式是 SSHFP，搭配 DNSSEC 也可以確認連線沒有被調包，不過這又牽扯到 DNS 的部份...

第二個提到的是 Jump Server (Bastion host)，之前的作法是用 -A 把 authentication agent 帶過去再連進去，這邊則是教你怎麼下指令直接連線，而不需要先連到 Jump Server (但實際上底層是透過 Jump Server)。

第三個是 2FA，對於還是使用密碼登入的系統可以多一層保護。文章裡面講的是 TOTP 的方式 (就是現在還蠻常見的 app + 六碼動態數字)。

先知道有這些東西，之後真的有用到的場景時再回來看...

Ptt 開始限縮 Telnet 協定連線方式

Ptt 開始關掉一些沒有加密的 Telnet 登入方式：「[公告] 正式支援Websocket連線/telnet連接埠調整」。

本來有 Telnet 很多 Port 可以連，現在限制到 Port 23：

此外, PTT 將會逐漸關閉無加密的 telnet 連線方式.
PTT 預計於 2020/03/01 起對 telnet 連接埠作以下調整.

到 2020/02/29 止 telnet 連接埠: 23, 443, 3000-3010, 8888
從 2020/03/01 起 telnet 連接埠: 23

同時也宣布扶正 WebSocket 連線方式：