我使用 RSA 密钥通过 ssh 登录到远程服务器。我将我的 dot 文件保存在一个可公开访问的地方，使其处于版本控制之下，这样我就可以快速设置新服务器以按照我喜欢的方式工作。
现在我的 .ssh 目录不受版本控制。但是，如果我可以将 .ssh/authorized_keys 保留在 dotfile 存储库中，它将节省一步。
这只是一个公钥。当然，我的私钥只存在于我拥有的受信任的客户端机器上。我将其设为 4096 位 RSA 密钥，因为这似乎是与常见 sshd 版本的广泛兼容性和安全性之间的最佳平衡。
所以我的问题是，公开发布公钥是否存在任何安全问题？没有人会经常在我的 dotfiles 存储库中闲逛，但这不是秘密，任何有兴趣的人都可以阅读它们。
公钥设计用于共享、读取和/或发布公钥是可以的
私钥是秘密的，只能由所述私钥的所有者访问。
要想明白这一点，请回想一下您曾经访问过的每个 HTTPS 网站。在每种情况下，作为 HTTPS 的一部分，站点都会为您提供他们的公钥。因此，发布它不仅是安全的，而且是这样的。例如，如果您单击地址栏上的绿色锁图标，您可以找到该网站的公钥（如果您在 HTTPS 上查看它）
*.stackexchange.com
Modulus (2048 bits):
af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a
22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9
d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98
33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e
2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1
2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8
f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2
75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d
6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b
2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74
81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5
22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51
65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95
b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35
b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a
80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f
Exponent (24 bits):
65537
这方面的更多示例可以在 github.com 上找到，他们要求您将公钥附加到您的帐户以用于 git clone git@github.com:<user>/<repo>
您实际上可以使用以下 URL 检查 github 上任何用户的公钥
https://api.github.com/users/<user>/keys
我的列为：
[
{
"id": 18667533,
"key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8/V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx/Xw1J/SXfIWUKuEe0SgmIwVwkk8jetfG/Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4+gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH+ABPkNQcFBk4rRLpCEAsoAhmvTk/NjnfZM+nd"
},
{
"id": 21175800,
"key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic/O8licyzW+eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16+lsJBSS8+YiWeMBlwo+JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV+0B/0fzDR/tiLFLj50+iJ9qCDSk/8fAsXz2xG39KcUcxmCbDXb/qSdESWaZc+pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT+k4X/TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"
}
]
私钥的情况恰恰相反，私钥应该始终受到保护，并且永远不要提供给第三方或在未加密的情况下通过电子邮件进行交换。
如果有人访问了您的私钥，他们就可以访问任何受您的公钥保护的设备或加密文件。这也意味着他们可以代表您签署。如果有人获得了您的私钥的访问权限，那将是非常糟糕的。
在许多情况下，如果检测到私钥文件的权限使您以外的用户具有读取权限，则 SSH 客户端将无法运行。
发布 ssh 公钥是否完全安全？
不，但是您无论如何都可以放心（很多人都这样做，只需查看https://sks-keyservers.net/i/或https://pgp.mit.edu/）
它不完全安全的原因是，如果我知道你的公钥，我可以通过巧妙的数学计算出你的私钥。你的公钥包含一个大数 n，它基本上是两个素数的乘积，如果我找到这两个素数，我可以很容易地找到你的私钥。
不用担心的原因：当 n = 21 时，很容易找到n的因数，但当n是 4096 位长的数字时，则要困难得多。目前在世或已死的数学家都没有发表过一种方法，可以在可接受的时间内计算出如此大的数字。使用最广为人知的方法，我们早就死了，早在任何人发现构成你的n的因素之前。
有人找到分解大数的捷径并非完全不可能。如果发生这种情况，RSA 将一文不值。在此之前，您不必担心。
SSH 使用 RSA（或其他签名方案）和 Diffie Hellman（用于会话密钥交换）。Diffie Hellmann 密钥交换的 1024 位（在数学上与 RSA 有点不同）可能不再足够大。这是因为一些使用 Diffie Hellman 的 ssh 实现（和 ssl 实现，如果我没记错的话）重用了一些常量，而不是随机选择它们，一旦有人建造了一台机器来进行必要的计算，他们就可以破坏基于这些常量的所有加密。1024 位仍然需要大量的计算能力来分解或计算离散对数（以及数十亿美元来构建机器以快速完成），但对于某些州级参与者来说可能是值得的，因为只是解决了一些问题实例会破坏如此大量的加密会话。
RSA 密钥也是如此。我认为 1024 位数尚未在公开场合被分解，但它可能即将出现，这意味着预算非常大的机构现在可能有可能分解 1024 位数，尽管数量不多。
（编辑：澄清了最后一段的意思并更正了RobIII指出的错误）
没有什么是“完全安全的”；问题是它是否会增加任何额外的风险。
SSH 协议仅在与服务器协商对称会话加密密钥后才发送客户端的公钥加密。因此，窃听连接的对手不会了解客户端的公钥。这意味着发布它确实会给对手额外的信息，否则他们不会有。
但是对手能用这些额外的信息做什么呢？好吧，这一切都取决于攻击者能否破解 RSA。让我们考虑两个子情况。（我假设服务器和客户端的 RSA 密钥都足够大，首先是安全的——2048 位或更多。）
通过一般攻击，我的意思是无论您使用什么密钥都会破坏 RSA。例如，这类似于解决RSA 问题的有效算法（例如，多项式时间素数分解算法）或通过构建实用的量子计算机。
在这种情况下，是否发布客户端公钥并不重要，因为 SSH 和所有其他使用 RSA 的应用程序都会被完全破坏。所以没有额外的风险。
这是一个现实生活中的问题。有些系统由于错误的密钥生成算法或错误的随机数生成器，选择了实际上容易受到攻击的 RSA 密钥。最值得注意的例子是Debian GNU/Linux 发行版在近两年（2006 年 9 月至 2008 年 5 月 13 日）中附带了一个弱随机数生成器。 2011 年对公共互联网中 710 万个 RSA 密钥的调查发现，他们看到的 1024 个 RSA 公钥中约有 0.4% 是弱密钥。
如果您的客户端公钥是如此弱的密钥并且您发布了它，那么获得它的攻击者可能会知道并利用这一事实。然后，他们将能够登录到您使用该密钥进行身份验证的 SSH 服务器。这确实是一个额外的风险。
如果您的服务器的公钥如此弱，那么该服务器是不安全的；攻击者可以窃听连接，这使他们无论如何都可以学习您的公钥。所以在这种情况下没有额外的风险。
发布 SSH 客户端公钥的额外风险很小但不是零。最大的风险是您的客户端公钥很弱，这是由错误的软件引起的。如果您要发布客户端公钥，您可能需要采取措施确保您的密钥不是弱密钥。例如：
如果您为服务 A 和服务 B 使用相同的公钥，并且您的公钥被泄露，这会将您的两个帐户交叉链接在一起。
希望这两种服务都不令人尴尬。但即使在这种情况下，如果攻击者想攻击你，这也将给攻击者一个更好的线索，让他有朝一日要破解哪些帐户。