Internet DRAFT - draft-ylonen-sshkeybcp
draft-ylonen-sshkeybcp
draft-ylonen-sshkeybcp-01.txt
Network Working Group T. Ylonen
Internet-Draft SSH Communications Security
Expires: October 06, 2013 G. Kent
SecureIT
M. Souppaya
NIST
April 04, 2013
Managing SSH Keys for Automated Access - Current Recommended Practice
Abstract
This document presents current recommended practice for managing SSH
user keys for automated access. It provides guidelines for
discovering, remediating, and continuously managing SSH user keys and
other authentication credentials.
Various threats from poorly managed SSH keys are identified,
including virus spread, unaudited backdoors, illegitimate access
using leaked keys, lack of proper termination of access, use of
legitimate access for unintended purposes, and accidental human
errors.
Hundreds of thousands, even over a million SSH keys authorizing
access have been found from the IT environments of many large
organizations. This is many times more than they have interactive
users. These access-granting credentials have largely been ignored
in identity and access management, and present a real risk to
information security.
A process is presented for discovering who has access to what,
bringing an existing IT environment under control with respect to
automated access and SSH keys. The process includes moving
authorized keys to protected locations, removing unused keys,
associating authorized keys with a business process or application
and removing keys for which no valid purpose can be found, rotating
existing keys, restricting what can be done with each authorized key,
and establishing an approval process for new authorized keys. A
process is also presented for continuous monitoring and controlled
authorized key setup.
Finally, recommendations are made for security policy makers for
ensuring that automated access and SSH keys are properly addressed in
an organization's security policy.
Specific requirements are presented that address the security issues
while keeping costs reasonable.
Ylonen, et al. Expires October 06, 2013 [Page 1]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Guidance is also provided on how to reduce operational cost while
addressing the threats and how to use tools to automate the
management process.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 06, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose and Scope . . . . . . . . . . . . . . . . . . . . 4
1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Structure of This Document . . . . . . . . . . . . . . . 4
1.4. Words Signifying Level of Requirement . . . . . . . . . . 5
1.5. Impact Levels for Information Systems . . . . . . . . . . 5
2. The Basics of SSH Protocol and Implementations . . . . . . . 8
2.1. The SSH Protocol . . . . . . . . . . . . . . . . . . . . 8
2.2. User Authentication in SSH . . . . . . . . . . . . . . . 8
2.2.1. Password Authentication . . . . . . . . . . . . . . . 9
Ylonen, et al. Expires October 06, 2013 [Page 2]
Internet-Draft Managing SSH Keys for Automated Access April 2013
2.2.2. Public Key Authentication . . . . . . . . . . . . . . 9
2.2.3. Kerberos Authentication . . . . . . . . . . . . . . . 9
2.2.4. Host-Based Authentication . . . . . . . . . . . . . . 10
2.2.5. Comparison of the Authentication Methods . . . . . . 10
2.2.6. Dangers of Unverified and Shared Host Keys . . . . . 10
2.3. Common Use Cases . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Interactive Use . . . . . . . . . . . . . . . . . . . 11
2.3.2. Automated Access . . . . . . . . . . . . . . . . . . 11
2.3.3. File Transfers . . . . . . . . . . . . . . . . . . . 12
3. Threats Arising from Poorly Managed Automated Access and SSH
Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Virus Spread Threat . . . . . . . . . . . . . . . . . . . 13
3.2. Unaudited Backdoor Threat . . . . . . . . . . . . . . . . 14
3.3. Leaked Keys May Provide Access for Extended Periods . . . 15
3.4. Lack of Proper Termination of Access . . . . . . . . . . 16
3.5. Use for Unintended Purpose . . . . . . . . . . . . . . . 17
3.6. Accidental Data Transfers and Human Errors . . . . . . . 18
3.7. Problem Under Radar . . . . . . . . . . . . . . . . . . . 19
4. Assessing the SSH Key Management Situation and Risks . . . . 20
5. Key Remediation Solution Planning and Deployment . . . . . . 23
5.1. Discovering SSH Keys and Trust Relationships . . . . . . 24
5.2. Moving Authorized Keys to Protected Locations . . . . . . 28
5.3. Monitoring Use of Trust Relationships and Keys . . . . . 29
5.4. Removing Trust Relationships That Are No Longer Used or
Otherwise Inappropriate . . . . . . . . . . . . . . . . . 31
5.5. Associating Trust Relationships with Application and/or
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6. Implementing Approval Process for Setting Up New Trust
Relationships . . . . . . . . . . . . . . . . . . . . . . 33
5.7. Rotating Existing SSH User Keys . . . . . . . . . . . . . 35
5.8. Configuring Command Restrictions on Authorized Keys . . . 36
5.9. Configuring IP Address Restrictions on Authorized Keys . 37
6. Continuous Monitoring and Management of SSH Keys and
Automated Access . . . . . . . . . . . . . . . . . . . . . . 38
6.1. Continuous Monitoring of Changes to Trust Relationships . 38
6.2. Removal of Trust Relationships . . . . . . . . . . . . . 41
6.3. Periodic Rotation of Trust Relationships . . . . . . . . 41
7. Policy Recommendations . . . . . . . . . . . . . . . . . . . 41
8. Considerations for Software Tools . . . . . . . . . . . . . . 45
8.1. Reducing Cost and Improving Security by Automation . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction
Ylonen, et al. Expires October 06, 2013 [Page 3]
Internet-Draft Managing SSH Keys for Automated Access April 2013
1.1. Purpose and Scope
This document focuses on risks related to poorly managed automated
access in information systems and particularly SSH user keys, and how
to reduce the risks. It documents current best practice of managing
SSH keys for cost-effectively minimizing the risks, and provides
security policy recommendations and auditing guidelines relating to
SSH keys and other automated access.
1.2. Audience
This document is intended for information security policy makers,
auditors, security managers, IT operations managers, system
administrators, and others who are responsible for specifying,
acquiring, testing, implementing, maintaining, and auditing identity
and access management and SSH solutions. Portions of the document
may be of interest to technically advanced end users and systems
programmers involved with SSH and other automated access
technologies.
1.3. Structure of This Document
Section 1.4 specifies what certain words indicating level of
requirement for compliance with this standard mean.
Section 1.5 defines impact levels for information systems, including
some important definitions relating to information systems having low
impact themselves but having automated access to higher-impact
information systems.
Section 2 summarizes the basics of the SSH protocol and
implementations, with particular emphasis on authentication methods
for automated access and typical use cases for automated access.
Section 3 describes threats arising from poorly managed SSH user
keys. Most of the threats are also relevant for other kinds of
automated access. However, because of the ubiquity of SSH keys and
the acuteness of addressing them the discussion focuses on SSH keys.
Section 4 introduces simple metrics and questions that are useful in
scoping the risks related to SSH user keys and gaining basic
understanding of the size of the problem in an organization. The
approach is suitable for both IT auditors responsible for assessing
compliance with security policies as well as government and other
policy makers wanting to measure the overall state of compliance and
security across agencies.
Ylonen, et al. Expires October 06, 2013 [Page 4]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Section 5 introduces the process for detailed analysis of existing
automated trust relationships and risks (with an emphasis on SSH user
keys), as well as recommended steps for remediating the risks. This
section also discusses the specific threats addressed by each
remediation step and risks involved in not implementing a particular
step.
Section 6 provides recommendations for continuous monitoring and
management of SSH user keys and other automated trust relationships,
as well as for auditing steps to be taken for ensuring that an
organization keeps automated access under control after an initial
remediation phase.
Section 7 provides recommendations for an organization's security
policy for properly addressing SSH user keys and automated access.
Section 8 summarizes issues to consider when planning use of
automated software tools for managing automated access with SSH and
particularly SSH user keys. It also illustrates how to achieve cost
savings in existing operational processes.
Section 9 summarizes security considerations. Most of this document
is about security and managing elements of security and access, and
this section serves as a conclusion and summary of this document.
Section 11 provides a glossary of the technical terms used in this
document.
1.4. Words Signifying Level of Requirement
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
1.5. Impact Levels for Information Systems
The appropriate level of security and effort expended on security
often depends on the level of impact from a failure or compromise of
an information system. FIPS Publication 199 [FIPS199] provides
designations for impact levels on organizational information systems
and a process for categorizing information systems.
This document makes reference to the impact levels described FIPS 199
(please see original document for exact definitions, this is just a
simplifying summary):
Ylonen, et al. Expires October 06, 2013 [Page 5]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Low impact: Unauthorized disclosure, modification, destruction, or
disruption of access have limited adverse effect on organizational
operations, organizational assets, or individuals.
Moderate impact: Unauthorized disclosure, modification, destruction,
or disruption of access could be expected to have a serious
adverse effect on organizational operations, organizational
assets, or individuals.
High impact: Unauthorized disclosure, modification, destruction, or
disruption of access could be expected to have a severe or
catastrophic adverse effect on organizational operations,
organizational assets, or individuals.
FIPS Publication 199 analyzes impact levels separately for
confidentiality, integrity, and availability. For considerations
around automated access, the impact level of access to an account on
an information system is taken to be the highest level of these three
principles for the information system, since this specification
primarily relates to operating system level access to information
systems, and operating system level access can often be used to
breach all three objectives simultaneously. Furthermore, experience
has shown that once an attacker has operating-system level access to
one user account on a computer, various attack vectors (including
bugs in system software and misconfigurations) can often be utilized
to escalate the access to high-level administrative access. That
definitely compromises all three principles of information security.
Configured trust relationships for automated access (e.g., using SSH
user keys) may permit access from low-impact information systems to
high-impact information systems without providing a password or other
authentication credential from a user. This is particularly relevant
if the authentication credential or authorized key permits access on
the high-impact information system without restrictions on the
commands that can be executed on the high-impact information system.
In this case, access to the low-impact information system implies
access to the high-impact information system. The information system
owner inherently accepted this risk by allowing a low-impact system
access to a high-impact system with providing compensation controls.
There may also be situations where the high-impact system owner may
not know the key has been copied to a low-impact system, or from one
low-impact system to another.
Therefore, whenever a low-impact information system has a configured
trust relationship permitting it to access a high-impact information
system without a restriction on the commands that can be executed on
the high-impact information system, the low-impact information system
MUST be treated as having the impact level of the highest-impact
Ylonen, et al. Expires October 06, 2013 [Page 6]
Internet-Draft Managing SSH Keys for Automated Access April 2013
information system that it can access using automated trust
relationships.
This implies that to avoid treating low-impact information systems as
high-impact systems, there must be a well-defined boundary in the IT
environment that trust relationships can only cross in the direction
allowing access from higher-impact systems into lower-impact systems,
but not vice versa. If such boundary is relied on, it MUST be
audited and continuously monitored to enforce its existence. Such a
boundary could exist, for example, between development and production
systems.
Sometimes otherwise low-impact systems are used for producing code,
software distributions, or data sets that will be used on higher-
impact systems. Such systems SHOULD be treated as higher-impact
systems in view of Advanced Persistent Threat (APT) scenarios where
an attacker could insert a backdoor in software that eventually gets
copied to production systems.
It should be noted that several current SSH implementations
(including OpenSSH) only permit configuring command restrictions for
access based on SSH user keys. It is currently not possible to
configure command restrictions for Kerberos-based authentication,
host-based authentication, hard-coded passwords, or passwords coming
from password vaults, which has implications for the above
requirement.
Command restrictions are a compensation control that can be leveraged
to minimize the exposure to the additional risks exposed to a high-
impact system from allowing limited access to the hosted resources
from a low-impact system. Command restrictions used for this purpose
MUST be designed to be effective in limiting what actually can be
done with the access, and MUST prevent interactive access and port
forwarding. For example, a command restriction permitting arbitrary
commands or interactive shell is not effective.
Furthermore, if a trust relationship has a command restriction that
limits its use to file transfers but the directories from which files
can be read or modified using it have not been restricted, it exposes
the server to a more limited risk. The trust relationship may be
used to read any file or directory on the server accessible to the
user account used for file transfers, even those outside the intended
directories. It may also be used to write any file that is writable
by the user account; it is fairly common to have configuration files
on servers that are inappropriately world-writable, in which case
these files could be modified.
Ylonen, et al. Expires October 06, 2013 [Page 7]
Internet-Draft Managing SSH Keys for Automated Access April 2013
If a trust relation is restricted to file transfers but does not
limit the directories that can be accessed, the originating
information system SHOULD be considered as having at least the impact
level of the highest-impact information system to which it has such
access.
2. The Basics of SSH Protocol and Implementations
SSH (Secure Shell) is a protocol and software tool for logging into a
remote machine, executing commands remotely, and transferring files
with a remote machine over a computer network. SSH can also be used
for implementing a protected tunnel for delivering other services.
SSH is very widely used for administering Linux and Unix systems,
virtual machines, routers, firewalls, and other network devices. It
is also embedded in many leading file transfer solutions, systems
management solutions, identity management solutions, and privileged
access management solutions. It is widely used for integrating IT
systems and automating their operation.
2.1. The SSH Protocol
The SSH protocol is an IETF standards track protocol and is described
in RFC 4251 [RFC4251], RFC 4252 [RFC4252], RFC 4253 [RFC4253], and
RFC 4254 [RFC4254].
Many independent commercial and open source implementations are
available, including Tectia SSH, OpenSSH, and many others. SSH is
available for nearly all platforms, including Linux/Unix, Windows,
mainframes, routers, telephone exchanges, mobile devices such as
smartphones and tablets, various embedded devices, and many
industrial automation systems.
In the SSH protocol, an SSH client application initiates a TCP/IP
connection over a network to a destination server, negotiates
encryption, authenticates the remote server, and then sends a
destination user name and authentication credentials to the server.
Server authentication is done using host keys, and its primary
purpose is to prevent man-in-the-middle attacks; however server
authentication is beyond the scope of this document.
2.2. User Authentication in SSH
The SSH protocol supports several mechanisms for authenticating
users, including passwords, public key authentication, Kerberos, and
host-based authentication.
Ylonen, et al. Expires October 06, 2013 [Page 8]
Internet-Draft Managing SSH Keys for Automated Access April 2013
2.2.1. Password Authentication
There are two kinds of password authentication mechanisms in SSH:
basic password authentication and keyboard-interactive
authentication. Keyboard-interactive authentication can support
various types of challenge-response systems and various other
authentication mechanisms.
Password authentication is commonly used for interactive users, but
less commonly for automated access (through it is sometimes seen with
hard-coded passwords in scripts and management systems, especially
for managing routers and file transfers).
2.2.2. Public Key Authentication
Public key authentication in SSH uses user keys or certificates to
authenticate/authorize a connection. An SSH client has an identity
key, typically an RSA or DSA private key, and the server must have
the corresponding public key configured as an authorized key for the
destination user. The private key may be protected by a passphrase,
in which case it is encrypted by a key derived from the passphrase
(passphrases are common for interactive users but rarely used for
automated access).
Many widely used SSH implementations support configuring restrictions
for SSH user keys. These may be used for limiting what can be done
on the server using the key (command restrictions) and for limiting
the IP addresses from which the key can be used (source
restrictions).
Public key authentication is by far the most frequently used method
of configuring automated access using SSH at the time of this writing
and represents best current practice.
2.2.3. Kerberos Authentication
Many organizations use Kerberos or Active Directory authentication
with SSH. Kerberos (usually together with LDAP) implements single
sign-on and allows user accounts to be stored in a centralized
directory.
In practice, Kerberos is rarely used for non-interactive accounts.
While it can be configured to use keytab files or cached tickets for
functional accounts, these approaches rely on having long-term
credentials stored on the host or at least accessible to the process
on the host that is obtaining tickets. These credentials can be
exploited by an attacker largely in the same way as SSH user keys,
e.g., by using them to obtain a ticket granting ticket (TGT) for the
Ylonen, et al. Expires October 06, 2013 [Page 9]
Internet-Draft Managing SSH Keys for Automated Access April 2013
functional account and using the ticket to gain access to other hosts
or accounts that the functional account can access (see virus spread
threat below).
One problem with Kerberos for automated access is that the single
sign-on feature implies that once access has been gained to one
account using Kerberos, it is usually possible to log in to any other
server that has the same account and is in the same domain without
further authentication. This can very easily create lots of unwanted
implicit trust relationships. Existing implementations also do not
support command restrictions for Kerberos.
2.2.4. Host-Based Authentication
Host-based authentication uses the source host's host key to
authenticate the source host and to vouch for the identity of the
user on the client side. It is rarely used and does not permit
configuring command restrictions. Therefore its use for automated
access is NOT RECOMMENDED.
2.2.5. Comparison of the Authentication Methods
All these authentication methods fundamentally rely on some secret
information, and when used for automated access, this secret
information must be stored on or accessible to the source host.
A major advantage of public key authentication over the other methods
is that it allows configuring a command restriction. The command
restriction can be used for preventing virus spread and other
attacks, as described in Section 3. It also does not create any
implicit trust relationships and the permitted access can be reliably
determined by inspecting the destination host (except for OpenSSH's
proprietary certificate authentication, which SHOULD NOT be used
because it cannot be reliably audited). For these reasons, public
key authentication is the RECOMMENDED authentication mechanism for
automated access with SSH.
Password authentication SHOULD NOT be used for automated access,
because hard-coded passwords may be obtained by attackers and
password vaults are also not particularly secure against local
attacks on the client software. If password authentication is used
for automated access, the passwords MUST be rotated every three
months.
2.2.6. Dangers of Unverified and Shared Host Keys
Many file transfer applications, privileged access management
systems, and systems management applications do not check host keys
Ylonen, et al. Expires October 06, 2013 [Page 10]
Internet-Draft Managing SSH Keys for Automated Access April 2013
for hosts that they connect to. This permits a man-in-the-middle
attack to be performed in the network. Many tools are available for
this and any device connected to a network through which the
connection goes can be used for the attack - including, e.g.,
reprogrammed smart switches.
Man-in-the-middle attacks are a risk regardless of the authentication
method if hosts keys are not properly verified. The attack permits
injection of arbitrary commands into the session, and reading and
modifying any transferred files (including injection of bogus file
transfers). A successful man-in-the-middle attack from the network
gives the same power as being able to use a trust relation leading to
the destination host.
Such man-in-the-middle attacks are practical, and are exploited in
freely available attack tools and malware, as well as security
software from multiple vendors for co-operative auditing purposes.
Besides applications that do not check host keys, there are also some
large enterprise that share the same host key on thousands of
machines (for example, one Fortune 500 company is known to use the
same host key on 14000 computers at the time of this writing). If
any of the computers is compromised, they all become vulnerable to
man-in-the-middle attacks.
Therefore, while this document is not really about host keys, the
destination host MUST be properly authenticated by the client for all
automated access and a unique host key MUST be used for each host.
An exception may be made for the very first connection to a server to
simplify system administration.
2.3. Common Use Cases
2.3.1. Interactive Use
SSH has become the standard used by system administrators for
configuring and managing Unix and Linux computers, routers, and
various other equipment remotely. It is also widely used by software
developers, and in some organizations by ordinary end users for
running applications remotely (particularly text-based legacy
applications). Public key authentication is often used by advanced
end users for single sign-in. Sometimes it is also used on jump
servers.
2.3.2. Automated Access
SSH is very frequently used for automated access between systems.
Such automated access is necessary for cost-efficiently managing
Ylonen, et al. Expires October 06, 2013 [Page 11]
Internet-Draft Managing SSH Keys for Automated Access April 2013
large IT environments, for integrating applications, and for cost-
effectively provisioning virtual machines in cloud services.
Automated access refers to accessing a computer from another computer
in an automated fashion. Automated access may be unrestricted,
allowing any commands to be executed, or may be limited to specific
commands or operations, such as file transfers (perhaps limited to a
specific directory).
Automated access is most commonly used with functional accounts,
system accounts, service accounts, and other non-interactive user
accounts (sometimes also called non-user accounts). Such accounts
are used by operating systems, middleware, databases, and
applications for running processes. System or service accounts are
likely to have sensitive levels of access to system resources (in
that case they are often called privileged accounts).
Automated access using SSH is common also in Windows and mainframe
environments, especially for file transfer applications. There are
also various native mechanisms on Windows that can be used for
automated access, but such mechanisms are beyond the scope of this
document.
Automated access has been largely ignored in Identity and Access
Management. Hundreds of thousands to over a million authorized SSH
keys have been found from the IT systems of several large
enterprises. This means that they have many times more entry points
for automated access configured on their servers than they have
interactive users in the organization! It is clear that such entry
points cannot be ignored.
2.3.3. File Transfers
SSH is frequently used as a file transfer tool in itself, using the
"scp" and "sftp" tools. The SFTP [SFTP] protocol is gaining
popularity in commercial and open source file transfer products, and
a substantial fraction of the world's file transfers now use the SFTP
protocol. Automated file transfers using SSH typically use public
key authentication or hard-coded passwords, and they are often also
used between organizations.
3. Threats Arising from Poorly Managed Automated Access and SSH Keys
This section outlines some of the threats that have been identified
with poorly managed SSH keys. The guidelines and recommendations of
this document are intended to address these while minimizing the
administrative burden from managing the keys.
Ylonen, et al. Expires October 06, 2013 [Page 12]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Several of the problems described below are present with many
technologies for automated access besides SSH keys. The issues must
be addressed regardless of technology.
3.1. Virus Spread Threat
Malware can be engineered to use SSH keys to spread to most servers
within an organization once it has penetrated one server. Experience
has shown that viruses frequently manage to penetrate individual
servers in an organization. Malware often uses multiple attack
vectors to penetrate an organization and could use SSH user keys (or
other trust relationships such as Kerberos) to spread within the
organization's server infrastructure in minutes after penetrating the
first server, thereby defeating layered security defenses.
The Morris worm in 1988 utilized automated access trust relationships
to spread in a similar manner (at that time based on ".rhosts"
authentication). This attack vector can be very powerful, and its
importance is increasing as systems management becomes more
automated. Many computer forensics experts are aware of cases were
SSH keys have been used to spread an attack from one server to
another, and several high profile incidents in the last year have
used SSH keys as an attack vector.
Experience has shown that most large organizations have 3 to 100+ SSH
keys configured granting access to each Unix/Linux server. Some keys
grant high-level administrative access or access to sensitive
accounts, such as those storing database files or critical software.
In practice it has been found that in many organizations
approximately 10% of SSH keys grant access to root accounts or other
privileged accounts.
The mesh of automated access relationships is so dense in many cases
that it is likely that an attack can spread to most servers in an
organization after penetrating the first few servers, especially if
other attack vectors are used to escalate privileges.
Implementing SSH keys as an attack vector in malware is quite easy,
requiring only a few hundred lines of code. Once the malware has
penetrated a server, it may use the server to further the attack and/
or, e.g., leave a backdoor, steal, alter, or corrupt data, subvert
encryption systems or databases, or outright destroy the server.
The virus spread threat can be reduced by combining several
approaches:
Mandating forced command restrictions for as many trust
relationships as possible.
Ylonen, et al. Expires October 06, 2013 [Page 13]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Removing trust relationships that are no longer needed.
Minimizing the number of trust relationships leading to root
accounts (directly or indirectly).
Minimizing implicit trust relationships arising from privilege
escalation (e.g., "sudo"), single-sign-on (e.g., Kerberos), and
host equivalence.
3.2. Unaudited Backdoor Threat
Many large organizations mandate that all privileged access to their
servers take place through a privileged access management system that
records any actions performed. Key-based access (and other automated
trust relationships) can be used for creating backdoors that bypasses
such privileged access management systems.
System administrators and production support personnel regularly gain
access to various accounts in the course of legitimate work. An
administrator or production support person may add a new authorized
key to an account with a single command (e.g., "echo ...keydata...
>>~/.ssh/authorized_keys"). As of this writing, most organizations
never audit authorized keys for their user accounts, and thus the
added key may remain unnoticed for years. Such a key can then be
used to log into the account using any SSH client, bypassing the
privileged access management system. It thus provides a relatively
permanent unaudited backdoor.
Key-based backdoors can also circumvent password vaults and systems
that change root (or other privileged account) passwords regularly.
Experience has shown that many organizations have no control or
tracking of trust relationship creation. Any system administrator or
production support personnel can create and install a user key pair
as needed without any reporting, logging, or authorization. Such
practice undermines traditional controls for privileges access.
The unaudited backdoor threat can be reduced by the following:
Prevent non-root/non-Administrator users from granting automated
access to accounts without proper approval. For example, move all
authorized keys files to root-owned directories that are not
writable by normal users.
Continuously monitor the environment to detect unauthorized trust
relationships configured by someone having root access.
Ylonen, et al. Expires October 06, 2013 [Page 14]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Require proper explanation and valid purpose for the existence of
every trust relationship and remove any unused trust
relationships.
Use privileged access management systems that capture SSH and
other protocols using automated access on the network level or at
the server (transparent access auditing). Enforce privileged
access management for connections using automated trust
relationships.
3.3. Leaked Keys May Provide Access for Extended Periods
Most security policies and regulations mandate that all passwords
must be changed regularly, e.g., every three months. Some security
standards mandate that encryption keys must also be changed
regularly. However, very few security policies at this time make it
explicit that authentication/authorization keys should also be
regularly changed. In a sense, authentication keys are even more
critical than encryption keys, because once access to a user account
has been gained, it is generally possible to access and modify any
data for that user account - including reading and modifying memory
of processes running under that user account and/or modifying any
executable programs owned by that user account, thus subverting
encryption systems and other critical applications.
At the time of this writing, most organizations do not track which
SSH keys their users, administrators, backup operators, and janitors
may have had access to and copied over the years. In addition, they
never change their SSH keys. Most environments do not use source
restrictions on authorized keys. Therefore, a leaked key may be used
from any computer or network within the organization (unless limited
by internal firewalls).
This means that anyone who may have obtained a copy of a key (e.g.,
by copying it from a host, accessing a backup, or having acquired
some decommissioned equipment that was not securely wiped) may gain
access to production servers in the organization.
No audit or discovery process can ever guarantee finding all copies
of identity keys, as they are small files that could be hidden
anywhere, and there could be copies on laptops, tablets, USB sticks,
offline, and even on paper (they are small enough to be typed in).
Identity keys can easily be taken out from an organization on a
single piece of paper, or by taking a photograph of a screen using a
cellphone.
There have also been many instances where private keys have been
uploaded to, e.g., "github" (a repository used by many open source
Ylonen, et al. Expires October 06, 2013 [Page 15]
Internet-Draft Managing SSH Keys for Automated Access April 2013
software development projects). In January 2013, hundreds of private
keys and passwords were found from the repository, some of which were
being used for attacks. Obviously, identity keys MUST NOT be
uploaded into any public repository.
The problems created by leaked or unchanged keys can be reduced by:
Rotating all keys regularly to guarantee the eventual termination
of access.
Configuring source restrictions for authorized keys, making it
more difficult to exploit copied identity keys.
Using certificate-based authentication, which can provide
revocation and expiration, but is cumbersome to manage (and still
does not protect from some of the other threats).
Using Kerberos authentication, which allows terminating access to
the account; however, Kerberos authentication does not in itself
prevent leaked keys that have not been changed from being used.
Besides rotating keys at regular intervals to avoid their leakage and
to limit the duration of the exploitation window should they leak,
periodic rotation also applies to credentials used for obtaining
actual authentication credentials; for example, it is not enough to
periodically obtain a new Kerberos ticket - one must also regularly
change the authentication credentials used for obtaining an initial
ticket. It is also not enough to issue a new certificate for the
same private key - the private key must also be replaced by a newly
generated private key.
3.4. Lack of Proper Termination of Access
Most security standards mandate proper termination of access when an
employee leaves or changes roles. If the user remains in possession
of identity keys that continue to have access to the organization's
information system, access is not being properly terminated.
Since administrators can quite easily copy identity keys (and may
have legitimately configured key-based access from their personal
account to various accounts they used in their previous role), the
only practical way to guarantee proper termination of access is to
remove or rotate any keys that the employee may have had access to.
At the time of this writing, most organizations do not know what each
key is used for. Without this knowledge, they seldom remove or
rotate keys, because something could break if they accidentally
remove a key that is needed for some important business process or
Ylonen, et al. Expires October 06, 2013 [Page 16]
Internet-Draft Managing SSH Keys for Automated Access April 2013
omit some authorized keys corresponding to a public key being
rotated.
Some organizations have used manual spreadsheets for tracking key
usage. However, it has turned out they are usually out of date,
inaccurate, and have not been maintained throughout the organization.
Many organizations have no monitoring whatsoever of automated access
or new user key setups.
Proper termination of access can be ensured by:
Moving all authorized keys files to root-owned directories that
are not writeable by non-privileged users.
Regularly rotating keys (ensures termination of access by copied
keys latest at next key change).
Triggering immediate key rotation for private keys on accounts
accessible by the person whose access is being terminated.
3.5. Use for Unintended Purpose
Firewalls commonly have rules that permit specific communications for
file transfer purposes. When the file transfer is using SSH (or
SFTP), it is important that a forced command be used on the server to
ensure that the access permitted through the firewall cannot be used
for other purposes, such as executing shell commands on the server.
Another related use case is employees creating their own backdoors
into the enterprise to circumvent corporate policies against
uncontrolled remote access by opening an SSH connection from the
office to their home machine with a port forwarding from the home
machine back to the office machine. Such backdoors may provide
hackers an entry point into the company intranet, especially if the
home machine is compromised and the user's password is obtained
using, e.g., key logger malware.
Various commercial products are available for auditing SSH
connections at a firewall to enforce that opened ports are not used
for unintended purposes regardless of server configuration.
Various SSH implementations permit port forwarding even when forced
commands are used. Therefore, a trust relationship that is intended
only for file transfer may actually be used to obtain a connection to
any port at any host on the internal network (or external network,
for hiding the source of an attack).
The threat of unintended use can be minimized by:
Ylonen, et al. Expires October 06, 2013 [Page 17]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Allowing SSH/SFTP through a firewall only when required and
restricting sources and destinations to fewest systems required.
Configuring forced commands for authorized keys used by external
parties.
Implementing tools to audit SSH connections at the firewall and
monitoring use to ensure that access was not misused.
Avoiding trust relationships that cross security boundaries or
allow connections from low-impact systems to higher-impact
systems.
3.6. Accidental Data Transfers and Human Errors
Not all risks associated with unmanaged automated access arise from
malicious behavior. If there is automated access from non-production
systems to production systems, data may accidentally be copied from
non-production systems into production systems, where the incorrect
data may cause substantial loss of money. Alternatively, data may be
inadvertently copied from production systems to non-production
systems, where the data may be exposed due to looser security
controls.
People are also known to make human errors when manually setting up
new trust relationships. For example, it is fairly easy for a
security administrator to accidentally copy an authorized key to the
root account on a host instead of some other account that was
intended. Such errors can go undetected for years.
Some key setups involve thousands of hosts. It is easy to miss one
or more hosts when copying an authorized key to so many hosts
manually. Debugging such errors can be very time consuming. Also,
when manually fixing such problems, security administrators are
likely to just copy the missing keys to the proper accounts, without,
for example, checking whether they have accidentally been copied to
the root account.
The threat of accidents and human errors can be minimized by:
Automating key provisioning to implement the authorized keys
exactly as they were requested and approved.
Configuring source and command restrictions for authorized keys.
Enforcing policies for preventing trust relationships between
systems that cross security zone boundaries.
Ylonen, et al. Expires October 06, 2013 [Page 18]
Internet-Draft Managing SSH Keys for Automated Access April 2013
3.7. Problem Under Radar
The SSH key management problem has been recognized in various circles
for some time. The scope of the problem, and its relation to
automated access overall, however, has not been widely understood.
The problems have remained under the radar because they are deeply
technical and obscure, within the domain of system administrators.
Each system administrator typically only sees a small corner of the
IT environment and does not have a full picture. Although
administrators and their managers may recognize that there is a
problem, they simply have not had time to analyze the scope or
possible implications of the problem. There have also been no
guidelines or training materials on how to address it.
Most IT auditors do not have SSH key management or automated access
more generally on their checklists or audit programs, yet it is
central to identity and access governance given the prevalence of
automated access entry points to systems.
SSH keys, or control of credentials for automated access more
generally, has not been sufficiently highlighted in security control
frameworks and auditing guidelines for FFIEC, SOX, PCI, FISMA, HIPAA,
NERC, or COBIT. Even many CISOs are only vaguely aware of the
problem, and many CIOs and IT risk management professionals have
never heard of it.
Training, books, and systems in the identity and access management
space have largely only dealt with actual human users and control of
interactive access by people. Automated access by machines has been
largely ignored, despite many organizations now having many times
more credentials for automated access to their systems than they have
interactive accounts.
Despite the risk, the problem will likely not be addressed until IT
security auditors, IT operations managers, security architects,
CISOs, and IT risk management professionals understand the issue. It
must be addressed in security regulations, guidelines, standards, and
internal security policies. Education and training will also be
needed to ensure that the SSH key management problem and remediation
actions are understood. It must be evaluated during audits to ensure
that action is taken.
Ylonen, et al. Expires October 06, 2013 [Page 19]
Internet-Draft Managing SSH Keys for Automated Access April 2013
4. Assessing the SSH Key Management Situation and Risks
Addressing threats related to automated access and SSH keys begins
with understanding the extent to which automated access and SSH keys
are used in an organization, understanding how they are managed, and
identifying areas likely to require further attention.
Risks associated with SSH key management are generally relevant for
organizations where at least one of the following is true (the list
is not exhaustive, and other automated access technologies affect
other organizations):
significant number of Unix or Linux systems;
significant use of SSH or SFTP on Windows or Mainframe;
virtualization or cloud services that are internally managed using
SSH (possibly inside automated scripts/tools/frameworks);
web server farms that are managed over SSH;
network devices (e.g., routers, switches, xDSL models, firewalls)
configured and managed using SSH and/or automated management
systems;
significant number of automated file transfers using SFTP;
password management or privileged access management tools using
SSH to connect to end servers; or
systems management tools using SSH to communicate with managed
systems.
Results of the scoping phase help estimate risk exposure and the
probability of non-compliance with mandatory regulations. This
information also helps auditors and decision-makers determine whether
a more detailed discovery and remediation project is warranted.
Certain types of relatively easily obtainable information are useful
in understanding the scope of the problem in an organization. This
information may easily be obtained as part of an audit or regular
review.
Some preliminary indicators about the level of risk can be obtained
by reviewing the sshd_config file for a sample of SSH servers. The
AuthorizedKeyFile parameter indicates the location of files that
store user's authorized key files. If the AuthorizedKeyFile is
located within the user's home directory (which is the default), then
Ylonen, et al. Expires October 06, 2013 [Page 20]
Internet-Draft Managing SSH Keys for Automated Access April 2013
it is likely that a significant problem exists because users are able
to provision new trust relationships. On the other hand, if the
AuthorizedKeyFile is defined within the /etc directory, for example,
then the risk of inappropriate trust relationships is significantly
lessened. Another significant configuration parameter is
PermitRootLogin. A value of "yes" or "without-password" indicates
that SSH keys can be used for root access, which significantly
increases the potential impact of poorly managed keys. However, if
this parameter is set to "no" or "forced-commands-only", then the
potential impact is substantially lessened since interactive root
access is disallowed.
Examining authorized keys provides a meaningful indication of the
level of risk. The following metrics generally give insight into
whether an organization is affected by the issue:
total number of authorized keys in the environment;
total number of authorized keys in the environment that grant
access to a root account (any account with user id 0);
total number of authorized keys in the environment that grant
access to a system account or service account;
total number of authorized keys without a command restriction; and
total number of non-root service accounts or system accounts that
have access to add new authorized keys at will.
There are also a number of scoping questions that can give insight
into the severity of the problem. These questions are well-suited
for a questionnaire or interview of knowledgeable personnel. An
affirmative answer indicates that SSH keys are being managed; a
``no'' indicates that risk exists. The questions are provided below:
Does installing a new authorized key require approval from a
system resource owner or authorized manager 1) for keys granting
root access, 2) for keys granting access to non-root service
accounts or system accounts, or 3) for keys granting access to
interactive user accounts?
Are such approvals enforced through the provisioning process?
Are non-root users technically prevented from installing new
authorized keys, e.g., by moving the authorized keys files to
root-owned locations?
Ylonen, et al. Expires October 06, 2013 [Page 21]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Has this configuration been verified to be the case 1) across all
high-risk systems and 2) all moderate-impact systems?
Is a continuous monitoring process in place for detecting
authorized keys that are added outside of the provisioning process
and without proper approvals 1) for root accounts, 2) for service
and system accounts, and 3) for interactive user accounts?
Is a policy in place for rotating SSH user keys? Are monitoring
procedures in place to verify that all user keys have actually
been rotated in accordance with the policy (and the private keys
actually changed)?
For all authorized keys for the root account (and critical system
and service accounts), can the organization easily identify who is
using the keys to connect?
Has the reason of existence for every authorized key, including
the application or business process it relates to, been documented
1) for high-impact systems, 2) moderate-impact systems, and 3)
low-impact systems?
Are SSH keys systematically removed when they are no longer
needed?
Do all authorized keys used for external SFTP/SCP file transfers
with other organizations have a command restriction?
Are command restrictions enforced for trust relationships leading
to moderate-impact and high-impact systems?
Preliminary scoping information can be obtained relatively easily and
scoping questions can be answered without having to install new
software on servers. However, the answers are only approximate.
Experience has shown that many organizations do not know clear or
definitive answers to the questions, and sometimes management
perceptions do not match reality. Therefore the answers are best
obtained and analyzed as part of a regular audit that actually
verifies the answers, at least by representative sampling.
Another interesting diagnostic exercise to gauge the level of risk is
to obtain listings from a few servers of the public keys (or
signatures) from the authorized keys file of root and other sensitive
accounts (such a system or service accounts). If the organization
can readily identify who is using those keys (or could use the keys)
to connect and why, then it is likely that the organization is
effectively managing SSH users key for access control. If the
organization is unable to identify who can use keys to obtain
Ylonen, et al. Expires October 06, 2013 [Page 22]
Internet-Draft Managing SSH Keys for Automated Access April 2013
sensitive access to systems, then the access control problem and risk
is self-evident.
Freely available scripts and tools for doing a proper scoping
analysis are available at http://www.ssh.com/auditing [1]. The
scripts and tools will be useful for internal security professionals,
system administrators, and auditors working with customers.
5. Key Remediation Solution Planning and Deployment
Once it has been determined that further analysis of automated access
and/or SSH keys in an organization is warranted, the organization
typically engages in a multi-step process consisting of additional
discovery and remediation of existing trust relationships,
establishment of appropriate policies, and continuous monitoring to
ensure that automated access is only enabled in accordance with
policy.
A typical key remediation process consists of:
discovering all existing trust relationships based on SSH keys
(and other trust relationships, if applicable);
moving authorized keys files to protected locations to prevent
non-root users from adding new authorized keys;
monitoring use of trust relationships and authorized keys in the
existing environment;
removing trust relationships that are no longer in use;
associating each trust relationship with an application or some
other valid purpose;
implementing an approval process for setting up new trust
relationships;
rotating existing SSH user keys;
configuring forced command restrictions on authorized keys; and
configuring IP address restrictions on authorized keys.
While it is possible to perform all the remediation steps manually,
in a larger environment the use of software tools to assist in the
process can save a huge amount of work. Parts of the process can be
fairly labor-intensive, for example, associating each trust
relationship with an application or valid purpose may require a
Ylonen, et al. Expires October 06, 2013 [Page 23]
Internet-Draft Managing SSH Keys for Automated Access April 2013
substantial amount of manual work, and removing of unused trust
relationships needs to be done with care to avoid any problems with
critical business applications. (See Section 8 for more
information.)
Automating management of SSH keys and other trust relationships can
also bring substantial cost savings. Many organizations spend a
substantial amount of administrator time setting up and maintaining
trust relationships, and the cost of such manual key management can
often be eliminated by automating the process. Ideally, new trust
relationships are approved in the organization's normal security
entitlement approval system and automatically implemented throughout
the IT environment by software for managing SSH authorized keys and/
or other trust relationships. Automation can also reduce human
errors and radically reduce the number of administrators requiring
root access on servers. (See Section 8.1.)
In some environments it may be desirable to prohibit public key
authentication for interactive logins to ordinary user accounts.
This can help enforce ordinary interactive logins to go through a
privileged access management system (unless some administrators have
copied private keys, which is generally possible).
5.1. Discovering SSH Keys and Trust Relationships
The purpose of the discovery phase is to obtain reliable and
reasonably complete information about configured SSH keys and trust
relationships throughout an IT environment. Discovery should ideally
include all Unix/Linux systems, Windows systems (at least those
running SSH servers, SSH clients, or file transfer solutions running
SFTP), Mac servers, workstations, laptops, mainframes, and other
systems using the SSH protocol, including file transfer solutions
using SFTP, virtualization platforms, and privileged access
management gateways.
Since it is not possible to know what trust relationships exist in an
IT environment without scanning all systems for SSH authorized keys
and identity keys, all organizations SHOULD perform initial discovery
of SSH user keys on all systems that use the SSH protocol.
Although some organizations may want to focus only on high-impact
systems, a limited scope discovery process provides only limited
visibility into the security risk of the current environment. It is
important to identify which low-impact systems can access high-impact
systems, and this can only be known by scanning low-impact systems
too. An identity key intended to allow access between two high-
impact systems could be copied onto a low-impact system. Unless
source restrictions are defined for the authorized key, the identity
Ylonen, et al. Expires October 06, 2013 [Page 24]
Internet-Draft Managing SSH Keys for Automated Access April 2013
key can be used from the low-impact system to access the high-impact
system. Therefore, the scope of the discovery process SHOULD include
all systems in the network, including even low-impact systems.
Ideally, routers, BIOS management ports, and other specialized
computing devices should also be included, but at the time of this
writing, software is not yet available for full SSH key discovery for
these devices. This is expected to change in the future. It is also
be possible to audit them manually.
The following MUST be determined during discovery:
Configured authorized keys for all user accounts on all servers of
interest (accounts may be local, in LDAP, in Active Directory, in
NIS, or any combination)
Configured identity keys on all user accounts on all servers and
clients (workstations, laptops, etc) of interest. It should be
understood, however, that one can never be certain that all
identity keys have been found, because some could be copied into
non-standard directories, stored offline, or even printed on
paper. Thus not finding an identity key on a particular system
does not guarantee that the key will not eventually be used from
that system later. On a broader scale, even if the discovery
process fails to find a particular identity key anywhere on the
network, this does not necessarily mean that the key cannot be
used later.
Configured restrictions for each authorized key, such as command
restrictions and source restrictions
Established trust relationships (source host, source account,
destination host, destination account, and restrictions)
The following SHOULD be determined during discovery (these may become
MUST in the future):
Kerberos-based trust relationships for automated access,
particularly access using keytab files, cached tickets, or service
processes holding tickets.
Implicit trust relationships arising from Kerberos single sign-on.
Implicit trust relationships arising from sharing the same home
directory across multiple accounts. Many organizations share the
same home directory for multiple accounts. Adding an authorized
key for any of the accounts implies adding it to all of the
accounts. Thus, any accounts that can write to the shared home
Ylonen, et al. Expires October 06, 2013 [Page 25]
Internet-Draft Managing SSH Keys for Automated Access April 2013
directory effectively have access to all accounts sharing the home
directory.
Trust relationships configured using host-based authentication
(".shosts", ".rhosts", "hosts.equiv", or "shosts.equiv").
The following MAY be determined during discovery (some of these may
become SHOULD or MUST in the future):
Trust relationships configured using password authentication
(whether hard-coded in scripts or in password vaults). (In
practice it may be difficult to do this reliably. However, it may
be possible to, e.g., recognize certain syntactic patterns and
commands from scripts as using hard-coded password
authentication.)
Implicit trust relationships configured using "sudo" or some other
privilege escalation tool.
Implicit trust relationships arising from user accounts that have
NFS-mounted home directories. NFS is usually not configured to
provide security against network-level attacks, and an attacker
who gains access to a network segment may be able to read and
modify the NFS traffic of any host on the network and impersonate
any other host or user on the network (including reading and
modifying any file on NFS file systems). When home directories
are stored in NFS, a sophisticated attacker with root-level access
to any device on the network (e.g., any unconfigured smart switch
where the attacker can replace the firmware) may add new
authorized keys to any home directory in an NFS file system.
Implicit trust relationships arising from user accounts that have
home directories on a Windows share. Windows file sharing (CIFS,
Common Internet File System) may suffer from same issues as NFS,
and thus the same considerations may also apply to it.
It is important to understand that even though the discovery process
finds keys, and in the short term most trust relationships are
configured using SSH keys, the primary concern is not with the keys
themselves or the underlying cryptography. Rather, the primary
purpose of discovery is to determine who (or what) can access what
and how such access is restricted. In terms of cryptography, all SSH
keys created with default settings since version 1.0 use the
equivalent of at least 1024 bit RSA key, which is still relatively
safe, especially since servers never disclose authorized keys
(cryptographic attacks on the key would first require access to an
authorized keys file, which usually already means access to the
host). Thus verifying key sizes or algorithms is not critical
Ylonen, et al. Expires October 06, 2013 [Page 26]
Internet-Draft Managing SSH Keys for Automated Access April 2013
(though may be required by policy); however, knowing who (or what)
can access what is critical and addresses a real security concern.
SSH user keys grant access and are fundamentally authentication
credentials, rather than encryption keys. The whole issue is
fundamentally not an encryption key problem, but an identity and
access management problem!
Doing discovery properly is complicated. At least the following
aspects need to be properly considered when planning discovery:
SSH user keys cannot be discovered by a network scan because the
SSH protocol was designed not to reveal authorized keys. It is
possible to query whether an already known key is acceptable for a
particular user, but an SSH server will not reveal an authorized
key that is otherwise unknown. This means that the discovery
process will need to connect to each host and access the
authorized keys through the file system. (Host key discovery, on
the other hand, is possible over a network, but host keys are
beyond the scope of this document.)
Different SSH versions are commonly deployed. Many large
organizations have some combination of OpenSSH, Tectia SSH,
SunSSH, Reflection for Secure IT, and various other products. Not
all SSH implementations use the same key formats, store SSH keys
in the same locations, or use the same key fingerprint format.
Furthermore, OpenSSH comes in many flavors and patch set
combinations, and some vendors pack a version of OpenSSH with
another product - sometimes without providing a proper way of
identifying the particular version. The discovery process (and
tools) should be able to properly analyze keys and trust
relationships for any SSH version that is deployed in the
environment.
Many organizations use the "root_squash" option for NFS exports,
which converts file system accesses by root to accesses by an
unprivileged account "nobody". A side effect of this is that a
key discovery process running as root may not be able to read SSH
keys in NFS home directories.
Systems using SELinux may not allow reading SSH authorized key
files or identity key files by ordinary processes. Reading such
files may require special authorization or the use of special
programs, such as "ssh-keycat".
In a large environment, some servers are down for maintenance at
any time, and in a geographically dispersed organization some
networks may not be reachable at the time the discovery is
initially run. Thus, discovery cannot be assumed to succeed on
Ylonen, et al. Expires October 06, 2013 [Page 27]
Internet-Draft Managing SSH Keys for Automated Access April 2013
all servers the first time. This problem is compounded for
discovery of SSH clients since laptops may be disconnected from
the network and therefore be unreachable for scanning.
5.2. Moving Authorized Keys to Protected Locations
Moving authorized keys to protected locations, or locking down
authorized keys, MUST be performed on all moderate-impact and high-
impact information systems (including systems having automated access
to such systems). It MAY be performed on low-impact information
systems.
Moving authorized keys to a protected location may be performed,
e.g., by copying authorized keys for each user to a root-owned
directory, and modifying the system-wide SSH server configuration
file to specify the authorized keys file path (typically using a
pattern that refers to a user name).
Failure to move authorized keys to protected locations allows system
administrators and other users with legitimate access to create new
trust relationships as unaudited backdoors and makes ensuring
termination of access very difficult. Locking down authorized keys
files helps to enforce the requirement that new trust relationships
be properly approved. (See Section 5.3 for discussion of using an
approval process for setting up new trust relationships.)
It is important to lock down authorized keys files early in the
remediation process to create a stable environment for discovery.
Otherwise, inappropriate authorized keys that continue to be added
may not identified during the discovery process.
Similarly, authorized keys MUST be moved away from home directories
susceptible to active network-level attacks (e.g., unencrypted NFS
and CIFS home directories - in practice this includes most NFS home
directories today) on all moderate-impact and high-impact systems
(including systems having unrestricted automated access to such
systems). It is RECOMMENDED that the same be performed on low-impact
information systems.
Failure to move authorized keys away from NFS and CIFS home
directories may allow a network-level attacker (whether human or
automated) to add new authorized keys to any account that accepts
authorized keys from such a directory, permitting unrestricted access
to such accounts. Such attacks are known to have been performed by
some penetration testers and are certainly within the capabilities of
Advanced Persistent Threat (APT) groups.
Ylonen, et al. Expires October 06, 2013 [Page 28]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Furthermore, identity key files SHOULD be moved away from home
directories susceptible to network-level attacks (e.g., unencrypted
NFS and CIFS home directories) on all moderate-impact and high-impact
systems. Otherwise, an attacker who gains privileged access one one
host on the network may be able to read identity keys from user's
home directories and use them for attack (this technique is known to
have been used by attackers). It is RECOMMENDED that the same be
performed on low-impact systems.
Failure to move identity keys away from NFS and CIFS home directories
may allow a network-level attacker (whether human or automated) to
obtain copies of identity keys for later use or for immediately
furthering the attack to other systems. It substantially increases
the risks associated with leaked keys and substantially expands the
group of people who may be able to obtain copies of identity keys.
Some penetation testers are known to use this technique for attacks.
5.3. Monitoring Use of Trust Relationships and Keys
After the initial discovery phase, the environment SHOULD be
monitored for some time (preferably several months) to collect data
on how authorized keys are actually used. While the process can be
performed manually in a small environment, use of scripts or
commercial tools is highly recommended in larger environments.
Software tools can gather and correlate log data from many hosts to
determine the following types of information: which keys are
currently being used, which source hosts they are used from, which
keys are external keys, and what commands they are used with. This
information about the use of trust relationships will help the
organization in later phases of remediation, such as deciding which
authorized keys will be removed for non-use (see Section 5.4) and
which keys can be easily configured with command and source
restrictions (see Section 5.8 and Section 5.9). In addition,
information gathered during monitoring will help the organization
understand automated access patterns in the existing environment and
further evaluate the concrete risks.
Monitoring use of trust relationships may involve configuring SSH
servers and clients to use a higher level of logging and collecting
and analyzing log data. To determine which authorized keys are still
being used, for example, an organization can configure SSH servers
with a log level that causes the fingerprints of keys used for public
key authentication to be logged, collect such log data for an
extended period (several weeks to an year), and analyze the data to
determine which authorized keys were actually used during the log
collection period.
Ylonen, et al. Expires October 06, 2013 [Page 29]
Internet-Draft Managing SSH Keys for Automated Access April 2013
On SSH clients, identity keys that have not been accessed for a long
time (according to file system's file access timestamps) are also
good candidates for removal. However, many programs and commands may
access identity key files, and a recent access time does not
necessarily mean that the key was actually recently used for
authentication. Furthermore, the identity key file timestamp
provides no information regarding the destination host for the last
connection. An identity key may still be in use for some destination
host where it is authorized but not for another.
It should be noted that orphaned keys (authorized keys without a
corresponding identity key) may be either unused or external keys.
Thus they SHOULD NOT be removed without monitoring, as if they are
external keys, trust relationships with hosts outside the managed
environment could be inadvertently broken.
From a project management perspective, the monitoring period can well
be used for assigning impact levels to systems, defining internal
boundaries, and defining host groupings. In practice in large
environments, different parts of the IT environment may be at
different stages of remediation during the project. However, some of
the remediation steps require a reasonably complete picture from
longer-term monitoring before they can be safely performed.
Identifying trust relationships crossing certain boundaries, such as
access from test and development systems into high-impact production
systems, is of high interest to auditors and security managers.
Detecting and controlling such unwanted access is an important audit
objective. This information generally becomes available with
reasonable certainty during the monitoring phase, after internal
boundaries have been configured and impact levels for information
systems determined.
Information collected during the monitoring stage will be helpful in
later stages of a remediation project. The information gathering
takes some time to get a reliable picture. It is RECOMMENDEED that a
sufficient period of time be given for monitoring use of keys: at
least 3-6 months or even a year. The remediation project should not
be rushed, as it increases risk of having incomplete information
about existing trust relationships or external keys, which in turn
increases the risk that remediation activities may disrupt
operations.
Failure to perform the monitoring step properly increases risk of
disruption when unused keys are removed (see Section 5.4), and may
even make removing unused keys impossible (one cannot remove unused
keys without knowing with a high degree of certainty which keys are
unused). Relying solely on the knowledge of application teams and
Ylonen, et al. Expires October 06, 2013 [Page 30]
Internet-Draft Managing SSH Keys for Automated Access April 2013
managers to identify unused keys is generally insufficient due to the
large number of legacy trust relationships, personnel changes, and
poor documentation of trust relationships.
Failure to perform the monitoring step properly also risks missing
some external trust relationships and external keys. This may cause
key rotation (see Section 5.7) to break external connections with
systems outside the managed environment, such as data transfers with
suppliers, contractors, distributors, or regional offices.
5.4. Removing Trust Relationships That Are No Longer Used or Otherwise
Inappropriate
Various security standards and prudent information security require
that access to information systems must be properly terminated when
it is no longer needed. If trust relationships for automated access
are left enabled on systems when no longer needed, they accumulate.
Real-world experience has shown they sometimes accumulate at the rate
of dozens of incoming trust relationships per year per system, even
in security-sensitive environments.
Therefore, all organizations MUST remove trust relationships leading
to moderate-impact or high-impact information systems (including low-
impact systems having automated access to such systems) that are no
longer needed as part of the initial remediation process. Unused
trust relations leading to low-impact information systems SHOULD be
removed.
Unused keys SHOULD NOT be removed until it is known with reasonable
certainty which keys are really unused. This is usually accomplished
by monitoring key usage over a period of time (see Section 5.3). It
is further RECOMMENDED that unused trust relationships be reviewed by
respective application owners to reduce the possibility of disruption
from removal of a trust relationship that is actually needed. It is
important to test infrequently used functionality, such as disaster
recovery systems, reasonably soon after removing unused trust
relationships.
It is also likely that the remediation process will identify many
trust relationships that are still being used but that have no
legitimate business purpose (see Section 5.5), that cross configured
boundaries in inappropriate ways, or that lead to accounts (e.g.,
root) that should not be accessible. Such inappropriate trust
relationships should also be removed (and alternate steps taken to
implement any functionality they support in a more appropriate way,
if required). Some of such trust relationships may have been created
by attackers and may warrant further forensics investigation, such as
identifying when they were created and by whom.
Ylonen, et al. Expires October 06, 2013 [Page 31]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Failure to remove authorized keys for unused trust relationships
increases the risk that key-based attacks for unauthorized access may
succeed and spread throughout the network, allows previously created
unaudited backdoors (using keys that are not regularly used) to
remain in existence, and allows leaked keys (that are not regularly
used) to remain usable indefinitely (if not rotated).
5.5. Associating Trust Relationships with Application and/or Purpose
Because authorized keys provide access to systems, their existence
should be understood, justified, and controlled just like any other
form of access control. After trust relationships that are not used
have been removed, it is important to analyze the remaining active
trust relationships to distinguish those authorized keys that support
a valid application or business purpose and those keys that do not.
Just because a trust relationship is being used does not actually
guarantee that it is needed or legitimate. It may be used, e.g., by
an attacker, by a user who created an inappropriate authorized key as
a backdoor for access, or by a stale cron job relating to a
decommissioned application. Determining the purpose of trust
relationships is important for detecting such illegitimate trust
relationships so that they can removed (see Section 5.4).
After having removed unused authorized keys, the existence of every
remaining incoming trust relationship MUST be justified for moderate-
impact and high-impact information systems (including low-impact
systems having access to such systems).
This is an area where the justification can be more lax on low-impact
systems. However, many low-impact systems, such as those used for
internal software development or packaging, may generate binaries or
distributions that later get installed on production systems. An
attacker could use such systems to gain access to production servers,
especially in an Advanced Persistent Threat (APT) scenario. It is
thus RECOMMENDED that even access to low-impact systems be prudently
justified, or alternatively systems with data/code paths to
production be treated as moderate-impact or high-impact systems.
One practical approach for low-impact systems may be to review
discovered incoming trust relationships in bulk (perhaps for a group
of hosts belonging to the same business process), and label them as
legacy trust relationships relating to the associated business
process. While not ideal, such an approach may make a reasonable
compromise between cost and security in many environments.
It is RECOMMENDED that each trust relationship be associated with the
business process and/or application that it supports, and that the
application/business purpose be documented for future reference.
Ylonen, et al. Expires October 06, 2013 [Page 32]
Internet-Draft Managing SSH Keys for Automated Access April 2013
This will help with removing trust relationships when applications
are replaced and business processes re-engineered, and serves to
assign responsibility for each trust relationship to somebody (the
business process or application owner). Assigning trust
relationships to applications or business processes effectively
assigns ownership for the trust relationships (and related authorized
keys) to the application or business process owner (or group). This
owner MAY be permitted to approve new trust relationships leading to
the same account on the same host, MAY schedule rotation of keys, and
MAY be asked to periodically validate the existence of each trust
relationship relating to the application or business process.
Failure to associate trust relationships with a purpose, business
process, or application means that there remains access to
information systems without reason or justification. Illegitimate
backdoors may remain unnoticed and unnecessary trust relationships
may remain in place that can be used by attackers, especially if keys
are leaked (and not rotated).
5.6. Implementing Approval Process for Setting Up New Trust
Relationships
Real-world experience has shown that many enterprises do not have a
well-defined process for approving new trust relationships for
automated access, and almost no enterprise today systematically
enforces or audits approvals for automated access.
Organizations MUST implement an approval process for ensuring the
validity of new trust relationships granting access to moderate-
impact and high-impact information systems. It is further
RECOMMENDED that organizations implement an approval process for
trust relationships granting access into low-impact systems. This
reduces risk of low-impact systems being used for staging attacks
into high-impact systems. See also Section 8.1 for ideas on how
automated setup of approved trust relationships can reduce costs.
New trust relationships SHOULD NOT be approved without a proper
justification and association with a business process, application,
or other valid purpose. In addition, the approval for new trust
relationships MUST specify any command or source restrictions that
should be implemented to limit security exposure. (See Section 5.8
and Section 5.9)
The approval process SHOULD carefully review whether trust
relationships violate internal boundaries, such as allowing access
from test or development systems into production or allowing access
from low-impact systems into high-impact systems. Documented
justification for crossing boundaries and secondary approval by
Ylonen, et al. Expires October 06, 2013 [Page 33]
Internet-Draft Managing SSH Keys for Automated Access April 2013
higher-level management SHOULD be required for such trust
relationships. Organizations MAY also use the approval process to
enforce other internal boundaries, such as those between business
units or functions, or "Chinese walls" between, e.g., retail banking
and investment banking.
Special approvals SHOULD also be required for trust relationships
leading to root accounts or other highly privileged accounts on
moderate-impact and high-impact systems.
The approval for each such trust relationship MUST be documented and
MUST be retained for later audit. Approvals MUST be organized so
that it is possible find the approval for each new authorized key.
Required approvals for new authorized keys MUST be enforced so that
users cannot bypass the approval process. Enforcement typically
involves both continuous monitoring and securing authorized keys
files:
Continuous monitoring (as discussed in Section 6) is needed to
detect trust relationships that were implemented without approval.
Existing trust relationships must be regularly audited against
approved trust relationships. This requires periodically re-
performing discovery to find all existing trust relationships so
that they can be compared against a database of approved trust
relationships. If software tools are used to perform this
auditing, enforcement may be performed in real time or very
frequently, e.g., once an hour or once per day.
Another way to help enforcement is to move all authorized keys to
protected locations (as discussed in Section 5.2) and tightly
control access to root accounts using a privileged access
management system (preferably one that also logs key-based access
to root accounts for accountability). However, regular audits
should still be performed, e.g., annually, to catch any trust
relationships that may have been missed in the normal process.
Although the focus of this section has been on approving new trust
relationships, existing legacy trust relationships should also be
approved, or at least associated with a business process,
application, or proper purpose. This was discussed in Section 5.5.
Failure to implement or enforce approvals means it is impossible to
ensure that new trust relationships are valid and appropriately
restricted. Not knowing what each trust relationship is used for
makes it very difficult to know which trust relationships can be
removed without substantial risk of disruption to business processes.
Lack of up-to-date documentation of trust relationships, including
Ylonen, et al. Expires October 06, 2013 [Page 34]
Internet-Draft Managing SSH Keys for Automated Access April 2013
lack of knowledge of which application or business process they
relate to, is one of the main causes of the current poor situation
with SSH user keys in many organization. Failure to implement and
enforce approvals for trust relationships also implies that system
administrators can continue to create unaudited backdoors to
production systems, bypassing most existing privileged access
management systems.
5.7. Rotating Existing SSH User Keys
SSH user keys are authentication credentials, like passwords. They
should be rotated (i.e., changed) regularly.
Rotating an SSH user key for a trust relationship means generating a
new identity key (key pair), storing (and configuring, if applicable)
the identity key for the source account of the trust relationship,
configuring the corresponding public key as an authorized key for the
destination account (with the same restrictions as the old key for
the trust relationship), and finally removing the old authorized key
from the destination account and the old identity key from the source
account. If the same identity key can access more than one
destination account (i.e., is used for more than one trust
relationship), then it the authorized key must be copied to (and the
old key removed from) all such destination accounts.
Rotating external keys (i.e., keys used with hosts outside the
managed environment) require special care and coordination between
the organizations responsible for the respective hosts. The basic
principle is that the new key should be added as an authorized key on
all destination hosts where the old identity key is used before the
old identity key is removed.
Authentication credentials for all trust relationships leading to
moderate-impact and high-impact systems MUST be rotated every 12
months, and it is RECOMMENDED that trust relationships leading to
low-impact systems be rotated every 12 months. It is recommended
that all keys be rotated as part of a remediation process to ensure
that any previously leaked keys cease to be usable.
If two or more users have had access to a shared account that has
access to an identity key, the identity key and any trust
relationships using it and leading to moderate-impact or high-impact
systems MUST be rotated during the remediation process and thereafter
every three months.
If an employee leaves or changes roles, immediate rotation for all
identity keys the employee is known to have accesss to and leading to
moderate-impact or high-impact systems SHOULD be triggered.
Ylonen, et al. Expires October 06, 2013 [Page 35]
Internet-Draft Managing SSH Keys for Automated Access April 2013
If a security breach is suspected, all identity keys stored on
affected servers SHOULD be immediately rotated.
If certificates are used for access, such certificates MUST be
renewed (with new private keys) annually if they can be used for
accessing moderate-impact or high-impact systems. If Kerberos is
used for configuring trust relationships, then the Kerberos
credentials used for authentication MUST be rotated annually if they
can be used for accessing moderate-impact or high-impact systems.
Failure to rotate keys allows leaked keys to continue working
forever.
Failure to rotate keys in response to an employee leaving or changing
roles means that there is no proper termination of access. Many
industries must comply with mandatory regulations that require proper
termination of access.
Failure to rotate keys in response to a suspected breach means that
keys copied by the attacker may be used to attack the systems again,
and there can be no guarantee that the system has been properly
cleaned up after the attack.
5.8. Configuring Command Restrictions on Authorized Keys
Command restrictions limit what can be done with a trust relationship
on the destination host. Typically, a command restriction (also
called "forced command") specifies the only command that can be
executed on the server using that key. If any other command is
attempted, the configured command will be executed instead or the
attempt is rejected.
A command restriction may further limit directories that can be used
for file transfers (if supported by the SSH implementation) and
whether writing files is allowed.
On some implementations, it may be necessary to prevent pseudo-tty
allocation for command restrictions to be effective.
It is usually desirable to prevent TCP/IP forwarding for all
authorized keys. Otherwise such keys could be used to mask the
source of attacks by redirecting them using port forwarding.
All non-interactive trust relationships leading to moderate-impact or
high-impact information systems MUST be configured with a command
restriction, unless an exemption has been approved as specified in
the organization's security process and based on a valid reason for
not having a forced command restriction (the relatively small effort
Ylonen, et al. Expires October 06, 2013 [Page 36]
Internet-Draft Managing SSH Keys for Automated Access April 2013
of configuring the command restriction not being a valid reason).
The specific command MUST be part of the approval, and a new approval
MUST be required if the command is later changed.
Trust relationships that are used for interactive access SHOULD NOT
have a command restriction (command restrictions that permit running
a shell and then arbitrary commands SHOULD NOT be used, because they
may be mistaken as real command restriction; if they are detected in
an audit, they SHOULD be flagged).
Regardless of impact level of the destination system, all trust
relationships intended for use with the SFTP protocol by external
parties or by lower-impact information systems MUST have a command
restriction that limits the use of the trust relationship to SFTP and
prevents interactive use.
Failure to configure command restrictions for keys increases virus
spread risk and can be used for other attacks. It also increases
risk from leaked keys.
Failure to configure command restrictions for trust relationships
used with external parties may allow a virus or attack to enter the
organization.
5.9. Configuring IP Address Restrictions on Authorized Keys
Source restrictions (also called "from" option in authorized keys
files) specify from which IP addresses an authorized key can be used.
Trust relationships permitting interactive access to moderate-impact
and high-impact systems SHOULD specify a source restriction to
hardened jump servers (privileged access management systems) or a
transparent access auditing solution SHOULD be used to ensure such
access is properly controlled and audited. If any such trust
relationships have been approved, they MUST be listed in an annual
audit report and their existence rejustified annually.
Source restrictions SHOULD be used for all trust relationships
leading to high-impact systems. Otherwise, the use of source
restrictions is OPTIONAL. They are laborious to configure manually
and make, e.g., IP renumbering and IPv6 transition painful. It is
also easy to make mistakes where, e.g., a secondary server for some
critical service is not permitted by a source restriction, which
could increase risk of outages under unusual operating conditions.
On the other hand, they can significantly reduce the exploitation
potential of leaked keys.
Ylonen, et al. Expires October 06, 2013 [Page 37]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Failure to configure source restrictions has only mild security
impact if other recommendations are followed. It is in part
compensated by regular key rotation that also reduces the potential
for exploitation of leaked keys, and thus a reasonable balance may be
to not implement source restrictions for most trust relationships.
However, source restrictions can completely prevent the exploitation
of leaked keys (without sophisticated active network-level IP
spoofing attacks), and thus is warranted for high-impact systems.
6. Continuous Monitoring and Management of SSH Keys and Automated
Access
The remediation process (as discussed in Section 5) addresses both
the one-time analysis and clean-up of existing legacy SSH trust
relationships and the implementation of an ongoing approval process
for validating, documenting, and restricting new trust relationships
that are added to the environment. Following the approval process
(discussed in Section 5.6) for all new authorized keys added to the
environment serves as a preventive control. Continuous monitoring of
trust relationships is needed to provide ongoing detection of non-
compliance, including instances where the approval process was too
lenient or was bypassed altogether. Continuous monitoring is also
important for identifying trust relationships that violate policy,
that can be removed because they have become unused or otherwise not
needed, or that require keys to rotated.
6.1. Continuous Monitoring of Changes to Trust Relationships
Proper management of automated access requires continuous monitoring
of the IT environment because system administrators operating as root
may add new trust relationships for any user account. Continuous
monitoring is also prudent for detecting keys that are no longer
used, identifying external keys, and identifying changes in the
patterns of usage of automated access.
The main rationale for the continuous monitoring of the environment
and annual audits and requiring reporting and revalidation of certain
aspects of automated access annually is to enforce proper policy
(policies usually do not get implemented if their implementation is
not enforced or if waivers are too easily available). However, IT
environments are complex and sometimes there is a need to have
automated access relationships for special purposes that would not
otherwise be advisable. Special waivers and corresponding approvals
can be used for implementing such special cases, but they MUST be
revisited annually and MUST NOT be used to circumvent remediating the
existing environment.
Ylonen, et al. Expires October 06, 2013 [Page 38]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Ideally, continuous monitoring should be a real-time or near-realtime
process. For some areas, hourly or daily analysis would generally be
perfectly sufficient. Using automated tools allows monitoring to be
performed more frequently, cost-effectively, and more thoroughly. On
the other hand, if implemented manually using audits, cost
constraints may limit continuous monitoring to annual audits. Even
when continuous monitoring is performed using software tools,
auditors SHOULD do some random sampling and testing annually to
verify that the continuous monitoring tools are working properly.
In some respects, continuous monitoring resembles re-performing
discovery on an ongoing basis. Configured SSH user keys and trust
relationships throughout the environment need to be discovered, and
checked for validity. Alerts, audit findings, or reports may be
produced based on the results of the checks. As in the discovery
phase, the continuous monitoring process MUST identify every trust
relationship and authorized key throughout the managed IT environment
so that they can be compared against a database of approved trust
relationships.
For each found authorized key, the trust relationship should be
analyzed to identify possible instances of non-compliance or
excessive security risk. Trust relationships leading to moderate-
impact or high-impact hosts with the following attributes MUST be
reported for further investigation:
Trust relationships without proper approval
Trust relationships without proper justification and an associated
application/business process
Trust relationships that have no command restriction configured
Trust relationships with command restrictions that do not match
the command restrictions specified during approval
Trust relationships from low-impact hosts with no command
restrictions
Trust relationships that cross defined internal boundaries
Trust relationships that have not been used in the last 12 months
(or other time period specified by policy)
Trust relationships whose keys have not been rotated in the last
12 months (or other time period specified by policy)
Ylonen, et al. Expires October 06, 2013 [Page 39]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Trust relationships leading to low-impact hosts with the following
attributes SHOULD be reported for further investigation:
Trust relationships without proper approval
Trust relationships without proper justification and an associated
application/business process
Trust relationships leading to privileged accounts that have no
command restriction configured
Trust relationships that have not been used in the last 12 months
(or other time period specified by policy)
Trust relationships whose keys have not been rotated in the last
12 months (or other time period specified by policy)
If trust relationships have existing waivers (e.g., for having no
command restrictions, crossing boundaries, or not being used or
rotated), then special approval of the waiver MUST be verified and
waivers SHOULD be re-justified and approved annually. Trust
relationships that are flagged by continuous monitoring MUST be
investigated and resolved. Possible resolution activities consist of
the following:
Obtaining approvals and justifications (including the associated
application/business process) for trust relationships that are
valid, including getting secondary approval by higher-level
management for trust relationships that cross boundaries. This
would retroactively apply the approval process described in
Section 5.6.
Adding command restrictions to the authorized keys file to limit
access according to policy. (See Section 5.8)
Removing trust relationships that are unused, not needed, or
otherwise invalid. (See Section 5.4)
Rotating private keys. (See Section 5.7)
Obtaining waivers with appropriate levels of approval.
Even if waivers are obtained, the resulting risk needs to be
considered. For example, if the trust relationship from a low-impact
host to a medium-impact or high-impact host has inadequate command
restrictions, then the low-impact host MUST be reclassified as having
the impact level of the higher-impact host, even if a waiver is
obtained.
Ylonen, et al. Expires October 06, 2013 [Page 40]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Failure to monitor SSH trust relationships prevents the organization
from enforcing policies related to SSH user keys. Policy enforcement
and detection of non-compliant trust relationships is needed to
prevent new keys from re-creating the same type of problems that
existed in the legacy population of user keys. Failure to enforce
approvals for newly-added trust relationships allows users to create
unaudited backdoors or trust relationships that cross boundaries or
are unrestricted. If there is no continuous monitoring for
unapproved or inappropriate trust relationships, such trust
relationships will be essentially permanent.
6.2. Removal of Trust Relationships
Trust relationships MUST be removed when they are no longer needed.
Ideally, the business or application owner of a trust relationship
SHOULD expressly request that it be removed as soon as it is no
longer needed. In addition, the owner MAY periodically recertify and
validate the continuing need for each trust relationship.
Sometimes a trust relationship may be removed by express request,
e.g., when a business process is changed so that it is no longer
needed.
Sometimes a trust relationship may be removed because the application
or business process it relates to is decommissioned or replaced by
another application.
Sometimes a trust relationship may be removed because continuous
monitoring detects that it is no longer being used. This basically
implies that something changed in the environment, but the trust
relationship was inadvertently not removed at that time. (This
scenario appears to be very common in practice). In addition, some
trust relationships may be removed because continuous monitoring
detected an unapproved or otherwise invalid trust relationship.
When trust relationships are removed, the associated authorized key
(if it is key-based) MUST be removed from the authorized keys file of
the destination server.
When there are no trust relationships remaining using a particular
identity key, the identity key SHOULD be removed.
6.3. Periodic Rotation of Trust Relationships
Keys must be regularly rotated as specified in Section 5.7.
7. Policy Recommendations
Ylonen, et al. Expires October 06, 2013 [Page 41]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Effective security policies are important for defining expectations
for controls and acceptable user behavior. Well-defined policies are
no less important for governing SSH user keys than for other elements
of an organization's security program. In fact, because few people
understand the problem and poor SSH user key management practices are
so pervasive, policies are essential to the success of any SSH key
management remediation process.
To support the key remediation and continuous monitoring steps
outlined elsewhere in this document, there is a common core set of
policy statements that should be adopted by all organizations. The
following policy statements are RECOMMENDED (with limited
organizational-specific customization and optionally limited to apply
to moderate-impact and high-impact systems) to provide the governance
framework for controlling SSH user keys:
All SSH servers shall be configured to store authorized keys in a
root-owned /etc directory (or other suitable directory not
writable by normal users).
Users shall not create new identity keys or authorized keys, shall
not share identity keys with other users, and shall not copy or
move identity keys to other SSH client systems.
SSH identity keys and authorized keys shall be provisioned only by
the access management group.
SSH user key requests shall follow the standard provisioning
process. All requests for SSH authorized keys shall be
provisioned only when required by a valid business need and
approved by the destination account's owner.
Trust relationships shall not cross security zone boundaries. If
this is a requirement for a trust relationship, then the new user
key request shall provide a rationale and require a waiver
approved by the server operations director and information
security director.
Trust relationships shall not allow access from low-impact systems
to higher-impact systems. If such trust relationships are
required, then those low-impact systems shall be reclassified as
higher-impact systems and shall be subject to the higher security
requirements of higher-impact systems, unless command restrictions
prevent obtaining an interactive shell and writing arbitrary files
using such trust relationships.
Trust relationships for non-interactive access shall be configured
with command restrictions. If commands cannot be restricted, then
Ylonen, et al. Expires October 06, 2013 [Page 42]
Internet-Draft Managing SSH Keys for Automated Access April 2013
the new user key request shall provide a rationale and require a
waiver approved by the server operations director and information
security director.
Trust relationships permitting interactive access (especially to
privileged accounts) shall enforce source restrictions to
authorized, hardened jump servers or transparent access auditing
solutions are used that ensure such access is properly controlled.
A registry of SSH user keys shall be maintained for tracking trust
relationships (including their owner, purpose, approval,
restrictions, and business purpose) throughout the environment.
SSH user keys and corresponding trust relationships shall be
removed when no longer needed or no longer used.
Usage of SSH user keys shall be tracked so that unused authorized
keys can be identified.
All SSH user keys shall be rotated annually.
When a user terminates employment or transfers to new job
responsibilities, all keys assigned to that user shall be rotated,
or the corresponding authorized key relationships shall be
removed.
If a key is compromised or shared by two or more users, then the
key shall immediately be rotated, or the corresponding authorized
key relationships shall be removed.
SSH authorized keys shall be revalidated annually by the
destination account owner to ensure that trust relationships
continue to be valid and proper.
Authorized keys for privileged accounts such as root shall be
revalidated annually and approved by the server operations
director and information security director.
Trust relationships throughout the network shall be monitored at
least annually to enforce compliance with this policy. At a
minimum, monitoring activities shall be in place to detect the
following types of non-compliance for immediate resolution:
SSH user key trust relationships that bypassed the formal
provisioning process and were not authorized and configured by
the access management group
Ylonen, et al. Expires October 06, 2013 [Page 43]
Internet-Draft Managing SSH Keys for Automated Access April 2013
SSH user key trust relationships that cross security zone
boundaries
SSH user keys that have been not rotated in over a year
Dormant trust relationships that have not been used
Other policy statements are highly dependent on the risk tolerance
and context of each organization. Depending on the unique
circumstances of the organization, these policy statements may or may
not be applicable. During the remediation process, organizations
often make risk-based decisions about how to cost-effectively control
and manage their SSH keys in their own context. It is critical that
these decisions be properly reflected in security policy in order to
influence user behavior and provide a framework for organization-
specific controls. Examples of these types of policy statements are
provided below:
All SSH user keys assigned to human users for interactive logins
shall be assigned a passphrase that is at least 15 characters
long. (The reason for this policy is self-evident.)
SSH trust relationships for human accounts shall be limited to
other human accounts. Human accounts shall never have trust
relationships to system accounts or service accounts. (This
policy makes sense for organizations with lots of keys and
transitive trust relationships that are too difficult to manage.
Eliminating human-to-system account trust relationships can help
simplify the mesh of trust and therefore minimize the risk of
inadvertently allowing unneeded access.)
SSH user keys shall be used only for automated access and shall
not be used for interactive logins by human users. (An
organization may decide to do this to reduce the number of keys in
the environment and lighten the load on the provisioning process,
for example, if no automation is available and provisioning is
done manually.)
SSH servers shall be configured to deny connections to the root
account. (If key-based connections to root are not required, then
setting "PermitRootLogin no" can significantly contain the damage
that can be done through unauthorized use of keys).
Unique SSH host keys shall be created for every system. (This is
essential when SSH host-based authentication is used and for
protecting against man-in-the-middle attacks.)
Ylonen, et al. Expires October 06, 2013 [Page 44]
Internet-Draft Managing SSH Keys for Automated Access April 2013
8. Considerations for Software Tools
All requirements specified in this document can be implemented
manually and with regular audits, without using software tools. Use
of software tools is OPTIONAL. However, automated software tools for
managing SSH keys are commercially available from multiple vendors
and their use is RECOMMENDED in large environments, as they can
substantially reduce the time, cost, and effort needed for
remediating existing SSH user keys and provide substantial ongoing
cost savings for continuously managing and monitoring SSH keys in an
organization.
Here are certain key things to consider in planning an SSH key
management remediation solution and its deployment:
Does the solution support all required operating systems where SSH
keys need to be managed (including mainframe, if applicable)?
Does the solution support all SSH implementations and versions
that are use in the environment, including their key formats and
fingerprint formats?
Does the solution support keys moved to protected, root-only-
writable locations? Can it help move keys to such locations? How
does it determine where the keys are stored on each host?
Can trust relationships that are not actually used be
automatically detected and proposed for removal (with selective
approval)?
Can the solution associate trust relationships and keys with an
application, business process, or other purpose? Can it enforce
that all authorized keys have a documented purpose? How is this
implemented for legacy trust relationships (from time before
deployment of the solution)? Can it distinguish legacy keys from
those that are set up afterwards?
How does the solution implement approvals for new keys? How does
it integrate to existing workflows and tools? Does it support an
approval workflow which integrates into external systems?
Can creation of new keys and trust relationships be automated
based on approvals done in an existing IT change control system?
If no existing IT change control system is in use in the
organization, does the solution provide one to enforce approvals?
Does the solution support grouping systems based on the impact of
their disruption or compromise?
Ylonen, et al. Expires October 06, 2013 [Page 45]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Does the solution support rotating SSH user keys?
How is key rotation implemented for external trust relationships/
external keys? Can it automatically recognize external keys?
Does the solution support configuring command restrictions for
authorized keys/trust relationships? Does it support requiring
special approvals for trust relationships that do not have a
command restriction?
Does the solution support configuring source restrictions for
authorized keys/trust relationships?
Does the solution provide continuous monitoring capabilities as
specified in Section 6?
If the management system is unavailable for some reason, will
normal operation of managed hosts be disrupted (other than not
being able to create/modify trust relationships)?
Will the solution run as root on managed hosts, or can it use a
non-root account and "sudo" (or equivalent) to perform limited
operations as root?
Is the solution able to retry discovery, key setups, etc. on
hosts that are down or unreachable at the time of the initial
attempt? How does the solution cope with poor network
connectivity?
Does the solution support user accounts stored in LDAP or Active
Directory? How does it prevent crashing LDAP or Active Directory
servers by reading directory contents from all servers
simultaneously?
Can the solution discover keys from directories that are not
readable by root (e.g., NFS directories using the "root_squash"
option)?
Does the solution work with SELinux, if such support is needed?
How can the solution save operational costs in SSH user key
management in the organization? Have existing user key management
costs been estimated on an annual level?
8.1. Reducing Cost and Improving Security by Automation
Some large organizations are seeing over a hundred thousand new
authorized keys being configured every year. Some trust relationship
Ylonen, et al. Expires October 06, 2013 [Page 46]
Internet-Draft Managing SSH Keys for Automated Access April 2013
setups may involve installing the same authorized key on thousands of
servers. Given that setting up and a manual trust relationship can
easily take fifteen minutes or more, the cost can be millions of
dollars per year.
Some software tools allow integration into existing security
entitlement approval systems, and can implement a suitably formatted
trust relationship setup request automatically, without manual
intervention.
Such automation provides several benefits:
Substantial cost savings by eliminating the manual work associated
with trust relationship setups.
Substantial reduction in outages due to errors in manual key
setups.
Need for root access is significantly reduced, as SSH user key
setups no longer require root access.
Substantial security improvements from eliminating root access (or
the need for being able to install new trust relationships) from
most system administrators (having five people with access to the
software tool system is much more secure than having two hundred
administrators able to manually install keys).
9. Security Considerations
This document is all about security, including how to evaluate the
impact of disruption or compromise of information systems, how to
reduce the risk to information system from automated access, how to
remediate current unmanaged base of SSH user key based trust
relationships for automated access, and how to manage and
continuously monitor automated access as an ongoing process.
Section 1.5 defined information system impact levels based on FIPS
199, but expanding on it by considering information systems having
automated access to higher-impact information systems as also having
the impact level of the higher-impact information system.
Section 2.2.6 briefly discussed unmanaged host keys and how they can
be used to compromise authentication and integrity protection using
active network-level man-in-the-middle attacks.
Section 3 discussed various threats arising from poorly managed
automated access and SSH user keys, including virus spread threat,
unaudited backdoor threat, leaked keys granting near-permanent
Ylonen, et al. Expires October 06, 2013 [Page 47]
Internet-Draft Managing SSH Keys for Automated Access April 2013
access, and lack of proper termination of access when an employee
leaves or changes roles. It also discussed how ports opened in
firewalls may be used for unintended purposes, including command
execution, access to internal services, or for hiding source of
attacks, if not properly controlled.
Section 4 discussed assessing the threats and exposure of an
organization to them as a quick precheck during audit, before
engaging in a full discovery and remediation project.
Section 5 provided recommendations on how to bring existing trust
relationships for automated access, particularly SSH user keys, under
control.
Section 6 provided recommendations for continuous monitoring and
management of automated access and SSH user keys.
Section 7 provided recommendations for organizational security
policy.
As a summary, automated access between systems MUST NOT be overlooked
in identity and access management. It has become so prevalent that
many organizations have many times more credentials for automated
access to their information systems that they have user accounts for
employees.
Management of SSH keys is about managing access, with strong ties to
identity and access management, security architecture, privileged
access management, IT change control, and security audits.
Cryptographic properties of the keys are in practice of little
importance, as all keys generated with default settings by most
commonly used SSH implementations are still cryptographically
reasonably strong.
Virus spread threat using automated trust relationships may remove
defense in depth against attacks and malware. Automated access may
provide pathways for bypassing existing privileged access management
systems. Rogue administrators may use SSH user keys to create near-
permanent unaudited backdoors, and leaked keys may be used for
breaking into production servers. Even accidental access using
poorly configured trust relationships has in the past caused
substantial financial losses.
Ylonen, et al. Expires October 06, 2013 [Page 48]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Risks of unmanaged, unaudited automated access are sufficiently high
and the state of their management in some of the largest
organizations in the world so appalling that all organizations should
evaluate to what extent they use automated access within and between
their information systems, how it is managed and audited, and whether
they are exposed to the risks.
IT security auditors, policy makers, and security architects are
urged to take automated access and SSH keys on their agenda.
10. Acknowledgements
The authors thank and acknowledge the contribution of the following
people to the development of this document and/or the underlying
ideas: Bruno Canamasas, Roman Hernandez, Jan Hlinovski, Kalle
Jaaskelainen, Mitch Klein, Sami Lehtinen, Sami Marttinen, Matthew
McKenna, S. Moonesamy, Tim Polk, Joe Scaff. We also wish to thank
anyone else who has helped by providing comments or input.
11. Glossary
account: A user account on a computer. An account may belong to an
actual person (interactive user) or may be used internally in a
system (in which case it is sometimes called a functional account,
process account, system account, or non-user account).
Active Directory: A directory service created by Microsoft for
Windows domain networks, providing a central repository for user
information, user groups, and various other kinds of configuration
information. Active Directory makes use of the LDAP and Kerberos
protocols, among others, and can serve as an LDAP directory and
Kerberos Key Distribution Center (KDC).
Advanced Persistent Threat (APT): A group, such as a government,
with the capability and intent to persistently target an entity
using a variety of cyberwarfare techniques, such as espionage,
social engineering, custom malware, and sophisticated hacking and
evasion techniques.
authorized key: A public key that has been configured as authorizing
access to an account by anyone capable of using the corresponding
private key (identity key) in the SSH protocol. An authorized key
may be configured with certain restrictions, most notably a forced
command and a source restriction.
automated access: Access to a computer without an interactive user,
generally machine-to-machine access. Automated access is often
triggered from scripts or schedulers, e.g., by executing an SSH
Ylonen, et al. Expires October 06, 2013 [Page 49]
Internet-Draft Managing SSH Keys for Automated Access April 2013
client or a file transfer application. Many programs may also use
automated access using SSH internally, including many privileged
access management systems and systems management tools.
automated trust relationship: A trust relationship for automated
access.
command restriction: See forced command.
certificate: A public key signed by a certification authority (CA)
key, together with additional information about the public key.
X.509 [RFC3280] is a widely used standard for certificates.
OpenSSH also implements its own proprietary certificate format;
however, use of the proprietary format is NOT RECOMMENDED (in part
because OpenSSH's authorization model does not permit reliably
determining which trust relationships exist granting access to a
server).
CIFS: Common Internet File System, a protocol used on Windows for
file sharing. The protocol is unencrypted and may be read and
subverted by a network-level attacker. The protocol is extremely
widely used in Windows environments, less frequently with Unix/
Linux.
CISO: Chief Information Security Officer. A person responsible for
IT security in an organization.
COBIT: Control Objectives for Information and Related Technology, a
framework created by ISACA (Information Systems Audit and Control
Association) for information technology (IT) management and IT
governance.
CryptoAuditor: A product from SSH Communications Security for
controlling and auditing content of SSH sessions and other
encrypted communications, including file transfers. Can also be
used for auditing use of SSH/SFTP connections at a firewall and
for privileged access auditing for key-based access.
destination account: In an SSH connection or trust relationship, the
user account for which authentication is provided and under which
any commands or other operations performed by the connection are
executed (acknowledging that some commands, such as "sudo", may
further escalate privileges).
destination host: In an SSH connection or trust relationship, the
destination host of the connection. A destination host would
typically run an SSH server.
Ylonen, et al. Expires October 06, 2013 [Page 50]
Internet-Draft Managing SSH Keys for Automated Access April 2013
DSA: Digital Signature Algorithm. An algorithm for public-key
cryptography, particularly digital signatures. It is a United
States government standard, specified in FIPS 186-3.
external key: An authorized key that is used from outside the
organization (or outside the environment considered for SSH user
key management purposes), or an identity key that is used for
authenticating to outside the organization (or outside the
environment considered for SSH user key management purposes). Key
rotation can break external keys, and therefore it must be ensured
that the other side of trust relationships involving external keys
is also properly updated as part of rotation. Alternatively,
rotation of external keys may be prevented, but that is not a
sustainable solution long-term.
fingerprint: A hash value of a (public) key encoded into a string
(e.g., into hexadecimal). Several fingerprint formats are in use
by different SSH implementations.
FISMA: Federal Information Security Management Act of 2002, a United
States law that mandates how US government agencies must implement
their it security.
forced command: A restriction configured for an authorized key that
prevents executing commands other than the specified command when
logging in using the key. In Tectia SSH and OpenSSH, forced
command can be configured by using a "command=" restriction in an
authorized keys file.
functional account: An account used for running applications or
other processes, as opposed to an interactive account normally
used by a person. Functional accounts are sometimes also called
process accounts, system accounts, or non-user accounts (with
slight nuances in meaning).
host: A computer or other device on a network. A host may be a
physical computer, a virtual machine, or any other logical or
physical device that can communicate on a network, typically using
one or more IP addresses. Some hosts may be multi-homed, meaning
that they have more than one IP address.
host certificate: A certificate for a host key for host
authentication in the SSH protocol (typically an X.509v3
certificate). Host certificates can eliminate the need for
distributing host keys to all communicating hosts, greatly
simplifying management and rotation of host keys. Widely used
with Tectia SSH to avoid copying host keys and to make rotating
them easier.
Ylonen, et al. Expires October 06, 2013 [Page 51]
Internet-Draft Managing SSH Keys for Automated Access April 2013
host credential: A Kerberos credential that is used for
authenticating to a Kerberos KDC as a host principal.
host key: A public key used for authenticating a host in the SSH
protocol to hosts that want to communicate with it (each host also
generally has its own private host key). Some hosts may have more
than one host key (e.g., one for each algorithm). Host keys are
used for authenticating hosts (machines) themselves, not users or
accounts, whereas identity keys and authorized keys relate to
authenticating users/accounts and authorizing access to accounts
on hosts. See also Section 2.2.6.
identity key: A private key that is used for authentication in the
SSH protocol; grants access to the accounts for which the
corresponding public key has been configured as an authorized key.
indirect trust relationship: A sequence of trust relationships that
indirectly leads to another account. For example, account A may
be able to log into account B, which may be able to log into
account C; then, account C indirectly trusts account A (and B
directly trusts A and C directly trusts B). Indirect trust
relationships may involve many kinds of trust relationships (e.g.,
SSH keys, Kerberos and privilege escalation).
interactive user: A person (human) that uses a computer (and may
type passwords or provide other authentication credentials as
needed), as opposed to a computer that performs operations on
another computer in an automated fashion.
jump host: A server that a user logs into for the purpose of logging
infrom there to another server. They are used for privileged
access management, centralizing configuration of access to a large
number of servers (e.g., at retail locations), and for accessing
restricted subnets that do not have normal routing from the rest
of the organization.
KDC: Key Distribution Center, a component of Kerberos.
Kerberos: A centralized authentication and single-sign on system.
Also used as part of Active Directory. See RFC 4120 [RFC4120].
key: A cryptographic key. In this document, keys generally refer to
public key cryptography key pairs used for authentication of users
and/or machines (using digital signatures). Examples include
identity key and authorized keys. The SSH protocol also uses host
keys that are used for authenticating SSH servers to SSH clients
connecting them.
Ylonen, et al. Expires October 06, 2013 [Page 52]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Key Distribution Center: A component of Kerberos and Active
Directory infrastructure that verifies credentials and issues
tickets to principals (e.g., users and hosts). An Active
Directory server includes a KDC. Frequently multiple KDCs
synchronize information for redundancy.
known host: A host whose host key is known (to a particular SSH
client).
LDAP: Lightweight Directory Access Protocol, a protocol for
accessing and maintaining distributed directory information
services. See RFC 4511 [RFC4511].
locking down keys: This refers to moving authorized keys to root-
owned (or otherwise protected) locations, so that non-root users
cannot add new authorized keys to themselves. This helps prevent
system administrators and users from creating key-based backdoors
that may survive the termination of their account and bypass
privileged access management systems. See Section 5.2 for more
information.
NERC: North American Electric Reliability Corporation, an
organization that, among other things, maintains the Critical
Infrastructure Protection (CIP) standards that set minimum
security requirements for protecting power generation and
distribution infrastructure.
NFS: Network File System, a file sharing protocol widely used in
Unix/Linux environments in enterprises and universities. The
protocol is unencrypted and may be subverted by a network-level
attacker, permitting modification of any file. (NFS4 adds some
security but is rarely used at the time of this writing, or is
used with the security features disabled.)
OpenSSH: An open source implementation of SSH based on Tatu Ylonen's
original free version of SSH from 1995 and further developed by
the OpenBSD group.
orphaned key: An authorized key for which no corresponding public
key can be found. An orphaned key may be currently unused, or the
identity key might just be on a server that was not part of the
discovery process (it could be an external key). Therefore
orphaned keys should not be removed without first monitoring
whether they are actually used.
password logger: A software or hardware module for recording
keystrokes, especially user names and passwords, typed by an
interactive user. Password loggers are nowadays commonly included
Ylonen, et al. Expires October 06, 2013 [Page 53]
Internet-Draft Managing SSH Keys for Automated Access April 2013
in various malware and used as part of Advanced Persistent Threat
(APT) attacks. Hardware-based key loggers may used in conjunction
with physical access to a desktop or laptop (perhaps using a
social engineering attack, such as getting hired as a janitor) to
obtain passwords for entry into information systems.
PCI DSS: A set of Data Security Standards defined by the Payment
Card Industry Security Standards Council, an organization
originally formed by major credit card companies.
PKI: See Public Key Infrastructure.
privilege escalation mechanism: A means for escalating a user's (or
processes) privileges from those of one account to those of
another account (particularly a root or Administrator account).
Examples of privilege escalation mechanisms include intentional
provilege escalation tools such as "sudo" and unintentional
privilege escalation possibilities based on vulnerabilities and
configuration errors (experience has shown that it is very often
possible to find vulnerabilities or misconfigurations on that
enable privilege escalation once inside a host). An attacker
having access to an account can generally change the configuration
of the account to cause the user to unknowingly run the attacker's
programs that may, e.g., steal the user's password and then use
the password to spread the attack. Also, having high-level access
on one host on a network may effectively imply access to every
user account on every host whose home directory is in networked
storage accessible through the same network as the compromised
host. Against advanced attackers, even vulnerable embedded
devices such as switches, printers and copiers can be used to
perform network-level active attacks against other hosts. Some
limit will have to be put on what theoretical possiblities are
considered, however. Privilege escalation possibilities
effectively imply additional trust relationships that may in turn
imply a multitude of indirect trust relationships.
Public Key Infrastructure: An arrangement that binds public keys
with respective user identities using digital signatures issued by
a certificate authority (CA). See RFC 3280 [RFC3280].
Putty: An Open Source SSH client for Windows.
Reflection for Secure IT: A commercial version of SSH from
Attachmate.
root account: In Linux/Unix, a privileged account that is usually
able to do anything in a computer (including reading any files and
modifying any programs). In Windows, Local Administrator and
Ylonen, et al. Expires October 06, 2013 [Page 54]
Internet-Draft Managing SSH Keys for Automated Access April 2013
Domain Administrator have similar or even broader power. (This
document mostly talks about root access as SSH is mostly used on
Linux/Unix and embedded devices, but the same issues often also
apply to other technologies and the Windows environment.)
rotating a key: Key rotation means changing the key, i.e., replacing
it by a new key. The places that use the key or keys derived from
it (e.g., authorized keys derived from an identity key, legitimate
copies of the identity key, or certificates granted for a key)
typically need to be correspondingly updated. With SSH user keys,
it means replacing an identity key by a newly generated key and
updating authorized keys correspondingly. See also external key.
RSA: An algorithm for public-key cryptography based on the
difficulty of factoring large integers, invented by Ron Rivest,
Adi Shamir and Leonard Adleman.
SELinux: Security-Enhanced Linux, a Linux feature that provides
mechanisms for supporting access control security policies.
SELinux is enabled by default on several Linux distributions (at
least in what is called "targeted" mode, where it protects
selected services).
SFTP: SSH File Transfer Protocol, a file transfer and file sharing
protocol typically used with the SSH protocol and originally
developed by Tatu Ylonen for ssh-2.0. The protocol is
unofficially described in SFTP [SFTP]; there is no normative
reference available at the time of this writing.
source account: In an SSH connection or trust relationship, a source
account is the user account on the host initiating the connection,
typically the user account under which an SSH client runs.
source host: In an SSH connection or trust relationship, a source
host is the host initiating the connection (typically by running
an SSH client).
source restriction: A restriction configured for an authorized key
that limits the IP addresses or host names from which login using
the key may take place. In OpenSSH, source restrictions can be
configured by using a "from=" restriction in an authorized keys
file.
SOX: Sarbanes-Oxley Act of 2002, also known as the Public Company
Accounting Reform and Investor Protection Act, a United States law
that, among other things, sets requirements for protecting certain
sensitive information in listed companies.
Ylonen, et al. Expires October 06, 2013 [Page 55]
Internet-Draft Managing SSH Keys for Automated Access April 2013
SSH: SSH (Secure Shell) is a protocol and tool for remote system
administration, file transfers, and for tunneling TCP/IP
communications securely, originally developed by Tatu Ylonen.
SSH Communications Security: A company founded by Tatu Ylonen, the
inventor of SSH, with products improving security and operational
efficiency of large IT environments, particularly for large SSH
environments. See http://www.ssh.com [2].
sudo: A privilege escalation mechanism/tool on Unix/Linux that can
be used for executing commands as root from a non-root account.
The operation of "sudo" depends on its configuration. In some
configurations, certain accounts may perform any command as root
using "sudo". In some other systems, certain users, such as
members of a "wheel" group can perform commands as root by
confirming the operation with the user's password. Several
commercial tools also exist for the same purpose.
Tectia Manager: A product for managing SSH host keys and
configurations, from SSH Communications Security.
Tectia SSH: A commercial version of SSH servers and clients for
Windows, z/OS (IBM mainframes), Unix, and Linux from SSH
Communications Security.
transparent access auditing: A method of doing privileged access
management and auditing on the network (using a co-operative man-
in-the-middle attack to transparently gain access to the
connection) or at an SSH server (by having auditing code built
into the server). See, e.g., the CryptoAuditor solution.
trust relationship: Something that permits a source account to log
in to a destination account (possibly on a different computer).
In a sense, the destination account trusts the source account, and
if the source account is compromised, so is the destination
account. An example is an authorized key (and corresponding
identity key) configured for public key authentication in SSH.
See also indirect trust relationship and privilege escalation.
Universal SSH Key Manager: A product from SSH Communications
Security for managing and monitoring SSH keys and other trust
relationships for automated access.
user key: A key that is used for granting access to a user account
in the SSH protocol (as opposed to a host key, which does not
grant access to anything but serves to authenticate a host). Both
authorized keys and identity keys are user keys.
Ylonen, et al. Expires October 06, 2013 [Page 56]
Internet-Draft Managing SSH Keys for Automated Access April 2013
X.509: A standardized widely used certificate format for public key
infrastructure (PKI). See RFC 3280 [RFC3280].
12. References
[FIPS199] Evans, D. L., Bond, P. J., and A. L. Bement, "Standards
for Security Categorization of Federal Information and
Information Systems", FIPS Publication 199, February 2004.
[FIPS200] Gutierrez, C. M. and W. Jeffrey, "Minimum Security
Requirements for Federal Information and Information
Systems", FIPS Publication 200, March 2006.
[NIST800-53]
Locke, G. and P. D. Gallagher, "Recommended Security
Controls for Federal Information Systems and
Organizations", NIST Special Publication 800-53 (revision
3 with updates as of 05-01-2010), August 2009.
[KENT] Kent, G. and B. Shrestha, "Unsecured SSH - The Challenge
of Managing SSH Keys and Associations", SecureIT White
Paper, 2010.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 4251,
April 2002.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4251,
July 2005.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
Ylonen, et al. Expires October 06, 2013 [Page 57]
Internet-Draft Managing SSH Keys for Automated Access April 2013
[SFTP] Galbraith, J. and O. Saarenmaa, "SSH File Transfer
Protocol", draft-ietf-secsh-filexfer-13.txt (work in
progress), June 2006.
Authors' Addresses
Tatu Ylonen
SSH Communications Security
Email: ylo@ssh.com
URI: http://www.ssh.com
Greg Kent
SecureIT
Email: gkent@secureit.com
Murugiah Soyppaya
NIST
Email: soyppaya@nist.gov
Ylonen, et al. Expires October 06, 2013 [Page 58]
