ssh链接有证书的服务器_如何使用SSH证书进行可扩展，安全和更透明的服务器访问

ssh链接有证书的服务器

SSH is the standard tool used by pretty much anyone accessing the server. Yet very few people know about SSH certificates. We are still stuck with copying and pasting our public key to the server, which isn’t the most efficient, scalable, or transparent method.

SSH是几乎所有访问服务器的人使用的标准工具。 但是很少有人知道SSH证书。 我们仍然坚持将公钥复制并粘贴到服务器上，这不是最有效，可扩展或透明的方法。

What’s the problem with the good old way of copying and pasting keys?

旧的复制和粘贴密钥的方法有什么问题？

• Scalability: It’s not very manageable when there are multiple servers and multiple users.

  可伸缩性 ：当有多个服务器和多个用户时，它不是很容易管理。

• Security: There is no check on the server’s identity. When you connect to myserver.com, there is no authenticity that you are in fact connecting to the server you intended. Also, once you have added the user’s public key to the server, there is no way to have a 2FA, which is very essential now.

  安全性：不检查服务器的身份。 当您连接到myserver.com ，实际上并没有连接到您想要的服务器的真实性。 另外，一旦将用户的公钥添加到服务器，就无法拥有2FA，这在现在非常重要。

• Flexibility: There is no way to give time-based access. Sometimes you might have a requirement to give access for an hour or so. You can’t really do that.

  灵活性 ：无法授予基于时间的访问权限。 有时，您可能需要提供一个小时左右的访问权限。 你真的不能那样做。

• Transparency: The ssh auth logs can be found at /var/log/auth.log. Try figuring out who logged to the server and when. It’s doable, but it’s not an easy task. If it’s not easy to figure out, it’s not transparent.

  透明度 ： ssh身份验证日志可以在/var/log/auth.log找到。 尝试找出谁登录到服务器以及何时登录。 这是可行的，但这并不是一件容易的事。 如果不容易弄清楚，那就不是透明的。

Now how does an SSH certificate solve this? Let’s set up certificate-based authentication and find out.

现在，SSH证书如何解决此问题？ 让我们设置基于证书的身份验证并进行查找。

Using simple key SSH, there are two players:

使用简单密钥SSH，有两个参与者：

• Client (i.e., your pc/laptop)
  客户端(即您的PC /笔记本电脑)
• Server
  服务器

The client logs into the server when the server recognises the client’s public key and the client can prove that it is, in fact, the owner of the public key.

当服务器识别出客户端的公共密钥，并且客户端可以证明它实际上是公共密钥的所有者时，客户端便会登录到服务器。

For SSH certificates, we have one more player:

对于SSH证书，我们还有一个播放器：

• A certificate authority (CA)
  认证中心(CA)

What’s the role of the certificate authority? The server no longer needs to recognise every client’s public key but only needs to recognise the certificate authority (or the CA’s public key).

证书颁发机构的作用是什么？ 服务器不再需要识别每个客户端的公共密钥，而只需要识别证书颁发机构(或CA的公共密钥)。

Now if we don’t add the client’s public key to the server, how can the server decide who to give access to?

现在，如果我们不将客户端的公钥添加到服务器，则服务器如何确定授予访问权限的人？

CA issues certificates to the client, and the client presents that certificate to the server. If the server recognises the certificate issuing the CA and the certificate is valid (i.e., has a valid signature, is not expired, and some other important things), then the server allows access.

CA向客户端颁发证书，然后客户端将该证书提供给服务器。 如果服务器识别出颁发CA的证书，并且该证书有效(即具有有效签名，未过期以及某些其他重要内容)，则服务器将允许访问。

One more important thing to note here is that using certificates won’t eliminate keys. Keys are still used in the same way for encryption. Certificates are added for some additional functionality, like access management, access expiration, etc.

这里要注意的另一件事是使用证书不会消除密钥。 密钥仍以相同的方式用于加密。 为某些附加功能添加了证书，例如访问管理，访问到期等。

设定步骤 (Setup Steps)

Steps to set up SSH certificate infrastructure:

设置SSH证书基础结构的步骤：

1. Set up a certificate authority.
   设置证书颁发机构。
2. Configure the server to recognise the CA.
   配置服务器以识别CA。
3. Issue client certificates.
   颁发客户端证书。

1.设置证书颁发机构 (1. Set Up a Certificate Authority)

A certificate authority is simply a public and private key pair. The private key is used to sign certificates and the public key, which is to be distributed through secure channels, will be used to verify the certificate’s signature.

证书颁发机构只是一个公钥和私钥对。 私钥用于对证书进行签名，而公钥将通过安全通道进行分发，将用于验证证书的签名。

Why distribute through secure channels when the public key is supposed to be shared publicly?

当公钥应该公开共享时，为什么要通过安全通道进行分发？

The problem here is not the confidentiality of the public key (it isn’t confidential). The problem we have is the integrity of the public key. If not distributed securely, it can be tampered with or replaced with another key. If a server has the wrong public key configured (whose private key is in the hands of someone else), the server is trusting that someone else.

这里的问题不是公钥的机密性(不是机密性)。 我们面临的问题是公钥的完整性。 如果分发不安全，则可以对其进行篡改或替换为其他密钥。 如果服务器配置了错误的公钥(其私钥在其他人的手中)，则该服务器将信任其他人。

For implementation, you can create a CA on your local machine.

为了实现，您可以在本地计算机上创建一个CA。

Generate a key pair using:

使用以下命令生成密钥对：

ssh ssh-keygen -t rsa -f ca_key

ssh ssh-keygen -t rsa -f ca_key

This will create two files in the directory: the public key ca_key.pub and the private keyca_key. And you have your own certificate authority. Secure this directory with the right permissions.

这将在目录中创建两个文件：公钥ca_key.pub和私钥ca_key 。 并且您拥有自己的证书颁发机构。 使用正确的权限保护此目录。

2.配置服务器以识别CA (2. Configure Server to Recognise the CA)

For configuring the server with the newly created CA, you simply need to add the CA’s public key as TrustedUserCAKeys in SSH config /etc/ssh/sshd_config.

要使用新创建的CA配置服务器，只需在SSH config /etc/ssh/sshd_config中将CA的公钥添加为TrustedUserCAKeys 。

Create a file /etc/ssh/ca.pub and paste the CA’s public key in this file now.

创建一个文件/etc/ssh/ca.pub然后将CA的公钥粘贴到该文件中。

Now add TrustedUserCAKeys /etc/ssh/ca.pub at the end of /etc/ssh/sshd_config .

现在，在/etc/ssh/sshd_config的末尾添加TrustedUserCAKeys /etc/ssh/ca.pub 。

Make sure you restart the sshd service using sudo service sshd restart.

确保使用sudo service sshd restart sshd服务。

And you have configured the server to trust your CA.

并且您已将服务器配置为信任您的CA。

3.颁发客户证书 (3. Issue Client Certificates)

This will be done at the CA server. I am assuming you are using your local system as the CA for now.

这将在CA服务器上完成。 我假设您现在使用本地系统作为CA。

Head over to the CA’s folder where you have generated CA keys. You will sign the certificate using the CA’s private key. You also need to pass the client’s public key, which will be signed, and some other parameters.

转到生成CA密钥的CA文件夹。 您将使用CA的私钥在证书上签名。 您还需要传递将被签名的客户端的公共密钥以及其他一些参数。

Your default SSH public can be found at ~/.ssh/id_rsa.pub, assuming that exists.

您可以在~/.ssh/id_rsa.pub找到默认的SSH公用程序(假定存在)。

• -s : private key used to sign the certificate

  -s ：用于签署证书的私钥

• -I : identity (This will be shown in all logs, so make it something meaningful, like the name of the dev.)

  -I ：身份(将在所有日志中显示，因此请使其有意义，例如开发人员的名称。)

• -n : principals (It denotes what users have access to on the server, and accepts multiple comma-separated values.)

  -n ：主体(它表示用户可以在服务器上访问的内容，并接受多个逗号分隔的值。)

• -V : validity (+1d denotes valid from now to one day from now.)

  -V ：有效期( +1d表示从现在到现在的一天有效。)

• -z : serial number (When you issue multiple certificates to a single client, this can help in tracking. It will also be logged along with identity.)

  -z ：序列号(当您向单个客户端颁发多个证书时，这可以帮助进行跟踪。它还将与身份一起记录。)

This command will generate a certificate at Users/aakash/.ssh/id_rsa-cert.pub.

此命令将在Users/aakash/.ssh/id_rsa-cert.pub生成证书。

Now you can simply SSH at ubuntu@myserver.com and you’ll be given access, but only from now to a day from now. The certificate will expire after that, and you will no longer have access. You will need to get a new certificate after that.

现在，您只需在ubuntu@myserver.com SSH即可获得访问权限，但仅从现在到现在为止。 证书将在此之后过期，并且您将不再具有访问权限。 之后，您将需要获取新证书。

Let’s pause for a bit and see what problems we have solved.

让我们稍停片刻，看看我们已经解决了什么问题。

• Scalability: You can create a CA server (ensure the security of this server, and if possible, only allow access through a VPN or local network) with exposing a web application that will authenticate organisation users, ask for a 2FA, and then issue certificates accordingly. Maybe put in a Google OAuth with 2FA enabled if you use G Suite. This system becomes very scalable.

  可伸缩性 ：您可以创建一个CA服务器(确保此服务器的安全性，并在可能的情况下仅允许通过VPN或本地网络进行访问)，并公开一个将对组织用户进行身份验证的Web应用程序，要求提供2FA，然后颁发证书相应地。 如果您使用G Suite，则可以放入启用2FA的Google OAuth。 该系统变得非常可扩展。

• Security: By issuing certificates only for a small period, you will minimise the risk of unauthorised access to servers in case laptops are lost or stolen.

  安全性 ：通过仅短期颁发证书，可以最大程度地降低笔记本电脑丢失或被盗时未经授权访问服务器的风险。

• Flexibility: With all the options you can configure the certificate with, you achieve flexibility.

  灵活性 ：使用所有可以配置证书的选项，您可以实现灵活性。

• Transparency: Now when you check logs, you will see messages like this:Accepted publickey for ubuntu from 106.202.115.141 port 48343 ssh2: RSA-CERT ID AakashsLaptop (serial 1) CA RSA SHA256:dfewVbDnh2OuOdY9AEwJJHoUfhPuqp/M2NIBRWX4Nf4 , which is clearly much easier to debug.

  透明度 ：现在，当您检查日志时，您将看到以下消息： Accepted publickey for ubuntu from 106.202.115.141 port 48343 ssh2: RSA-CERT ID AakashsLaptop (serial 1) CA RSA SHA256:dfewVbDnh2OuOdY9AEwJJHoUfhPuqp/M2NIBRWX4Nf4很容易，调试。

But there are still two issues in our current setup:

但是我们当前的设置中仍然存在两个问题：

• Host verification: Our current setup still doesn’t have any provision for verifying the host’s identity.

  主机验证 ：我们当前的设置仍然没有任何验证主机身份的规定。

• Multiple servers with same username: It is very likely that you have multiple servers with the same username (ubuntu , root ). If you issue a certificate with principals ubuntu, you will be giving access to all the servers that trust your CA for ubuntu user.

  具有相同用户名的多个服务器 ：您很有可能拥有具有相同用户名的多个服务器( ubuntu ， root )。 如果您使用主体ubuntu颁发证书，则将授予对ubuntu用户信任您的CA的所有服务器的访问权限。

主机验证 (Host Verification)

When you connect for the first time to a server, you will be shown a message like this:

首次连接到服务器时，将显示以下消息：

This says that the server you’re connecting can’t be verified, though that it is in fact the server you intend to connect to. You are supposed to manually match this key fingerprint (SHA256 hash of the public key) with your server’s public key. Have you ever done that? Most of the time, the answer is no.

这表示您正在连接的服务器无法验证，尽管实际上它是您要连接的服务器。 您应该手动将此密钥指纹(公共密钥的SHA256哈希)与服务器的公共密钥进行匹配。 你做过吗？ 在大多数情况下，答案是否定的。

Once you say yes, it will save the public key in ~/.ssh/known_hosts and won’t ever ask you again. If you want to see this message, simply head to this file and delete the line with the server you are connecting to.

一旦您说“是”，它将把公钥保存在~/.ssh/known_hosts ，再也不会询问您了。 如果要查看此消息，只需转到此文件，然后删除与您要连接的服务器的行。

You’ve seen what the problem is with the current way, so now try the certificate way. Just as you issued a certificate to the client, you’ll issue a certificate to the host. There is one minor difference. The principals that contained the usernames a client is authorised for will, for the host certificate, contain hostnames.

您已经了解了当前方式的问题，因此现在尝试使用证书方式。 就像您向客户端颁发证书一样，您也将向主机颁发证书。 有一个小的区别。 对于主机证书，包含授权客户端使用的usernames的主体将包含hostnames 。

You have to copy the server’s host public key to a file to the CA for signing and then transfer the signed certificate back to the server. You can find the server’s host keys in /etc/ssh/. An ls command will give something like this:

您必须将服务器的主机公共密钥复制到一个文件中，然后将其复制到CA中以进行签名，然后将已签名的证书传输回服务器。 您可以在/etc/ssh/找到服务器的主机密钥。 ls命令将给出以下内容：

You will notice there are many host keys. That’s because the server has to support different types of algorithms. For the sake of this tutorial, just pick ssh_host_rsa_key.pub.

您会注意到有很多主机密钥。 那是因为服务器必须支持不同类型的算法。 为了本教程的缘故，只需选择ssh_host_rsa_key.pub 。

Copy it to a file on CA server and run the command:

将其复制到CA服务器上的文件并运行以下命令：

-h : flag to indicate you are signing host key

-h ：标志，指示您正在签名主机密钥

-Z : to bind the certificate to a host (here I have used *.mydomain.com to denote all subdomains of mydomain.com)

-Z ：将证书绑定到主机(在这里我使用*.mydomain.com表示mydomain.com所有子域)

This will create a ssh_host_rsa_key-cert.pub, which you will have to copy to server (in /etc/ssh/ directory). You’ll also need to add it as HostCertifcate in sshd_config, like this:

这将创建一个ssh_host_rsa_key-cert.pub ，您必须将其复制到服务器(在/etc/ssh/目录中)。 您还需要将其作为HostCertifcate添加到sshd_config ，如下所示：

Changes in config only are reflected after you restart the sshd service.

重新启动sshd服务后，仅反映配置中的更改。

Now that the server has a host certificate, we also need to configure the client to trust the CA’s public key. Add a line with the CA’s public key in ~/.ssh/known_hosts, as follows:

现在服务器已经有了主机证书，我们还需要配置客户端以信任CA的公钥。 在~/.ssh/known_hosts添加带有CA ~/.ssh/known_hosts ，如下所示：

Now when you connect ssh ubuntu@dev.mydomain.com, the host will present the host certificate. You no longer will see the “host authenticity can’t be verified” message because host verification is handled automatically. If you still see this message, don’t blindly click on yes. Check why you are facing this issue.

现在，当您连接ssh ubuntu@dev.mydomain.com ，主机将出示主机证书。 您将不再看到“无法验证主机真实性”消息，因为主机验证是自动处理的。 如果您仍然看到此消息， 别 盲目地单击是。 检查为什么您遇到此问题。

具有相同用户名的多个服务器 (Multiple Servers With the Same Username)

When you issue a certificate with usernames, let’s say root , you will be giving access to all your servers that trust your certificate authority.

当您使用用户名颁发证书时(例如root ，您将授予对信任证书颁发机构的所有服务器的访问权限。

Instead of issuing the certificate username in principals, you need to create a strategy for principals and map those to usernames. You can do this by using AuthorizedPrincipalsFile. Just add this in the sshd_config of the server:

代替在主体中颁发证书username ，您需要为主体创建策略并将其映射到用户名。 您可以使用AuthorizedPrincipalsFile来做到这一点。 只需将其添加到服务器的sshd_config中：

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

When you ssh ubuntu@myserver.com, the certificate server will look to see if woobly-super is in the file etc/ssh/auth_principals/ubuntu (notice %u in config). If the file has woobly-super, then you will be logged in.

当您ssh ubuntu@myserver.com ，证书服务器将查看woobly-super是否在etc/ssh/auth_principals/ubuntu (注意配置中的%u )。 如果文件具有woobly-super ，那么您将登录。

You can get certificate info using ssh-keygen -L -f <CERT_PATH>

您可以使用ssh-keygen -L -f <CERT_PATH>获取证书信息。

Let’s devise a principals strategy. A typical scenario is that some users are allowed to access some servers based on roles, and some are allowed to access all servers on a project.

让我们设计一个原则策略。 典型的情况是，允许某些用户基于角色访问某些服务器，而允许某些用户访问项目中的所有服务器。

Typically, some developers are allowed to access only dev servers, DBAs are allowed to access only database servers, QAs are allowed to access only testing servers, and a small group of people is allowed to access all the servers, including production servers.

通常，允许某些开发人员仅访问开发服务器，允许DBA仅访问数据库服务器，允许QA仅访问测试服务器，并允许一小部分人访问所有服务器，包括生产服务器。

One way to do things can be to create principals for each group and issue certificates with principles accordingly:

一种处理方法是为每个组创建委​​托人，并根据相应的principles颁发证书：

• project-dev : project developers

  project-dev ：项目开发人员

• project-dba : database administrators

  project-dba ：数据库管理员

• project-qa : project testers

  project-qa ：项目测试人员

• project-super : people supposed to have access to all servers

  project-super ：人们应该可以访问所有服务器

Now for the different types of server, create principals file (/etc/ssh/auth_principals/ubuntu) and put principals like this : (\n is for the next line, as you have to put one principal per line)

现在，针对不同类型的服务器，创建主体文件( /etc/ssh/auth_principals/ubuntu )并放置以下主体：( \n用于下一行，因为您必须在每行中放置一个主体)

• Dev servers: project-dev\nproject-super

  开发服务器： project-dev\nproject-super

• Database server: project-dba\nproject-super

  数据库服务器： project-dba\nproject-super

• Testing servers: project-qa\nproject-super

  测试服务器： project-qa\nproject-super

• Production servers: project-super

  生产服务器： project-super

This can vary based on your requirements. Maybe developers also have access to a database server, or testing servers, or some other possibility — adjust accordingly.

这可能会根据您的要求而有所不同。 也许开发人员也可以访问数据库服务器，测试服务器或其他可能性-进行相应调整。

Warning: Even when using AuthorizedPrincipalsFile, if a certificate is presented with a username (let’s sayubuntu ) in principals, it will still work. So make sure never to issue certificates with usernames.

警告：即使使用AuthorizedPrincipalsFile ，即使证书在主体中带有用户名(比如ubuntu )，它仍然可以使用。 因此，请确保不要颁发带有usernames证书。

You can also restrict what command will be executed through force-command in Critical Options. Let’s say someone is only allowed to deploy on a server. You can issue a certificate for that.

您还可以通过“ Critical Options force-command限制执行什么命令。 假设只允许某人部署在服务器上。 您可以为此签发证书。

It might be overwhelming at first, but the benefits surpass any initial complexity involved. So that’s how SSH certificates deliver scalable, secure, flexible, and transparent infrastructure.

起初它可能会让人不知所措，但是好处超过了最初涉及的任何复杂性。 这就是SSH证书提供可伸缩，安全，灵活和透明的基础结构的方式。

翻译自: https://medium.com/better-programming/how-to-use-ssh-certificates-for-scalable-secure-and-more-transparent-server-access-720a87af6617

ssh链接有证书的服务器