IP Library Granted Patent US 9,363,080
Granted Patent B2
US 9,363,080 · App. 14/131,635 · Granted Jun 7, 2016

System for managing cryptographic keys and trust relationships in a secure shell (SSH) environment

View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 9,363,080
App. No.
14/131,635
Granted
Jun 7, 2016
Kind
B2
Abstract

A system for managing cryptographic keys and trust relationships in a secure shell (SSH) environment by mapping network servers, clients, and appliances and locating SSH keys and key pairs associated with each device. The system provides for mapping the network topology and all SSH keys and key pairs stored on network connected devices, and the creation of a master database of all devices, keys and key pairs, key types and encryption strength, and user accounts with which each key or key pair is associated. The mapping and database enable the effective management of SSH keys and key pairs, detection of errors and weakness, elimination of orphaned or outdated keys, correction of all deficiencies, and replacement of keys in accordance with policies set by the organization maintaining the network.

Claims (143)

1. A system for managing cryptographic keys and trust relationships in a secure shell (SSH) network environment, the system configured to:

identify SSH devices in the network environment;

collect SSH-related information including known host keys, client key pairs, authorized keys and server key pairs from the identified SSH devices;

centrally store the collected information;

determine which SSH devices acting as SSH clients and associated accounts have a server trust relationship with SSH devices acting as SSH servers by correlating known host keys to public keys in SSH server key pairs from the centrally stored information;

determine which SSH devices acting as SSH clients and associated accounts have a client trust relationship with SSH devices acting as SSH servers and associated accounts by correlating authorized keys to public keys in SSH client key pairs from the centrally stored information.

2. The system of claim 1 in which the SSH devices are identified by iteratively performing one or more of:

from previously known or additionally identified SSH devices, collect SSH-related information including SSH Known Host Keys, Authorized Keys, Client Key Pairs, Server Key Pairs, and connection logs; and

analyze the collected SSH-related information by:

identifying additional SSH servers at network addresses associated with collected SSH Known Host Keys for which no corresponding SSH Server Key Pair was found in the collected SSH-related information;

identifying additional SSH clients by detecting collected SSH Authorized Keys for which no corresponding SSH Client Key Pair exists in the collected SSH-related information and determining a location of those SSH clients from collected connection logs; and

evaluating any collected connection logs to identify SSH clients or SSH servers from which SSH-related information has not yet been collected.

3. The system of claim 1 in which the collected SSH-related information from the identified SSH devices further includes at least one of:

user accounts associated with each authorized key found;

SSH server configuration data, including at least one of:

configuration file location;

whether ignore RHosts is enabled;

whether ignore user known hosts is enabled;

whether empty passwords are allowed;

whether public key login is allowed;

whether password login is allowed;

whether root login is allowed;

whether the SSH server is active; and

commands, programs, scripts, restrictions or other optional configuration items associated with authentication;

user accounts associated with each Client Key Pair and each known host key; and

access logs documenting SSH connections.

4. The system of claim 1 , wherein the system is configured to correct non-compliant policy conditions by at least one of:

replace specific SSH server key pairs and matching known host keys by:

generating a new SSH server key pair;

placing a public key from the new SSH server key pair at all locations of the known host keys being replaced;

placing the new SSH server key pair at a same location as a SSH server key pair being replaced;

removing the SSH server key pair being replaced; and

removing all known host keys being replaced; and

replace specific SSH client key pairs and matching authorized keys by:

generating a new SSH client key pair;

placing a public key from the new SSH client key pair at a same location of an authorized key being replaced;

placing the new SSH client key pair at a same location as an SSH client key pair being replaced;

removing the SSH client key pair being replaced; and

removing all authorized keys being replaced.

5. The system of claim 1 , wherein the system is configured to generate reports with respect to at least one of the following from the centrally stored information:

a major and minor version of SSH implementation of discovered SSH servers;

SSH protocol versions supported by the discovered SSH servers;

a key length and format of SSH server public keys;

a cryptographic algorithm used with an SSH server public key;

whether password-based SSH authentication is enabled on the SSH servers;

whether public key-based SSH authentication is enabled on the SSH servers; and

whether interactive keyboard authentication is enabled on the SSH servers.

6. A method for determining in a network environment which SSH devices acting as SSH clients and associated accounts have a server trust relationship with SSH devices acting as SSH servers comprising:

obtaining known host keys and SSH server key pairs from the SSH devices connected to the network;

storing the known host keys and SSH server key pairs in a repository; and

correlating known host keys to public keys in SSH server key pairs.

7. The method of claim 6 in which the SSH devices connected to the network are identified by:

collecting SSH-related information including SSH Known Host Keys, Authorized Keys, Client Key Pairs, Server Key Pairs, and connection logs; and

analyzing the collected SSH-related information by:

identifying additional SSH servers at network addresses associated with collected SSH Known Host Keys for which no corresponding SSH Server Key Pair was found in the collected SSH-related information;

identifying additional SSH clients by detecting collected SSH Authorized Keys for which no corresponding SSH Client Key Pair exists in the collected SSH-related information and determining a location of those SSH clients from collected connection logs; and

evaluating any collected connection logs to identify SSH clients or SSH servers from which SSH-related information has not yet been collected.

8. The method of claim 6 in which the collected SSH-related information from the identified SSH devices further includes at least one of:

authorized keys and any user accounts associated with each authorized key found;

SSH server configuration data, including at least one of:

configuration file location;

whether ignore RHosts is enabled;

whether ignore user known hosts is enabled;

whether empty passwords are allowed;

whether public key login is allowed;

whether password login is allowed;

whether root login is allowed;

whether the SSH server is active; and

any commands, programs, scripts, restrictions or other optional configuration items associated with authentication;

SSH client key pairs and associated user accounts and known host keys associated with those user accounts; and

access logs documenting SSH connections.

9. The method of claim 6 further comprising:

replacing specific SSH server key pairs and matching known host keys by generating a new SSH server key pair;

placing a public key from the new SSH server key pair at a same location of the known host keys being replaced;

placing the new SSH server key pair at a same location as the SSH server key pair being replaced;

removing the SSH server key pair being replaced; and

removing the known host keys being replaced.

10. The method of claim 6 further comprising the steps of installing discovery agents on SSH devices in the network environment known or suspected to have SSH capabilities and using those discovery agents to collect SSH-related information.

11. The method of claim 6 in which reports are generated with respect to at least one of the following:

a major and minor version of SSH implementation of discovered SSH servers;

SSH protocol versions supported by the discovered SSH servers;

a key length and format of SSH server public keys;

a cryptographic algorithm used with a SSH server public key;

whether password-based SSH authentication is enabled on the SSH servers;

whether public key-based SSH authentication is enabled on the SSH servers; and

whether interactive keyboard authentication is enabled on the SSH servers.

12. A method for determining in a network environment which SSH devices acting as SSH clients and associated accounts have a client trust relationship with SSH devices acting as SSH servers and associated accounts comprising:

obtaining authorized keys and SSH client key pairs from the SSH devices connected to the network;

storing the authorized keys and SSH client key pairs in a repository; and

correlating authorized keys to public keys in SSH client key pairs.

13. The method of claim 12 in which the SSH devices connected to the network are identified by:

collecting SSH-related information including SSH Known Host Keys, Authorized Keys, Client Key Pairs, Server Key Pairs, and connection logs; and

analyzing the collected SSH-related information by:

identifying additional SSH servers at network addresses associated with collected SSH Known Host Keys for which no corresponding SSH Server Key Pair was found in the collected SSH-related information;

identifying additional SSH clients by detecting collected SSH Authorized Keys for which no corresponding SSH Client Key Pair exists in the collected SSH-related information and determining a location of those SSH clients from collected connection logs; and

evaluating any collected connection logs to identify SSH clients or SSH servers from which SSH-related information has not yet been collected.

14. The method of claim 12 in which the collected SSH-related information from the identified SSH devices further includes at least one of:

SSH server key pairs;

any user accounts associated with each authorized key found;

SSH server configuration data, including at least one of:

configuration file location;

whether ignore RHosts is enabled;

whether ignore user known hosts is enabled;

whether empty passwords are allowed;

whether public key login is allowed;

whether password login is allowed;

whether root login is allowed;

whether the SSH server is active; and

any commands, programs, scripts, restrictions or other optional configuration items associated with authentication;

SSH client key pairs and associated user accounts and known host keys associated with those user accounts; and

access logs documenting SSH connections.

15. The method of claim 12 further comprising:

replacing specific SSH client key pairs and matching authorized keys by:

generating a new SSH client key pair;

placing a public key from the new SSH client key pair at a same location of the authorized keys being replaced;

placing the new SSH client key pair at a same location as the SSH client key pair being replaced;

removing the SSH client key pair being replaced; and

removing the authorized keys being replaced.

16. The method of claim 12 further comprising the steps of installing discovery agents on SSH devices in the network environment known or suspected to have SSH capabilities and using those discovery agents to identify additional SSH devices in the network environment.

17. The method of claim 12 in which reports are generated with respect to at least one of the following:

a major and minor version of SSH implementation of discovered SSH servers;

SSH protocol versions supported by the discovered SSH servers;

a key length and format of SSH server public keys;

a cryptographic algorithm used with a SSH server public key;

whether password-based SSH authentication is enabled on the SSH servers;

whether public key-based SSH authentication is enabled on the SSH servers; and

whether interactive keyboard authentication is enabled on the SSH servers.

18. A system for central management of SSH credential information comprising:

a central data store comprising a plurality of records adapted to store SSH server key pairs, SSH client key pairs, known host keys, authorized keys from a plurality of systems to be brought under management;

a network connection connecting the system to a first set of the plurality of systems to be brought under management; and

a processor having access to executable instructions that, when executed by the processor, cause the system to perform operations comprising:

perform a scan of the first set of the plurality of managed systems, the scan collecting SSH server key pairs, SSH client key pairs, known host keys, authorized keys logs that exist on each of the first set of the plurality of systems to be brought under management;

compare each collected authorized key to collected SSH client key pairs to identify client trust relationships between SSH clients and SSH servers;

based on finding an authorized key for which there is no corresponding SSH client key pair, marking that authorized key as an orphan authorized key;

compare each collected known host key to collect SSH server key pairs to identify server trust relationships between SSH servers and SSH clients; and

based on finding a known host key for which there is no corresponding SSH server key pair, marking that known host key as an orphan known host key.

19. The system of claim 18 wherein:

the central data store further comprises a plurality of records adapted to store connection logs; and

the executable instructions further cause the system to perform operations comprising:

collect, during the scan, connection logs from each of the first set of the plurality of systems to be brought under management;

analyze the connection logs to identify any SSH clients that authenticate to an SSH server using user name/password authentication; and

marking as unaccounted for SSH clients those SSH clients that authenticate to an SSH server using user name/password authentication and that are not represented in a list of SSH clients identified through the scan.

20. The system of claim 18 where the executable instructions further cause the system to create a discrepancy report listing information associated with orphan authorized keys and orphan known host keys.

Assignments (8)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jan 8, 2026
From: VENAFI, INC.; VENAFI BUYER, LLC; VENAFI INTERMEDIATE, LLC; VENAFI HOLDINGS, INC.
To: CYBERARK SOFTWARE, INC.
Reel/Frame 073400/0651 →
TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS RECORDED AT REEL 054892, FRAME 0430 Recorded Oct 1, 2024
From: TRUIST BANK, AS ADMINISTRATIVE AGENT
To: VENAFI, INC.
Reel/Frame 069065/0950 →
PATENT SECURITY AGREEMENT Recorded Jan 4, 2021
From: VENAFI, INC.
To: TRUIST BANK
Reel/Frame 054892/0430 →
RELEASE OF SECURITY INTEREST Recorded Dec 10, 2018
From: ORIX GROWTH CAPITAL, LLC
To: VENAFI, INC.
Reel/Frame 047722/0100 →
SECURITY INTEREST Recorded Jul 21, 2017
From: VENAFI, INC.
To: ORIX GROWTH CAPITAL, LLC
Reel/Frame 043069/0191 →
RELEASE OF SECURITY INTEREST Recorded Jun 29, 2017
From: VENTURE LENDING & LEASING VI, INC.; VENTURE LENDING & LEASING VII, INC.
To: VENAFI, INC.
Reel/Frame 043038/0218 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 7, 2014
From: BARTOK, PETER D; TURNER, PAUL A; SKEHAN, JOSEPH D.; BROTHERS, JASON W.K.
To: VENAFI, INC
Reel/Frame 033252/0084 →
SECURITY INTEREST Recorded May 8, 2014
From: VENAFI, INC.
To: VENTURE LENDING & LEASING VI, INC.; VENTURE LENDING & LEASING VII, INC.
Reel/Frame 032848/0048 →