如何用Monkeysphere验证SSH服务器身份的Ubuntu VPS

介绍

随着组织的发展,管理大量的SSH密钥和服务器可能非常困难。 在整个组织中正确识别有效密钥和删除无效密钥可能会遇到错误,并对服务器安全造成严重后果。

此外,当有服务器更改时,有时您的用户将收到关于无法确定您的服务器的真实性的警告。 大多数用户在连接前不会重复检查服务器的密钥指纹,允许某人潜在地欺骗服务器并执行中间人攻击。

所谓monkeysphere的项目是为了解决这些问题。 它通过利用GPG密钥和信任模型网络来验证服务器的凭据,并提供简单的用户管理。

在本指南中,我们将讨论如何设置monkeysphere以便为用户验证服务器。 这将解决用户不得不猜测他们连接到的服务器是否实际上是他们试图访问的问题。 通常,当您第一次连接到服务器时,您将看到如下所示的内容:

The authenticity of host '107.170.43.127 (107.170.43.127)' can't be established.
ECDSA key fingerprint is 10:14:75:d6:42:a3:c5:59:d1:83:6d:cf:52:61:4a:52.
Are you sure you want to continue connecting (yes/no)?

我们将在本文中工作,以避免向我们的用户显示这些消息。 在以后的指南中,我们将讨论如何解决容易识别和验证用户的问题

我们将使用Ubuntu 12.04 VPS实例来配置此系统。 我们将有一个SSH服务器,我们将尝试验证给我们的用户。 我们还需要两个其他机器来演示(无论是本地计算机还是VPS实例)。 一个将是管理员的计算机,另一个将是客户端,我们将用作测试机,以查看我们的信任网是否允许其验证服务器的身份。

基本策略

整个monkeysphere系统依靠GPG密钥和密钥服务器来工作。 在开始之前,您必须为每个系统配置这些键。 许多实际配置也将通过这些键完成。

你开始用GPG工作之前,你可能想看看我们的文章如何使用GPG键 我们将给你所需的具体命令,但是更深入的了解正在发生的情况可能有助于您排除故障时遇到问题。

我们的三台机器及其用途将是:

  • server.example.com:我们要验证给客户端的SSH服务器。
  • admin.example.com:将使用配置访问我们的管理员计算机。 这通常是您的家用电脑,但我们将在我们的指南中使用另一Droplet。
  • client.example.com:这是我们将使用测试我们对验证客户端。 我们希望此计算机能够连接到服务器,而不会收到未知的主机警告。

SSH服务器机器应具有可公开访问的域名。 使用本指南建立在DigitalOcean域名

对于第一部分,我们要在管理和客户端计算机上生成密钥。 然后我们将这些密钥上传到集中式密钥服务器。 我们将从密钥服务器下拉管理员的密钥,并使用客户端密钥签署和信任它,表明我们的客户端信任我们的管理员。

这是整个验证方案的基础。 我们不是信任计算机或密钥,而是利用GPG的信任网模型。 如果您认为某人对您尝试连接的服务器非常了解并且值得信赖,您可以推迟该人通知您服务器是否合法。 在这种情况下,我们的客户端将相信服务器管理员可以验证服务器的身份。

然后,我们可以配置monkeysphere使用GPG框架下拉信息,以验证我们信任的管理员对我们尝试连接的服务器的支持。

设置GPG密钥和身份验证

幸运的是,GPG默认安装在Ubuntu上。

我们将首先在客户端系统和管理员系统上创建一些GPG密钥。 这些密钥与单个用户相关联,并用于全局地标识该用户。 每个需要访问您的SSH服务器的人都应该有识别它们的GPG密钥。 这就是我们如何建立我们的信任网。

生成GPG密钥

我们需要在客户端计算机和管理计算机上创建GPG密钥。 这两个计算机的以下动作:

gpg --gen-key

这将提示您一些问题,以创建您的密钥对。 首先,它会询问您希望创建哪种类型的键。 选择“1”创建两个RSA密钥。 在下一个问题中接受默认值以生成2048位密钥。 选择“0”使密钥永不自动过期,然后键入“Y”确认信息正确。

接下来,系统会要求您为这些用户提供您的信息。 我们将用名“admin”和电子邮件地址“ admin@fakedomain.com ”我们的管理员的钥匙。 对于我们的客户,我们将使用的名称为“客户”和电子邮件“ client@fakedomain.com ”。 你有机会添加一个可选的注释,然后你应该键入“O”表示信息是好的。

输入并确认密码以保护密钥。

计算机现在将使用从系统收集的随机数据片段创建密钥。 这被称为“熵”并且用于创建真正随机的密钥。 可能需要一段时间。 有时,使用单独的SSH会话登录以执行某些工作以加快进程是有帮助的。

当密钥生成后,它将存储在您的GPG密钥环中。 您可以通过输入以下命令查看:

gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   2048R/08D014B3 2014-03-14
uid                  client <client@fakedomain.com>
sub   2048R/4C73683E 2014-03-14

上面红色的部分是缩短的密钥ID。 我们可以使用这个哈希来引用这个键。

我们应该将密钥上传到密钥服务器。 这些密钥服务器被复制到世界各地,允许任何人下拉我们的关键信息。 这是我们想要的,因为它允许我们的两个用户和SSH服务器相互交互和建立信任关系。

要将我们的密钥上传到密钥服务器,在我们的客户端和管理计算机上,我们需要输入这样的内容。 我们需要上面提到的密钥ID:

gpg --send-key key_id

因此,对于上面的客户端密钥,我们可以通过键入以下内容将其上传到密钥服务器:

gpg --send-key 08D014B3

签署密钥

现在,我们的管理员和我们的客户端都有GPG密钥,并已将其上传到密钥服务器,它们将开始传播到世界各地的其他密钥服务器。 可能需要一些时间将每个密钥复制到世界各地的GPG服务器,因此您可能需要等待几分钟才能执行这些步骤。

等待几分钟后,您可以尝试在每台计算机上拉下相反的键。 这意味着,在客户端计算机上,尝试拉下管理员的密钥。 您还应该拉下管理员计算机的客户端密钥。

我们将签署这些密钥,这意味着我们认为它们有效,并且已经验证它们是我们试图识别的人的正确密钥。 为了绝对确保你得到正确的密钥,我们将做到这一点没有搜索,并通过其指纹识别它指定确切的关键。

在客户端服务器上,通过键入GPG密钥获取指纹。 “客户端”是您在建立密钥时选择的名称或电子邮件地址:

gpg --with-colons --fingerprint client
tru::1:1394819815:0:3:1:5
pub:u:2048:1:4B3F73E208D014B3:2014-03-14:::u:client <client@fakedomain.com>::scESC:
fpr:::::::::85ECDB498FB0CAB5F02989E64B3F73E208D014B3:
sub:u:2048:1:254105194C73683E:2014-03-14::::::e:

上面突出显示的输出部分是您要查找的指纹。

现在您已经拥有此指纹,在管理员的计算机上,您可以告诉GPG使用该指纹查找密钥,并将其下拉到本地计算机,如下所示:

gpg --recv-keys 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

这将连接到默认密钥服务器,并要求由该指纹识别的密钥。 它将被转移到我们的本地系统。

现在我们可以访问密钥,我们可以签名,以指示我们作为管理员,信任属于客户端的密钥:

gpg --sign-key 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

现在,我们已经在我们的本地系统上签了钥匙。 我们现在应该将客户端的密钥发送回密钥服务器。 密钥服务器将更新其关于客户端密钥的信息,以指示我们的管理员帐户已对密钥签名并认为其有效。

要将签名密钥发送回密钥服务器,我们键入:

gpg --send-key 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

密钥服务器现在具有我们的管理员密钥和客户端密钥,就像以前一样。 所不同的是,该密钥服务器现在具有从在客户端密钥管理员密钥的签名。

我们现在需要做相反的操作(用客户端密钥签署管理员的密钥)。 为此,在管理员的计算机上,我们获取管理员密钥指纹:

gpg --with-colons --fingerprint admin

现在,在客户端机器上,我们使用从输出中收集的指纹,下拉,签名,然后上传管理员的密钥,就像我们以前做的一样:

gpg --recv-keys 7C873BB244245CB13BFEFC31F7C66E2FF945A061
gpg --sign-key 7C873BB244245CB13BFEFC31F7C66E2FF945A061
gpg --send-key 7C873BB244245CB13BFEFC31F7C66E2FF945A061

随后,在两台机器上,我们需要更新我们的钥匙。 这是因为我们的每个用户都有他们的密钥签名,但他们没有在自己的计算机上的签名,只是在对面的计算机和密钥服务器。 您将需要等待几分钟,让您的更改传播,然后键入:

gpg --refresh-keys

您需要验证是否已处理更新。 输出应该有一行说“新签名:1”。 如果不存在,请重试,直到它显示。

现在,您的每台计算机都应该有两个签名的密钥。

信任署长的判决

为了使我们的信任网真正工作,我们不仅要让客户签署管理员的密钥,我们还必须确定客户端“信任”管理员的判断。

这意味着,当管理员说SSH服务器是它说,这是我们作为客户机,可以相信签名另一人 ,管理员,使得机器。

首先,我们可以通过键入以下内容在我们的客户端上查看当前设置:

gpg --check-trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u

这是一个非常混乱的信息。 第一行说明我们正在运行的信任模型。 基本上,如果我们有一个由一个完全信任的用户签名的密钥,那么我们将认为该密钥有效。 我们也可以信任一个密钥,如果它由至少3个人签署,我们只是微不足道的信任。

第二行告诉我们关于我们的“深度0”信任级别。 这基本上是关于我们自己的密钥的信息。 我们认为它有效并签字。 而“信任”部分告诉我们,密钥是在“u”类别,意味着最终信任。

第三行告诉我们关于“深度1”的键。 这些是我们亲自签署的钥匙。 我们可以看到,我们认为一个密钥有效(我们签署了管理密钥以使其有效),并且管理密钥尚未签署任何我们关心的其他密钥。

在该行的信任部分中,我们有一个具有“1-”的字段。 这意味着我们在这个级别上的一个键(管理键)没有被给予信任设置。 我们不知道在这个关键字中放置什么级别的信任。

我们想完全信任管理员密钥。 这样,管理员签名的任何密钥(例如我们尝试验证SSH身份的SSH服务器)将被我们认为是合法的。 为此,我们可以在客户端计算机上更新我们的信任数据库:

gpg --update-trustdb

您将要求为您签名的,当前没有信任值的任何密钥分配信任等级。 它将如下所示:

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
No trust value assigned to:
2048R/49E95F19 2014-03-14
      "admin <admin@fakedomain.com>"
 Primary key fingerprint: A612 56B8 5307 B7ED 9AD8  D93E 9E06 881E 49E9 5F19

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  s = skip this key
  q = quit

Your decision?

我们想完全信任这个键,所以输入“4”。

现在,由于我们信任管理员的判断,我们可以合理地确保管理员签名的密钥与所讨论的用户或服务正常关联(通常我们使用真实名称,而不是客户端或管理员)。

安装Monkeysphere和配置SSH服务器

现在我们已经让我们的客户端和管理员计算机设置了他们的GPG密钥,我们可以开始实际的monkeysphere安装和配置。

在Ubuntu的默认存储库中有一个monkeysphere包。 它包含SSH使用GPG进行验证所需的服务器和客户端实用程序。 因此,我们需要在我们的每台计算机上安装该软件包。

在此模型中的所有计算机(管理员,客户端,SSH服务器)上,通过键入以下命令安装monkeysphere:

sudo apt-get update
sudo apt-get install monkeysphere

我们现在有必要的组件把这些片放在一起。 在SSH服务器上,我们将使用monkeysphere中包含的wrapper实用程序生成一个特殊的GPG密钥。 所产生的密钥将基于该的ssh_host_rsa_key用于标识服务器到客户端。

在SSH服务器上,键入:

monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key ssh://server.example.com

上面的第二个组件应该指示SSH服务器的域。 这将帮助客户端在尝试验证服务器连接时找到正确的服务器密钥。

现在,我们可以再次将我们刚刚创建的密钥上传到公钥服务器。 这一次,我们将再次使用包含在monkeysphere套件中的包装程序:

monkeysphere-host publish-key

这将上传您的服务器密钥,并将其提供给希望连接的客户端。

将服务器密钥验证为服务器管理员

现在,我们将SSH服务器的密钥传播到世界的密钥服务器。 但是这如何帮助我们?

那么,GPG的工作方式是通过建立它所谓的“信任网”。 简单地说,它的工作原理是建立一个人的网络,你知道,你的身份,你可以验证高度的确定性。 然后,它使用这些信任关系,让您将知道信息的责任转移给您信任的人。

在我们的例子中,我们(作为这个例子的客户端)卸载知道服务器是否合法的责任到我们的管理员,我们信任谁。 服务器的管理员应该有一个好主意是否服务器的凭据签出。

所以我们现在需要做的是签署SSH服务器的GPG密钥作为服务器管理员,这将允许我们的客户端用户通过信任管理员验证服务器的身份。

在SSH服务器上,键入以下命令获取GPG指纹:

monkeysphere-host show-key
pub   2048R/0D281337 2014-03-14
uid                  ssh://fakedomain.com
OpenPGP fingerprint: E06A426459E584F272DB708AD2D462790D281337
ssh fingerprint: 2048 61:1e:a7:66:1d:04:64:80:3f:27:81:34:31:78:8d:df (RSA)

“OpenPGP指纹”与我们的GPG指纹相同。 这是我们将使用把钥匙下拉到我们的管理员的计算机并签名。

在管理员的计算机上,键入以获取SSH服务器的密钥。 再次,您可能需要等待几分钟:

gpg --recv-key E06A426459E584F272DB708AD2D462790D281337

我们将签署密钥,就像我们上面用客户端密钥:

gpg --sign-key E06A426459E584F272DB708AD2D462790D281337

最后,我们需要记住将签名密钥上传到密钥服务器:

gpg --send-key E06A426459E584F272DB708AD2D462790D281337

从客户端验证SSH服务器的身份

现在,我们有一切适当的地方从客户端计算机验证SSH服务器的身份。

为此,我们必须在一个monkeysphere实用程序中包装SSH命令。 这将告诉我们的客户端使用monkeysphere来检查我们尝试ssh进入的服务器的GPG密钥。 然后它会看到我们是否信任任何确认服务器有效的人。

我们将手动第一次手动显示发生了什么。 之后,我们可以将其添加到文件中以自动执行此操作。

在客户端上,键入手动命令,如下所示:

ssh -oProxyCommand='monkeysphere ssh-proxycommand %h %p' server.example.com
-------------------- Monkeysphere warning -------------------
Monkeysphere found OpenPGP keys for this hostname, but none had full validity.
An OpenPGP key matching the ssh key offered by the host was found:

pub   2048R/0D281337 2014-03-14
uid       [ unknown] ssh://server.example.com
sig!3        0D281337 2014-03-14  ssh://fakedomain.com
RSA key fingerprint is 61:1e:a7:66:1d:04:64:80:3f:27:81:34:31:78:8d:df.

-------------------- ssh continues below --------------------
The authenticity of host 'server.example.com (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is 78:50:80:60:2a:a3:51:51:37:9d:25:8b:d4:0c:d1:15.
Are you sure you want to continue connecting (yes/no)?

在这里输入“no”。

正如你可以看到,我们有一个通常的消息,关于我们试图连接到的主机的真实性无法建立。 我们还没有解决这个问题,还没有验证服务器的身份,所以我们必须输入“no”保护我们自己不要连接到错误的主机。

但是,我们还在“Monkeysphere警告”部分标题下获得了一个额外的信息部分。 它告诉我们,它能够检索密钥,但它无法验证服务器,因为它没有必要的信任关系。

如果我们在客户端计算机的密钥链中查看我们的密钥,我们将注意到我们现在有SSH服务器的密钥:

gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   2048R/87791BD0 2014-03-14
uid                  client &lt;client@fakedomain.com&gt;
sub   2048R/3294D31D 2014-03-14

pub   2048R/54AD641F 2014-03-14
uid                  admin &lt;admin@fakedomain.com&gt;
sub   2048R/A87CADCB 2014-03-14

pub   2048R/0D281337 2014-03-14
uid                  ssh://fakedomain.com

所以我们现在在我们的系统中的关键。 现在我们只需要刷新我们的钥匙。 这将拉入我们系统中的密钥的任何签名:

gpg --refresh-keys

你应该再次看到一条线,说:“ new signatures: 1 。” 我们可以通过检查SSH服务器密钥上可用的签名来看到这一点:

gpg --list-sigs ssh://server.example.com
pub   2048R/0D281337 2014-03-14
uid                  ssh://server.example.com
sig 3        0D281337 2014-03-14  ssh://server.example.com
sig          54AD641F 2014-03-14  admin <admin@fakedomain.com>

如您所见,我们现在看到一个“sig”行,其中列出了管理员的密钥。 由于我们的客户端信任管理员,我们现在可以通过代理信任SSH服务器。

让我们再次尝试我们的命令:

ssh -oProxyCommand='monkeysphere ssh-proxycommand %h %p' server.example.com
root@server.example.com's password:

如您所见,我们现在已经得到了密码提示,而不要求我们验证SSH服务器的有效性。 这是因为我们已通过GPG验证其身份。

为了避免在每次我们希望SSH进入服务器时键入这个长命令,我们将其添加到客户端计算机上的配置文件中:

nano ~/.ssh/config
Host *
ProxyCommand monkeysphere ssh-proxycommand %h %p

这将允许我们像通常一样通过SSH连接,并将在后台进行所有的monkeysphere验证:

ssh server.example.com

要仔细检查,这是工作,随意删除当前known_hosts文件中:

rm ~/.ssh/known_hosts

现在,重试ssh命令:

ssh server.example.com

您将登录或提示输入密码,从不询问您是否接受主机。 您还可以看到known_hosts文件已被自动重新创建该主机已添加:

cat ~/.ssh/known_hosts
server.example.com ssh-rsa AAAB3NzaC1yc2EAAAADAQABAAABAQC9aTHZmHZSgwNtwichF0AqDI74bCMtI29kqPDZaNn2r86NGIElRUlQiRImmZXs5oEjF0o8VaW6s1cIj0hC5ziDPShJ3VzZTWz9RmJ9xfPPcAPw2JbV1c1Q1bplstQqCZmFcRZyofztnP55HqOiJ4htLMxH+a9lM4AydDZtGHhzU+usxUjHniVbxCUVntpunlwtMk+Mtk9eysVdnJCJyV02/W89HExiO9QRpv+EugKN1eCQYrGvNbKWQKq4gSJ0RDwOSKNgkY/Ii0MsGJ2HuioO9np6IEdeZdgSGHPA23+zZe8asrN62iLUBADDkyIR6FAonCvfh99hbFxpNz2N8Mdb MonkeySphere2014-03-21T21:30:44

结论

如果您将组织配置为对SSH使用monkeysphere,SSH用户将永远不必质疑组织中主机的合法性。 一旦您的用户信任服务器管理员并且已将其SSH配置为依赖monkeysphere,并且假设管理员警惕签署新主机,则不应要求用户验证主机身份。

盲目接受主机作为有效的是一个巨大的风险,大多数用户将不具备合法检查服务器的身份的能力,无需管理员帮助。 因此,使用Monkeysphere,我们可以为整个组织的安全切断整个过程。

这可能看起来像很多工作,但是设置一个信任网络将变得越来越少的工作,你会去,并将允许你避免危险的中间人风格的攻击。

在接下来的文章中,我们将讨论如何使用monkeysphere给用户验证到SSH服务器

作者:Justin Ellingwood
赞(52) 打赏
未经允许不得转载:优客志 » 系统运维
分享到:

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏