Tag: host

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 這樣的組合沒興趣...

Amazon EC2 有 Mac (M1) 機種可以租用了

2020 年年底的時候 AWS 推出用 Mac mini 配合搭建出 Mac (Intel) 機種：「Amazon EC2 推出 Mac Instance」，當初有計畫在 2021 年推出 M1 的版本：

Apple M1 Chip – EC2 Mac instances with the Apple M1 chip are already in the works, and planned for 2021.

不過就沒什麼意外的 delay 了，這次則是推出了 M1 的版本：「New – Amazon EC2 M1 Mac Instances」。

依照說明看起來還是 Mac mini，掛上 AWS Nitro System：

EC2 Mac instances are dedicated Mac mini computers attached through Thunderbolt to the AWS Nitro System, which lets the Mac mini appear and behave like another EC2 instance.

然後跟 Intel 版本一樣，因為是掛進 Dedicated Hosts 的計價方式，雖然是以秒計費，但還是設定最低 24 小時的租用時間限制：

Amazon EC2 Mac instances are available as Dedicated Hosts through both On Demand and Savings Plans pricing models. The Dedicated Host is the unit of billing for EC2 Mac instances. Billing is per second, with a 24-hour minimum allocation period for the Dedicated Host to comply with the Apple macOS Software License Agreement. At the end of the 24-hour minimum allocation period, the host can be released at any time with no further commitment.

Intel 版本代號是 mac1，只有一種機種 mac1.metal，M1 版本代號是 mac2，也只有一種機種 mac2.metal。

以最經典的美東一區 us-east-1 來看，mac1.metal 的 on-demand 價錢是 US$1.083/hour，mac2.metal 則是 US$0.65/hour，差不多是 60% 的價錢，便宜不少，大概是反應在硬體攤提與電費成本上了。

另外目前大家用 M1 的經驗來看，Rostta 2 未必會比原生的機器慢多少，雖然 mac1.metal 是 12 cores，mac2.metal 是 8 core，但以雲上面一定要用 Mac 跑的應用來說，馬上想的到的還是綁在 Apple 環境裡 CI 類的應用？

目前看起來主要的問題還是 24 小時的最小計費單位讓彈性低不少...

關於自己架設 E-mail server 的事情

自己架設 E-mail server 的難處算是每過一陣子在 Hacker News 上就會冒出來討論的題目：「Ask HN: Why can't I host my own email?」。

收信只要有固定 IP，加上 ISP 沒有擋 TCP port 25 就倒不是問題，整個最難的點在於怎麼送信，因為會常常被標成 spam...

最基本要設定的東西大概是 SPF，但通常還是建議連 DKIM 一起搞定。另外 DMARC 也弄一下會比較好。

然後依照經驗，Gmail 擋信的機率低不少，微軟家擋信的情況就多很多 (包括免費的 E-mail 服務與付費的 Microsoft 365)...

目前一般建議是自用就過 Amazon SES，沒有低消所以個人用起來不貴...

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

Ubuntu 20.04 下用 resolvconf 取代 systemd-resolved (因為 PPPoE)

如同在「升級跳板機」這邊提到的，這台跳板機是跑 Ubuntu 20.04，加上需要跑 PPPoE，我就遇到透過 PPPoE 拿到的 DNS 無法套用的系統內。

這點在「add pppoe support to systemd-networkd」這邊有被提到，而且看起來 Debian 那邊已經套用 patch 上去了，但 Ubuntu 這邊似乎還沒...

我看了看還是決定先暫時先回頭用 resolvconf，可以只用指令解決：

sudo apt install -y resolvconf
sudo systemctl disable systemd-resolved

然後重開確認後就可以收工...

升級跳板機

算是做個記錄...

差不多是 2014 年的時候，因為 xDSL 網路的頻寬拉起來比較夠用了，加上當時發生一些事情，而且 HiNet 的 PPPoE 可以申請發一個固定 IP (即「非固固 IP」)，所以就用這個功能架了一台小的 server，這樣一來就有一台小的 server 可以用，另外很多 firewall 之類的操作就方便很多。

當時買的機子是 Gigabyte 的 GB-XM12-3227，Intel i3-3227 + 4GB RAM + 128GB mSATA SSD：

幾年前 CPU 風扇掛過一次，去淘寶上挖了一顆回來後又可以繼續用。

不過後來在上面跑的東西愈來愈多，加上現在的軟體開發愈來愈吃各種資源 (就算只是 command line 環境)，i3-3227 的 CPU Benchmarks 跑分也才 1274，記憶體也只裝了 4GB，跑起來還是愈來愈吃力... 大概在年初的時候就有打算要換，直到看到了這個機殼的影片：

我買了一個機殼回來 (還找到 $350 含運的店家)，在客廳裝了一台 Intel J1900 + 8GB RAM 的機器接電視用 (不過這又是另外一個故事了)，對這款機殼還算滿意，就再去下了一顆回來...

接下來就是湊其他的零件了，既然這次要拿來當半個開發機用，上面的等級要好一點，但又不希望太吃電 (畢竟是一直開著的機器)，所以就找了一顆二手的 Intel i3-8100T (35W，CPU Benchmarks 分數 5319)，然後在 PChome 24h 上面找了張 H310 的主機板，一個全新的 350W 電源供應器，以及 2*16GB RAM + 500GB SATA SSD。風扇的話是之前 Intel E3-1230 v3 留下來的風扇 (現在上面是掛水冷)，扣具的位置是相同的 (LGA115x)，就直接拿來用了。

弄好後裝個 Ubuntu 20.04，然後在只有兩顆風扇的環境下 (電源供應器的風扇與 CPU 風扇)，CPU idle 只有 35 度上下，壓測也只有 55 度上下，本來還在糾結後方要不要還是裝個 8cm 系統風扇，後來決定還是放一顆上去好了，用負壓的方式把熱帶出來。

如果之後真的遇到灰塵太多的問題，再考慮用先前在「無風扇系統的 CPU 散熱片」提到的方案來換：

接下來就是搭車把機器帶老家裝，就順便被老人家餵食：

回家升級跳板機，然後就被餵食了...

換完後當然如同預期的速度快不少，接下來應該會考慮把線路升級到 300M/100M (現在只有 100M/40M)，不過看起來 IP 一定會變，就比較麻煩了，之後再看看機會...

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 + 六碼動態數字)。

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

Google Fonts 的加速方式

這邊講的是透過 css (以及 js) 使用的 Google Fonts，作者想要改善這塊，加速網頁的速度：「Should you self-host Google Fonts?」。

作者第一個提到的技巧是個懶人技巧，只要加上 preconnect 預先把 HTTPS 連線建好，就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect，但從前後比較可以看出，整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的)：

另外一個技巧是增加 swap，讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖，然後突然字都冒出來的情況，也就是把一般在用的：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

加上 &display=swap：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

最後一招就是把字型放在自己家，差異就更大了：

另外一個好處是改善 privacy，不過好像沒特別提到...

Amazon S3 淘汰 Path-style 存取方式的新計畫

先前在「Amazon S3 要拿掉 Path-style 存取方式」提到 Amazon S3 淘汰 Path-style 存取方式的計畫，經過幾天後有改變了。

Jeff Barr 發表了一篇「Amazon S3 Path Deprecation Plan – The Rest of the Story」，裡面提到本來的計畫是 Path-style model 只支援到 2020/09/30，被大幅修改為只有在 2020/09/30 後建立的 bucket 才會禁止使用 Path-style：

In response to feedback on the original deprecation plan that we announced last week, we are making an important change. Here’s the executive summary:

Original Plan – Support for the path-style model ends on September 30, 2020.

Revised Plan – Support for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.

這樣大幅降低本來會預期的衝擊，但 S3 團隊希望償還的技術債又得繼續下去了... 也許再過個幾年後才會再被提出來？

Amazon S3 要拿掉 Path-style 存取方式

在 Hacker News 上翻的時候翻到的公告：「Announcement: Amazon S3 will no longer support path-style API requests starting September 30th, 2020」。

現有的兩種方法，一種是把 bucket name 放在 path (V1)，另外一種是把 bucket name 放在 hostname (V2)：

Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com/<bucketname>/key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //<bucketname>.s3.amazonaws.com/key).

這次要淘汰的是 V1 的方式，預定在 2020 年十月停止服務 (服務到九月底)：

Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.

Virtual-hosted style requests are supported for all S3 endpoints in all AWS regions. S3 will stop accepting requests made using the path-style request format in all regions starting September 30th, 2020. Any requests using the path-style request format made after this time will fail.