IP Library Granted Patent US 10,567,360
Granted Patent B2
US 10,567,360 · App. 15/687,561 · Granted Feb 18, 2020

SSH key validation in a hyper-converged computing environment

Inventors: Vishesh Kumar Nirwal (Bangalore, IN); Suket Gakhar (Bangalore, IN)
Assignee: VMware, Inc.
H04L63/061G06F9/45558G06F9/54H04L63/0281H04L63/0435H04L63/0442H04L63/08H04L63/0884G06F2009/45595H04L9/3247H04L63/166
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 10,567,360
App. No.
15/687,561
Granted
Feb 18, 2020
Kind
B2
Abstract

Disclosed are various examples for validating a public SSH host key. The examples can be implemented in a hyper-converged computing environment to detect potential man-in-the-middle attacks in which an attacker intercepts or spoofs an internet protocol (IP) address of a target virtual machine (VM) that is being addressed by a management service and with which a secure shell (SSH) session is being established.

Claims (37)

1. A computer-implemented method, comprising:

initiating a secure shell (SSH) connection to a target virtual machine running on a host computing device, the host computing device being one of a plurality of hyper-converged computing devices in a hyper-converged virtual computing environment;

obtaining a public SSH host key from the target virtual machine, wherein the public SSH host key corresponds to a private SSH host key associated with the target virtual machine;

sending an artifact of the public SSH host key to a trusted service running on the same host computing device as the target virtual machine, wherein the trusted service is configured to validate the public SSH host key associated with the target virtual machine by obtaining the public SSH host key directly from the target virtual machine in a request without using the same internet protocol address associated with the SSH connection to the target virtual machine;

obtaining a validity indication from the trusted service in response to a determination that the public SSH host key is valid or invalid; and

saving the public SSH host key as a trusted key in response to the validity indication indicating that the public SSH host key is valid.

2. The computer-implemented method of claim 1 , further comprising establishing a transport layer between the at least one computing device and the target virtual machine in response to the validity indication indicating that the public SSH host key is valid.

3. The computer-implemented method of claim 2 , further comprising supplying at least one credential to the target virtual machine over the SSH connection subsequent to the transport layer being established.

4. The computer-implemented method of claim 1 , wherein the artifact of the public SSH host key comprises a key signature or a copy of the public SSH host key.

5. The computer-implemented method of claim 1 , wherein the trusted service validates the public SSH host key by communicating with the target virtual machine using an application programming interface (API) provided by a hypervisor running on the host computing device executing the target virtual machine.

6. The computer-implemented method of claim 5 , wherein the API provided by the hypervisor validates the public SSH host key of the target virtual machine without communicating with the trusted service over a network connection.

7. A system, comprising:

at least one computing device comprising memory; and

program instructions stored in the memory and executable in the at least one computing device that, when executed, cause the at least one computing device to:

initiate a secure shell (SSH) connection to a target virtual machine running on a host computing device, the host computing device being one of a plurality of hyper-converged computing devices in a hyper-converged virtual computing environment;

obtain a public SSH host key from the target virtual machine, wherein the public SSH host key corresponds to a private SSH host key associated with the target virtual machine;

send an artifact of the public SSH host key to a trusted service running on the same host computing device as the target virtual machine, wherein the trusted service is configured to validate the public SSH host key associated with the target virtual machine by obtaining the public SSH host key directly from the target virtual machine in a request without using the same internet protocol address associated with the SSH connection to the target virtual machine;

obtain a validity indication from the trusted service in response to a determination that the public SSH host key is valid or invalid; and

save the public SSH host key as a trusted key in response to the validity indication indicating that the public SSH host key is valid.

8. The system of claim 7 , wherein the program instructions further cause the at least one computing device to establish a transport layer between the at least one computing device and the target virtual machine in response to the validity indication indicating that the public SSH host key is valid.

9. The system of claim 8 , wherein the program instructions further cause the at least one computing device supply at least one credential to the target virtual machine over the SSH connection subsequent to the transport layer being established.

10. The system of claim 7 , wherein the artifact of the public SSH host key comprises a key signature or a copy of the public SSH host key.

11. The system of claim 7 , wherein the trusted service validates the public SSH host key by communicating with the target virtual machine using an application programming interface (API) provided by a hypervisor running on the host computing device executing the target virtual machine.

12. The system of claim 11 , wherein the API provided by the hypervisor validates the public SSH host key of the target virtual machine without communicating with the trusted service over a network connection.

13. The system of claim 7 , wherein the program instructions further cause the at least one computing device to terminate the SSH connection prior to establishing a transport layer in response to the validity indication indicating that the public SSH host key is invalid.

14. A non-transitory computer-readable medium embodying program code executable in at least one computing device that, when executed by the at least one computing device, causes the at least one computing device to:

initiate a secure shell (SSH) connection to a target virtual machine running on a host computing device, the host computing device being one of a plurality of hyper-converged computing devices in a hyper-converged virtual computing environment;

obtain a public SSH host key from the target virtual machine, wherein the public SSH host key corresponds to a private SSH host key associated with the target virtual machine;

send an artifact of the public SSH host key to a trusted service running on the same host computing device as the target virtual machine, wherein the trusted service is configured to validate the public SSH host key associated with the target virtual machine by obtaining the public SSH host key directly from the target virtual machine in a request without using the same internet protocol address associated with the SSH connection to the target virtual machine;

obtain a validity indication from the trusted service in response to a determination that the public SSH host key is valid or invalid; and

save the public SSH host key as a trusted key in response to the validity indication indicating that the public SSH host key is valid.

15. The non-transitory computer-readable medium of claim 14 , wherein the program code causes the at least one computing device to at least establish a transport layer between the at least one computing device and the target virtual machine in response to the validity indication indicating that the public SSH host key is valid.

16. The non-transitory computer-readable medium of claim 15 , wherein the program code further causes the at least one computing device supply at least one credential to the target virtual machine over the SSH connection subsequent to the transport layer being established.

17. The non-transitory computer-readable medium of claim 14 , wherein the artifact of the public SSH host key comprises a key signature or a copy of the public SSH host key.

18. The non-transitory computer-readable medium of claim 14 , wherein the trusted service validates the public SSH host key by communicating with the target virtual machine using an application programming interface (API) provided by a hypervisor running on the host computing device executing the target virtual machine.

19. The non-transitory computer-readable medium of claim 18 , wherein the API provided by the hypervisor validates the public SSH host key of the target virtual machine without communicating with the trusted service over a network connection.

20. The non-transitory computer-readable medium of claim 14 , wherein the program code further causes the at least one computing device to terminate the SSH connection prior to establishing a transport layer in response to the validity indication indicating that the public SSH host key is invalid.

Assignments (2)
CHANGE OF NAME Recorded Apr 15, 2024
From: VMWARE, INC.
To: VMWARE LLC
Reel/Frame 067102/0395 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Aug 28, 2017
From: NIRWAL, VISHESH KUMAR; GAKHAR, SUKET
To: VMWARE, INC.
Reel/Frame 043686/0953 →
Priority Claims (1)
IN 201741022857 · Jun 29, 2017 · national
Continuity (1)
Related Publication 20190007382A1 · Jan 3, 2019
Cited By (4)
US 12,634,213 US 12,634,350 US 12,699,639 US 12,712,727