最先进的Crypto进入后量子时代(采用容器化TinySSH)
保密是计算机科学最重要的功能之一。如果电子保密突然崩溃为完全透明，我们将无法从事电子商务，我们将无法私下沟通，我们过去的通信将在全球范围内可见，我们将受到无数方面的严重影响，这将从根本上改变我们的工作和生活能力。想一想我们每天花多少时间用密码、锁模式、无线Fobb和生物识别来维护我们的机密性，这些密码、锁模式和生物识别技术限制了访问以保护我们，以及它们失败的后果。
公钥密码系统构成了我们保密的一个重要方面。通过公共媒体建立私人通信的能力每天被使用数十亿次。如果技术的出现揭开了这种私人话语的面纱，后果可能是不可估量的。
在量子计算领域，这样的技术正在兴起。可以执行肖尔算法直接威胁常用公钥方案(RSA、传统的Diffie-Hellman和椭圆曲线)的潜在硬件可能比我们预期的更接近实现。D-Wave公司承诺今年将交付一台5000量子比特的绝热量子计算机；这台计算机不能直接运行肖尔的算法，但如果运行，TLS和SSH将受到严重威胁。有一些紧迫的事情需要纠正我们的密码系统。
与渗透到我们电子产品中的无处不在的CMOS技术不同，量子逻辑是一种截然不同的设计，它适应了不确定性和不确定性，从量子位的形式开始，这是一个违反直觉的二进制数值，可以同时为正值和负值。这些新的计算设备的威胁是非常真实的，以至于美国国家标准研究所(National Institute Of Standards)发起了一场争夺量子抗性公钥密码系统的比赛。
在这场争论中，TinySSH，一个嵌入焦点的最小SSH服务器，已经实现了一种混合密钥交换，使用NTRU Prime(NIST竞赛的第二轮决赛选手)与传统的ed25519椭圆曲线密钥相结合。该方法允许ed25519密钥通常继续使用，但透明地增加了量子转发保密的外观。"；OpenSSH v8.0中采用了该方法：
提交dfd591618cdf2c96727ac0eb65f89cf54af0d97e作者：[email protected]日期：*Mon Jan 21 10：20：12 2019年+0000。上游：添加对PQC KEX/KEM的支持：使用简化的NTRU Prime*4591^761实施，添加对PQC KEX/KEM的支持：[email protected]。默认情况下未启用。
TinySSH服务器严格遵循与Daniel J.Bernstein相关的加密技术，大部分SSH会话流量依赖于chacha20-poly1305；不允许使用其他密码。它同样不允许密码登录，但需要准备好用户ed25519密钥才能成功连接。这些约束可能看起来很僵硬，但它们也是最佳实践。
TinySSH服务器可以补充或替换Linux OpenSSH守护进程，并且提供了通过inetd或systemd套接字激活来执行此操作的说明。TinySSH的极简主义立场也很适合Linux容器设计，但要实现这一点需要做一些调整。
无论如何，NTRU密钥交换已经在OpenSSH中部署了足够长的时间，因此通用是一个合理的目标。它也远比ssh-rsa密钥更可取，ssh-rsa密钥是多年来默认的SSH2用户和主机密钥类型，现在由于对SHA-1的依赖而受到严重削弱。虽然TinySSH的作者Jan MoJžíš暗示，NTRU密钥交换还没有达到可以投入生产使用的地步-包括后量子密码-启用它肯定比继续依赖SSH-RSA更安全。
一般说来，容器共享一个共同的内核，但有不同的用户空间，这将它们与虚拟机区分开来。最直接的Linux容器可能从BusyBox开始。在本练习中，我获得了使用MUSL libc(而不是uclibc)编译的1.31.0版本。选择合适的体系结构；我已经开始使用标准的x86_64 PC。
以本地目录中有BusyBox副本的root用户身份，输入以下命令以组织并启动/home/pqc作为Post-Quantum Container：
#mkdir-p/home/pqc/bin#cp busybox-x86_64/home/pqc/bin#mkdir/home/pqc/root#mkdir/home/pqc/ssh#mkdir-p/home/pqc/var/log#cd/home/pqc/bin#chmod 755 busybox-x86_64#./busybox-x86_64-list|awk。|sh#cd/home/pqc#tar cf-/usr/share/zoneinfo|tar xvpf-#ln-s bin sbin#mkdir/home/pqc/etc#echo'；name="；Post-Quantum Container"；&39；>；/home/pqc/etc/os-release#echo&39；root：：0：0：root：/root：/bin/sh'。/HOME/pqc/etc/passwd#ECHO根：x：0：>；/etc/group#ECHO'；控制台：：Respawn：/bin/getty 38400/dev/console'；>；/home/pqc/etc/inittab#ECHO'；：：sysinit：/bin/syslogd'；>；/home/pqc/etc/inittab#ECHO&#。/home/pqc/etc/inittab#echo'；tssh 2222/tcp'；>；/home/pqc/etc/services#echo"；tssh stream TCP nowait root/ssh/tinysshd tinysshd-lpsv\n-x sftp=/ssh/sftp-server/etc/tinyssh/sshkeydir"；>；/home/pqc/etc/int。
执行上述最后的nspawn命令后，将启动一个新的用户空间，允许您在模拟基本Unix System V的环境中以root用户身份登录：
/home/pqc上的产卵容器pqc。在1秒内按^]三次即可杀死容器。Jun 23 14：44：04 pqc syslog.info syslogd已启动：BusyBox v1.31.0 Jun 23 19：44：04 pqc守护程序.info：正在启动PID 4，tty'；'；：'；/bin/inetd'；Jun 23 19：44：04 pqc daemon.err inetd[5]：tssh/tcp：未知服务Jun 23 19：44：04 pqc守护程序。Pqc login：root Jun 23 19：44：06 pqc auth.info login[6]：root登录'；console'；#ps pid/user-time命令：1 root登录控制台'；#0：00 init：3 root登录：0：00/bin/syslogd登录：5 root登录：0：00/bin/inetd#6 root登录：*0：00-sh：7 root：0：00 ps#。
上面的inetd守护进程被配置为启动TinySSH，而TinySSH还没有出现在您的容器映像中。您可以构建TinySSH并返回容器进行安装。
如果您从未见过nspawn容器，请在继续操作之前花一些时间探索它。如果您想要关闭它，请停止它：
#HALT系统现在要关机了！已向所有进程发送SIGTERM Jun 27 21：51：42 pqc daemon.info：系统正在关闭！Jun 27 16：51：42 pqc syslog.info syslogd正在退出将SIGKILL发送到请求系统暂停的所有进程容器pqc已关闭。
如果您在上面的配置中向root帐户添加密码，它将使用/etc/passwd文件中的古老DES散列进行存储。只有nspawn控制台允许密码登录；TinySSH忽略密码。如果您希望使用影子密码，请在容器内运行以下命令：
最后，您需要禁用控制台Getty，只允许通过TinySSH登录。为此，请注释/home/pqc/etc/inittab的第一行，并为systemd放置以下服务文件：
可以通过各种机制在容器内使用glibc和现有主机代码。然而，这可能很困难，因为大多数程序中有大量的依赖项，复制起来可能很乏味。考虑一下Red Hat/CentOS 7上的sshd服务器；将所有49个共享对象正确放置在一个容器中不是一个简单的过程：
$ldd/usr/sbin/sshd linux-vdso.so.1=>；(0x00007ffeec564000)libfipscheck.so.1=>；/lib64/libfipscheck.so.1(0x00007fafbfa3b000)libwrap.so.0=>；/lib64/libwrap.so.0(0x00007fafbf8。Libkeyutils.so.1=>；/lib64/libkeyutils.so.1(0x00007fafb978e000)libattr.so.1=>；/lib64/libattr.so.1(0x00007fafb9589000)libelf.so.1=>；/lib64/libelf.so.1(0x00007fafb9371000)libz2.so.1=&。
MUSL C库允许大幅减少或完全消除编译对象中的运行时链接器依赖。您至少可以使用它来构建功能齐全的TinySSH。
为了构建MUSL，您必须准备好GNU C编译器和相关工具。如果尚未加载它们，则以root身份运行以下命令(在Red Hat/CentOS平台上)获取它们：
大多数安装将在/usr/local/MUSL中进行，但/lib/ld-musl-x86_64.so.1除外(在/lib64中安装会更一致，但是在编译静态二进制文件时奇怪的位置是无关紧要的)。
特别令人感兴趣的是/usr/local/musl/bin/musl-GCC，它是一个简短的shell脚本，它使用具有备用libc链接的system C编译器。
TinySSH在容器或基本OS安装中的灵活性要求在构建过程中稍有不同，主要是将焦点从glibc转移到MUSL，这并不困难。
处于日落支持不同阶段的遗留系统也可以使用TinySSH来实现现代最佳实践密码。Red Hat/CentOS5可以很好地运行TinySSH，尽管旧的HP-UX10.20系统由于缺乏C99支持而无法编译它。注意，Red Hat/CentOS8包括支持NTRU的OpenSSH客户机和服务器；如果您的主机操作系统运行的是OpenSSHV8或更高版本，那么TinySSH实际上只适合容器使用(在Red Hat/CentOS8上启用NTRUkey需要更改/usr/share/crypto-policies/DEFAULT/opensshserver.txt文件)。
$make sh-e make-tinyssh.sh=Sat Jun 27 18：00：33 CDT 2020=正在获取编译器=Sat Jun 27 18：00：34 CDT 2020=检查编译器选项=Sat Jun 27 18：00：34 CDT 2020=Sat Jun 27 18：00：34 CDT 2020。2020年=74069字代码=星期六6月27 18：00：53 CDT 2020=整理=星期六6月27 18：00：53 CDT 2020=计数代码字数=星期六6月27 18：00：53 CDT 2020=星期六6月27 18：00：53 CDT 2020=加密21330。
$LDD build/bin/tinysshd**linux-vdso.so.1=>；(0x00007ffce33e1000)**libutil.so.1=>；/lib64/libutil.so.1(0x00007f53ade04000)**libc.so.6=>；/lib64/libc.so.6(0x00007f53ada36000).。
此二进制文件将非常适合主机操作系统的SSH服务器，但是试图将其放入具有明显依赖关系的nspawn环境中，调用getpwnam()将会失败。与其调试似乎是glibc名称服务开关问题的问题，不如使用MUSL重新构建代码：
与glibc一样，MUSL库也支持使用动态共享对象。如果要在nspawn中使用MUSL环境准备大量编译的C语言，请考虑在容器应用程序中使用共享库来减少内存消耗，甚至可以重新构建BusyBox以使用共享对象。
在任何情况下，都可以以root用户的身份将静态TinySSH二进制文件移动到容器中：
如果您之前暂停了pqc容器，请重新启动它。确保您以root身份登录，并运行以下命令：
这将生成新的ed25519主机密钥。您可能更喜欢使用OpenSSH中的现有密钥；这将在下面讨论。
此外，必须将AUTHORIZED_KEYS文件安装到将托管登录的特定用户帐户中。如果您尚未生成这样的密钥，请生成。对于此测试用例，密钥最好没有密码：
$ssh-keygen-t ed25519-f测试密钥生成公钥/私钥ed25519密钥对。输入密码(如果没有密码，则为空)：再次输入相同的密码：您的身份已保存在testkey中。您的公钥已保存在testkey.pub中。关键的指纹是：SHA256:tahsHrY5b0PqNMuxxDew35xS7FoLWNJ6VNOslUNCFao [email protected]关键的随机图片是：+--[ED25519256]--+|{##**|{##**}{##**$$}{##**$$}.o.+。我||我是你的朋友*。||=*||。==。*|*||*.o**||**.o++=*.o||*.o++=*.o|+-[SHA256]-+。
将公钥安装到目标帐户中。此示例使用root。如果您更喜欢非root目标，请创建用户并从nspawn控制台对其进行测试。将密钥安装到相应的容器目录中：
#ssh-p2222-i testkey root@localhost无法确定主机'；[localhost]：2222([127.0.0.1]：2222)'；的真实性。ED25519型密钥指纹为SHA256:1nnku5/Q8leUwnbB9mDcfPobvsQapj2JJA6FVVQjTJg.。ED25519型密钥指纹为MD5:bc:dc:b6:52:31:8a:59:1d:dc:c7:61:7c:2b:7c:37:01.。是否确实要继续连接(是/否)？是警告：将'；[localhost]：2222'；(ED25519)永久添加到已知主机列表。输入密钥'；testkey'；的密码：~#。
容器现在应该为最佳实践SSH登录做好了准备，可以选择使用NTRU(可能的)量子安全密钥交换进行保护。
NTRU密钥的一个问题是，目前只有两个服务器和一个客户端实现它们。如果您幸运的是您的操作系统包含OpenSSH V8或更高版本，您可以直接测试NTRU交换机：
如果您是众多没有运行如此新版OpenSSH的Linux用户之一，那么您可以使用MUSL来创建一个。我将演示OpenSSH的其他组件(sftp-server、scp等)。因此，即使是最新OpenSSH版本的用户也有理由使用MUSL版本。下载最新版本的OpenSSH，然后使用以下命令执行MUSL构建：
$。/configure--help|grep不带-openssl|head-1命令--不带-openssl将禁用OpenSSL；仅使用有限的内部加密**实验性**。
如果使用有密码的密钥，您可能会在MUSL&39；的ssh版本中看到以下错误：
如果是这种情况，请将本机ssh-agent与MUSL ssh客户端一起使用，然后删除ssh命令行上对密钥的LATH-I引用：
$eval$(ssh-agent)代理PID 21067$ssh-add~/testkey输入/HOME/cfish/testkey的密码：身份添加：/home/cfish/testkey(cfish@your host.com)$。/ssh-p 2222\-o [email protected]\root@localhost。
您可能已经注意到inetd引用TinySSH中对sftp-server的引用。如果您想要允许sftp或scp，那么将MUSL构建复制到容器中，并使用正在运行的代理测试登录(请注意，我已经将其称为glibc sftp)：
#cp sftp-server/home/pqc/ssh#cp scp/home/pqc/bin$echo'；put ssh-agent'；|sftp-S。/ssh-o端口=2222\-o [email protected]\root@localhost：/root。
现在不鼓励使用SCP，但它是起作用的。此示例假设有一个正在运行的代理：
如果应该允许非本地主机登录容器，则必须打开端口上的所有防火墙限制。要做到这一点，一种方法是：
如果您曾经打算在OpenSSH和TinySSH服务器之间移动主机密钥，那么TinySSH密钥格式可能会有问题，因为它可能不是OpenSSH期望的格式：
#ls-al/home/pqc/etc/tinyssh/sshkeydir共8个drwxr-xr-x，1个根，0个根，8个月，42月27日18：36。Drwxr-xr-x：1根：0：00，3月18日18：27 18：36.。--rw-1根：0：36.pk 64 Jun 27 18：36.ed25519.sk--rw--r--r-1根：0：--3：32 Jun 27 18：36 ed25519.pk。
Tinysshd-printkey实用程序只能打印公钥。将私钥移动到OpenSSH格式可能需要似乎并不存在的自定义代码。因此，tinysshd-makekey实用程序与生产主机密钥有关。
最好维护与OpenSSH兼容的主机密钥副本，并使用转换器生成TinySSH变体。当前的转换器需要Python3(避免使用较旧的基于C的密钥转换器)。我在Red Hat/CentOS 8上加载了Python转换器：
#python3-m pip install tinyssh-keyConvert-0.3.2.zip警告：以root权限运行pip install通常不是一个好主意。改用`__main__.py安装--用户`。正在处理中。/tinyssh-keyConvert-0.3.2.zip安装收集的软件包：tinyssh-keyConvert为tinyssh-keyConvert运行setup.py install...。已成功安装tinyssh-keyConvert-0.3.2。
OpenSSH ed25519主机密钥通常存储在/etc/ssh/ssh_host_ed25519_key中，应该在没有密码的情况下创建。使用以下命令将此类密钥转换为TinySSH格式：
$tinyssh-keyConvert ssh_host_ed25519_key--dir。$ll ed25519.pk.ed25519.sk-rw-r--r--。1 fish ecj ITG 32 Jun 25 11：57 ed25519.pk-rw-。1 fish ecj ITG 64 Jun 25 11：57.ed25519.sk
将所有相关密钥复制到将使用它们的主机或容器。Ssh_host_ed25519_key.pub公钥并不是严格必需的，因为它可以使用ssh-keygen-y重新生成。请务必在安装完成后删除所有临时副本，因为丢失这些密钥将危及主机的通信安全：
反对上述方法的论据有很多。明显的反对意见包括：NTRU Prime没有得到官方认可；使用MUSL编写标准OpenSSH SSHD并不困难；*TinySSH没有使用特权分离和/或chroot()；*TinySSH缺乏重要功能(端口转发、sftp/scp、X11、VPN等)；以及应该执行不使用实验功能的更大的MUSL SSH构建。
关于NTRU的官方认可，OpenSSH打算在近期禁用ssh-rsa。对于遗留系统来说，这将是一个创伤性的变化，其中许多系统将只剩下孤立的SSH实现。随着这一级别的变化即将到来，应该施加压力来选择最好的可用的密码系统，并且可以考虑包含TinySSH NTRU Prime。没有管理员想要这样做两次。
与完全实现OpenSSH SSHD相比，TinySSH服务器的配置难度要小得多。服务器的作者声称不能错误配置TinySSH；但对于SSHD则不能这样说。易管理性是一个因素，尤其是在部署到许多服务器时。
TinySSH'；的安全记录似乎相当干净，它的设计避免了C的已知问题。此服务器强制执行用户的最佳实践，这可能既是安全优势，也可能是培训责任。也许，特权分离的丧失归根结底是一种合理的交易。
使用OpenSSH，用户可以很容易地了解不良习惯和对外来或过时功能的依赖。这些功能应该简约地扩展到有实际需求的有经验的用户。
最后，如果只将scp和/或sftp服务器组件与TinySSH一起使用，则实验构建可能与此无关。OpenSSL也不包括任何NTRU实现，因此该方面可能不会降级。
为了解决更大的问题，SSH面临着巨大的混乱，RSA密钥立即被弃用和转换(这使得TinySSH省略RSA的决定变得明智)。忽略量子后问题，这个问题是由NIST在2016年提出的，
.
