为什么 ssh-keygen 和 ssh-copy-id 创建具有不正确权限的文件

为什么 ssh-keygen 和 ssh-copy-id 创建具有不正确权限的文件

我有一个上周刚刚设置的 FreeBSD 主机 (sh),它正在执行以下两件似乎相关的奇怪的事情:

  1. ssh-keygen ON 此主机正在创建具有 775 个文件权限的私钥和公钥

  2. ssh-copy-id TO此主机正在创建具有775权限的authorized_keys

结果是,除非权限修复,否则 SSHd 不会在身份验证中使用这些文件。我想彻底解决这个问题,因为我最终想将此主机设置为堡垒/跳转服务器。

我在这里通过下面的一些注释对每一个进行了说明。

当我将chmod这些文件赋予正确的权限时,一切都按预期进行。我想最终的问题是为什么这个主机以不正确的权限写入文件?

如果您能提供任何关于此事的意见或见解,我将不胜感激。我已阅读 ssh-keygen 和 ssh-copy-id 手册页,但未看到任何指定输出文件权限或使用配置文件指定权限的选项。

第 #1 期

在这里我将创建一个新的密钥对并显示生成的权限:

jg@sh ~ ❯❯❯ ssh-keygen -C testkey -f ~/.ssh/test-key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jg/.ssh/test-key
Your public key has been saved in /home/jg/.ssh/test-key.pub
The key fingerprint is:
SHA256:dSQXsohvg53uRy07TWZ/kA7DP251L6MSA5tonxXd0zQ testkey
The key's randomart image is:
+---[RSA 3072]----+
|          o +.   |
|       . . *   E.|
|      . . o... o.|
|       +.o... o .|
|      ..S+ +   o |
|      ooo.* O o o|
|     . ..+ X * oo|
|       .o = . O o|
|        .. o.+.= |
+----[SHA256]-----+
jg@sh ~ ❯❯❯ ll .ssh/test-key*
-rwxrwxr-x+ 1 jg  jg   2.5K Dec 12 15:38 .ssh/test-key
-rwxrwxr-x+ 1 jg  jg   561B Dec 12 15:38 .ssh/test-key.pub

第 #2 期

首先删除现有authorized_keys文件:

jg@sh ~ ❯❯❯ rm -rf .ssh/authorized_keys

跳转到另一台主机并使用ssh-copy-id将公钥放在该主机上:

jg@BTFU:~ % ssh-copy-id -i .ssh/id_rsa_btfu-to-sh_20231212 jg@sh
([email protected]) Password for jg@sh:

回到我们的目标主机并检查该文件:

jg@sh ~ ❯❯❯ ll .ssh/authorized_keys
-rwxrwxr-x+ 1 jg  jg   573B Dec 12 15:41 .ssh/authorized_keys

笔记:

  • 该系统是 FreeBSD 13.2-release-p5 并作为 TrueNAS 设备上的监狱运行(如果重要的话)。
  • 我认为这不太可能是 FreeBSD 的问题,同一设备上同一版本的其他 jail 行为正常,使用 600 权限写入私钥,使用 644 权限写入公钥,使用 600 权限写入 authorized_hosts
  • $HOME 归 jg 所有并且是 755 ( drwxr-xr-x+)——这看起来是正确的。
  • jg 用户的 umask 是 022,这似乎也是正确的

答案1

FreeBSD 上的 ssh-keygen 仅对 使用 umask test-key.pub,而不对 使用 umask test-key

有效权限看起来像 HOME 位于共享上(可能是 samba),这迫使文件模式不同(创建掩码 = 0775)

答案2

感谢@dave_thompson_085 的提示,我能够弄清楚这一点,因此为后面任何勇敢的探险者留下了指示。

#1 最重要的是,我错过了+文件列表中的 ,因为它有意义。这意味着该文件有一个 ACL。这在 的手册页中被调用ls

#2 FreeBSD 使用 NFSv4 文件 ACL,这与 Linux 平台使用的 POSIX ACL 不同。

#3 使用getfacl [filename]查看应用了什么。阅读 setfacl(1) 手册页以解析输出的含义。

#4 当您到达这一点时,您可能会眯着眼睛看 setfacl(1) 手册页一会儿并尝试编写一个setfacl -m(修改)命令,您可能会收到类似以下内容的错误:
setfacl: [filename]: branding mismatch; existing ACL is NFSv4, entry to be merged is POSIX.1e

#5 您可能最终只想完全删除 ACL!为此,请使用setfacl -b [filename|*]setfacl -b .从所需文件和目录中删除 ACL,这样新文件就不会继承 ACL。

(如果你有更好的方法改变文件的 ACL 和目录上的 ACL,以便新文件可以正确继承权限,如果您能在这里通过评论或回答向我提供一些知识,我会很高兴。)

具体来说是 TrueNAS/FreeNAS 实际上并不重要,但它确实暗示了监狱的文件系统是 ZFS,这与上面的第 2 点相吻合。

相关内容