很久以前在 macOS 上配置了一次，然后具体怎么配给忘了一个干净，所以这次写一个作弊条。

Telegram 最近宣布了其订阅付费计划。 说起来我也不是特别信任其安全/隐私方面的特性(*)，不过作为一个跨平台即时通讯软件来说， 其在不同平台上的功能基本上做到了完全一致，并且在这个礼崩乐坏 的时代，能够在不同平台上都做到不狂吃CPU/内存，在不同平台上的界面行为上高度一致， 并且完全没有各种令人抓狂的智障设计（举例来说：随便干什么事情都弄个二维码还非让你扫描一下借此获得摄像头权限、 多机登录时以手机为主并且时不时就得再扫描一次二维码、完全无法回溯的会话引用、 没头没脑地给一条「有人@你」的通知，却无法迅速定位到消息等等），并且公开客户端源代码以便第三方进行代码审计， 确实是十分难得的。

问题

有些环境中，SSH 服务器可能无法从 Internet 直接访问（例如，SSH 服务器可能使用的是一个私有 IP 地址，或是 Internet 服务提供商没有提供 IPv6 服务，而 SSH 服务器只提供 IPv6 服务）。

考虑到 SSH 已经进行了相互认证（连接时客户端会验证服务器的公钥是否与已知公钥，例如 ~/.ssh/known_hosts， 或是通过 DNSsec 发布的 SSHFP RR 匹配；服务器端则会验证用户是否能证明自己拥有与授权公钥对应的私钥）， 因此比较常见的解决方法便是使用 VPN、在防火墙上穿孔，或是使用代理服务器。

由于 SSH 自身也提供了许多转发功能，因此如果中间的跳板服务器也提供 SSH 服务， 便可以使用这些跳转服务器直接作为代理服务器来用。与前面那些传统方法相比， 这样做的优点是避免了安装额外的软件，也不需要特别指定端口。

OpenSSH 8.2 中新增了 FIDO/U2F 支持。 它支持两种密钥对类型： ecdsa-sk 和 ed25519-sk。需要注意的是并非所有的 FIDO Security Key 都实现了 ed25519-sk 的硬件支持：例如，截至2022年，Titan Security Key 就不支持 ed25519-sk。

使用 FIDO key 的 SSH key 在使用上和之前的 SSH key 类似， 主要的区别在于在登录时系统会确认用户是否在机器旁边（通常是碰一下 FIDO key）， 这可以显著地改善安全性：与之前的 SSH key 不同的是， 即使机器上的 U2F/FIDO SSH key 私钥文件被攻击者获得， 在没有硬件 FIDO key 的情况下也无法使用这个私钥。 对于对方同时能获得私钥文件和物理访问的情况， 参见 xkcd/538，就不要跟扳手过不去了。

我觉得这事必须得记一笔。

去年9月的时候，我和张师傅在 eBay 上团购了两台 Juniper NFX250-S2。 昨天周师傅问我当时付了多少钱，于是我就打开了浏览器准备去 eBay 查一下交易记录。

诶？右上角那是啥？使用 Gmail 账户登录？这比他们自己那个 2FA 实现好多了啊，我于是想都没想就点了一下。

上个月初带娃去佛罗里达那边休假，在机场租了辆车。这次的租车公司相当先进，完全不需要去排队或是在租车公司的触摸屏上再次确认， 直接在手机应用中确认之后，系统就直接给出了车的位置、型号（Ford Mustang），直接过去开门上车就可以出发了。

开始导航，一会谷歌地图显示去目的地基韦斯特 (Key West) 岛发生了大堵车。

「这题我会」，我想，顺手掏出了另一部手机上的苹果地图导航，发现果然也是出现了堵车。

此地是自古华山一条路，如果桥上发生事故，堵车实属正常。正想着，谷歌地图通知我说您稍微绕一下可以节省四个小时。 「太及时了！」看到堵车地点位于罗纳德里根收费公路附近，我毫不犹豫地跟随指示朝西开去。

走着走着，车的胎压报警突然亮了起来，配合了一段文字：「胎压传感器故障（Tire pressure sensor fault） 」。 这一路上估计车速会比较快，我不敢怠慢，赶快找了附近的一家加油站下车检查。 先是目测，发现轮胎没有显著的变扁，用手使劲按压也没发现什么问题， 于是到气泵处拿气泵带的压力表测了一下，发现胎压完全正常。

由于使用的 port 的编译选项与官方的往往不一致（例如我非常讨厌 gnutls、avahi 这两个包，此外有时我希望使用一个和官方不太一样的 OpenLDAP 版本， 或者采用不同的编译选项等等），我之前一直是 portmaster(8) 的用户。 portmaster 是 Doug Barton 早年用 shell 脚本写的一个 portupgrade(1) 的替代品，和后者相比，它不需要使用数据库，并且充分利用了 shell 的任务管理功能实现了尽可能利用 CPU 的计算能力，我个人也从这个脚本中学到了不少 shell 脚本的技巧。

不过，使用 portmaster 需要在每一台机器上都有一份 ports tree，并且由于直接操作的是本地的生产环境， 因此对于比较基础的库，如 gettext 之类，或是在升级操作系统时， 由于升级时间较久导致出现问题的可能性相对要大一些。 另一方面，使用 port 来管理第三方软件意味着需要把联编过程中的所有依赖软件包全都都装到生产环境中， 有时这是非常不经济的，例如大部分时候运行环境并不需要完整的跨平台 LLVM，等等，而使用 port 安装的话， 每一个系统中都需要整体重新联编一遍。

我之前已经用过很长时间的 poudriere 了。 这是一款现代化的联编系统，它充分利用了 FreeBSD 的一系列特性，包括 ZFS 快照/克隆、 tmpfs、 jail 等等，支持交叉编译。除此之外它还支持使用 ccache 来减少重复编译，等等。 不过，线上的机器出于习惯^H^H懒惰导致的惯性一直还是在沿用之前采用 portmaster 来进行更新。