(This work was completed as part of my participation in NYU Course CS GY 6813: Information Security & Privacy)

Introduction

SSH (Secure Shell) key pairs are one of the most secure ways to authenticate to a system when using the SSH protocol. When accessing a system, traditionally users would authenticate using a username and password combination, which only provides one factor authentication (something you know). If a user’s credentials were obtained and used by a bad actor (through a phishing attempt, credential dump, password crack, etc.), that threat actor would be able to trivially impersonate the original user with their full un-scoped entitlements. Additionally, just like passwords, users often reuse the same SSH key pair between multiple services and systems [3], therefore creating a single point of compromise and an increased security boundary should that credential fall out of control of the user. As mentioned by Ylonen who studied various financial intuition’s usage of SSH keys, “…many of the companies … had several million keys authorized to log in across tens of thousands, sometimes over a hundred thousand servers. In some cases a single key can access thousands of servers.” [3].

In terms of managing SSH keys from an infrastructure point of view, a user’s public portion of the key pair must be installed into each system which that user needs to access (typically by the user themselves). This method creates a circular dependency on the use of passwords to install the public key before password-less authentication (or password/key pair combination) can be used. Furthermore, this management style does not scale in large distributed systems wherein an entity might need to access any one several hundred hosts at any point (think a Kubernetes cluster) or the public key pair list could be removed when the system undergoes regular hygiene and the file system is cleared.

Hypothesis

The author of this paper proposes the broader adoption of SSH Certificates as an alternative/addition to password-based authentication and/or the use of a traditional SSH key pair. By using a SSH Certificate, an entity wanting to access a system would first declare their intent along with a public key to an authoritative system to be signed. This system would then verify the provided information and cryptographically issue a short lived (and scoped) certificate to the user.

❯ ssh-keygen -L -f ssh_rsa_cert
ssh_rsa_cert:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT SHA256:Lrn2lw7W+busYCOgHAJWGExjzm6UZ05jy1OlsiH4hZ0
        Signing CA: RSA SHA256:rL4OSRnEtMeHoiuiG8rpsUxWzSTuzNV/rKVGtNKe6fM (using ssh-rsa)
        Key ID: "vault-oidc-developerUsername@ad.mydomain.example-2eb9f6970ed6f9bbac6023a"
        Serial: 18218704284435187322
        Valid: from 2022-05-01T13:58:07 to 2022-05-01T13:58:38
        Principals:
                sharedAccountUsername
        Critical Options: (none)
        Extensions:
                permit-pty

Figure 1: Snippet of Signed SSH Certificate

The contents of a sample SSH Certificate is shown in Figure 1, including important fields such as the Key ID, Valid period, Principals (i.e., the user which the certificate can be used to authenticate as), and the allowed Extensions. For those familiar with a JSON Web Token (JWT), this format should be quite analogous. The use of a SSH Certificate signed by a trusted Certificate Authority accomplishes three main points: first, it dramatically decreases the management overhead needed to manage individual user’s SSH public keys on hosts, next it increases audit capabilities by creating an independent and immutable system recording the “signing” of a key pair to access a particular system, and finally it decreases the security boundary should a user’s private key be compromised by a bad actor.

As discussed earlier, SSH key pairs are extremely vulnerable to leakage and are traditionally high touch in terms of management across large scale distributed environments. For example, if a user is part of an application development team which needs to access six or seven different hosts (across different data centers, environments, etc.), that user’s SSH public key must be added to each different server either manually or by some other automation pipeline. Additionally, if the user no longer needs access, the administrator of the host must delete and remove that user’s key from the host. Traditionally, a first-time user would login with a keyboard authentication method, and then subsequently add their public key to the authorized_keys file in their home directory. With the proposed broader adoption of Signed SSH Certificates, authorization for accessing the system is now externalized to a third-party (e.g., Active Directory, Okta, Keycloak, etc.) where permissions can easily be added or dropped (and audited) as the role of the user changes.

Table 1: Threat Model for Public/Private Key Pairs

The threat model as described in Table 1 identifies a variety of different attack scenarios for accessing a system using traditional SSH key pairs. The model used for this paper was the STRIDE model, which is a model developed by Microsoft to realize the absence of desired security properties of a system or process. The key threats of SSH key pairs recognized by this paper are spoofing, repudiation, information disclosure, and elevation of privilege. The threats of spoofing, repudiation, and information disclosure are related to the trust and “lack of control” of a user’s key pair. Just because a public key is present on a host in the authorized_keys file, there is no guarantee that the key is “in control” by the user and has not been leaked or compromised. In terms of persistence, if a “bad” actor were able to compromise a host and inject their own public key into authorized_keys, the “bad” actor could potentially maintain access even if the “good” user used a new keypair.

Motivating Example

In the proposed example flow described in Figure 2, we assume the organization leverages Active Directory as their directory manager of choice, and the user has been added to the appropriate entitlement groups within the directory. When the user needs to access a protected resource (e.g., a database server), they will first authenticate to the identity provider (using either OAuth2 or SAML) which authenticates and later authorizes the user based on their roles within the directory, producing a JSON Web Token (JWT) with their roles and claims. The user will then use the JWT to authenticate to an application which has access to a trusted Certificate Authority’s private key. The purpose of this application is to verify the intent of the user, and eventually issue a signed certificate certifying the time to live and conditions of authentication. Upon a successful signing, the user is returned a signed certificate from the application, which they will then use as part of the authentication process to the SSH protected resource.

Figure 2: Proposed authentication & authorization flow for SSH Certificate Issuance

Besides certificates, the typical solution to “securing” SSH key pairs is the use a passphrase to encrypt the key pair. While the use of a passphrase solves for the spoofing and/or integrity, it does not address repudiation. When a public key is added into the authorized_keys file, there is no guarantee that the key(s) contained within that file are that of the user and not of a bad actor. This is because key pairs are typically generated by a user in their own environment and not generated by a trusted or auditable source. With the use of a SSH certificate and signing, a user could theoretically generate a new public and private key pair each and every time they connect to a system and it would not matter. In this case, the system/host is only checking that the key pair is accompanied by a certificate signed by a trusted authority (CA) and that the hash of the provided key pair matches contained in the certificate (as shown in Figure 2). There is no prior knowledge of the keypair’s public key pre-authentication.

Evidence

The data used for this experiment and analysis is purely anecdotal based on the experiences of the author as an engineer in the Distributed Computing and Cloud space. As with the best of security controls (and the use of Signed SSH Certificates certainly falls into this category), care must be taken to ensure that the control itself does not start to become a burden or hindrance on the user (e.g., the developer). Once the control begins to impede on productivity or ease of accessibility for the user, the user will stop following the control and start to find workarounds to avoid the complicated process. Table 2 speaks to some of this hindrance. Using a standard SSH key pair could be seen by users by allowing them to connect to a host “passwordless” in as little as fifteen seconds, while as it taking upwards of 60 seconds with the use of Signed Certificates. The added time is due to the user having to authenticate to the issuing system, provide details of the host they want to connect to, and then wait for the system to generate and sign the certificate. Some users could see this increase in time as a barrier to their productivity, when rather it should be seen as a way to decrease risk to the host and environment.

Table 2: Comparison of Developer Experience & Time using Signed SSH Certificates as compared to Public/Private Key Pairs

In terms of administrative overhead and maintenance, there is additional work that must be taken on by the Systems Administration (SA) and Cybersecurity (Cyber) teams to keep the system operational. With the use of Public/Private keypairs, there is little to no involvement by either the SA or Cyber teams when adding a new keypair for a user to a system. However, with the use of Signed Certificates, there is the assumption that there is a Certificate Authority (CA), a Single Sign On (SSO) or Identity Provider (IDP) to authenticate a user is present, along with an entitlement management system, and finally a vaulting or other vault like application which is able to parse and verify the input from a user and conditionally issue a signed Certificate. While most of these systems are already in use by an organization, they might not be – requiring additional time and effort being spent on maintaining the system, as shown in Table 3.

Table 3: Comparison of Time Spent Maintaining Signed SSH Certificates as compared to Public/Private Key Pairs

Related Work

Several researchers have studied various organization’s use of Public Key Infrastructure (PKI), and how it could be applied to either SSH logins or One Time Passwords (OTP). In “A Design of One-Time Password Mechanism Using Public Key Infrastructure”, H. Kim, et. al. discusses various proposals for implementing a secure authentication system using PKI [1]. Of the solutions introduced, the “Certificate Issuance and Registration” methodology is most similar and provides precedence for the solution set forth in this paper. In the “Certificate Issuance and Registration” scenario, a user would contact a Registration Authority (RA) which would then transfer to a Certificate Authority the request and user information [1]. After being validated, a reference number and approval would be returned back to the user, and that reference would be used to issue a certificate. While this does not completely match the solution proposed, it does provide a basis for validating a user’s identity and intent before allowing the issuance of a certificate by a Certificate Authority.

Summary

Based on the above solution set forth by the author, additional layers of security are put in place to avoid the abuse and misuse of SSH key pairs in a distributed key environment. Through the use of a Certificate Authority (CA) as a trusted and official source of truth, you can validate that the user accessing the system is the intended entity, and with both time and permissions scoped. While the level of effort is higher to maintain such Certificate and Registration Authorities, there is increased control and repudiation within the system.

Slide Deck

References

[1] H. Kim, H. Lee, K. Lee and M. Jun, ”A Design of One-Time Password Mechanism Using Public Key Infrastructure,” 2008 Fourth International Conference on Networked Computing and Advanced Information Management, 2008, pp. 18-24, doi: 10.1109/NCM.2008.77.

[2] M. Kumagai, Y. Musashi, D. A. L. Romana, K. Takemori, S. Kubota and K. Sugitani, ”SSH Dictionary Attack and DNS Reverse Resolution Traffic in Campus Network,” 2010 Third International Conference on Intelligent Networks and Intelligent Systems, 2010, pp. 645-648, doi: 10.1109/ICINIS.2010.9.

[3] T. Ylonen, ”SSH Key Management Challenges and Requirements,” 2019 10th IFIP International Conference on New Technologies, Mobility and Security (NTMS), 2019, pp. 1-5, doi: 10.1109/NTMS.2019.8763773.

[4] L. Zheng, C. Zhao and Z. Wang, ”The SSH Protocol Audit System Based on Proxy Technology,” 2013 International Conference on Computational and Information Sciences, 2013, pp. 1489-1492, doi: 10.1109/ICCIS.2013.392