Secure Shell (SSH) – Application, Standards and Usage Guidelines

What is Secure Shell (SSH)?

SSH Secure Shell is a popular, powerful, software-based command interface and a cryptographic network protocol used to protect data in transmission between devices providing strong authentication and establishes a secure channel over an insecure network in a client-server architecture. Whenever data is sent by a computer to the network, SSH automatically encrypts (scrambles) it. Then, when the data reaches its intended recipient, SSH automatically decrypts (unscrambles) it. The result is transparent encryption: users can work normally, unaware that their communications are safely encrypted on the network.

Why Secure Shell?

With the evolution of the internet, the number of threats is also increasing where some of the threats are network monitoring, connection hijacking, routing spoofing, DNS spoofing, denial of service attacks, etc. File transfers, remote logins, and remote command executions became possible with the help of existing protocols like FTP, Telnet and TCP but the problem with these protocols is they lacked security and hence it is possible for an intruder to intercept and read the data. Telnet especially was very risky as the username and password were interpreted as plain text over the network.

Secure Shell (SSH) Protocol  Features

SSH protocol is a specification of how to conduct secure communication over a network. The SSH protocol covers Authentication (user, password, public and host key authentication), Data Encryption, and the Integrity of data transmitted over a network.

  

Figure 1.4  Authentication, Encryption, and Integrity

The Secure Shell (SSH) Protocols

Secure Shell Protocol  is divided into four major components:

SSH-TRANS - is the fundamental building block, providing the initial connection, server authentication, and basic encryption and integrity services.

SSH-AUTH – The user authentication layer authenticates the client-side to the server. It uses the established connection and runs on top of the transport layer. It provides several mechanisms for user authentication. These include password authentication, public-key or host-based authentication mechanisms.

SSH-CONN - The connection layer runs over the user authentication protocol. It multiplexes many different concurrent encrypted channels into logical channels over the authenticated connection.

SSH-SFTP- is a  protocol to provide secure file transfer, access and management.

Figure 1.5 outlines the division of labor between these protocols, and how they relate to each other, application programs, and the network.

Applications Of Secure Shell (SSH)

Secure Shell provides various applications:

•  Secure command-shell- Allows you to edit files, view the contents of directories and access custom database applications.
•  Secure file transfer- SFTP is a subsystem of the Secure Shell protocol. In essence, it is a separate protocol layered over the Secure Shell protocol to handle file transfers.
• Port forwarding- Port forwarding or tunneling reroutes a TCP/IP connection to pass through an SSH connection, transparently encrypting it end to end. Port forwarding can also pass such applications through network firewalls that otherwise prevent their use.
• Access Control- Permits another person to use your computer account, but only for certain purposes granted.

Threats Addressed by Secure Shell

• Eavesdropping or Password Sniffing
• Man-in-the-Middle Attack (MITM)
• Insertion and Replay Attacks
•  Connection Hijacking

Secure Shell (SSH) Standards

A Request for Comments (RFC) is a type of publication from the Internet Engineering Task Force (IETF) and the Internet Society (ISOC), the principal technical development and standards-setting bodies for the Internet. SSH is documented as a proposed standard in RFCs 4250 through 4256.

• RFC 4250 - The Secure Shell Protocol Assigned Numbers - This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol.
• RFC 4251 - The Secure Shell  Protocol Architecture - This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents.
• RFC 4252 - The Secure Shell Authentication Protocol-  This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods
• RFC 4253 - The Secure Shell Transport Layer Protocol - This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP.
• RFC 4254 - The Secure Shell Connection Protocol - This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections etc.
• RFC 4255 - Using DNS to Securely Publish Secure Shell Key Fingerprints - This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security
• RFC 4256 - Generic Message Exchange Authentication for the (SSH) - This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device).

Secure Shell (SSH) –Usage Guidelines

While the SSH protocol itself provides a secure communications channel, the effective management of SSH-based access requires proper provisioning, termination and monitoring processes. Some of the specific guidelines and security controls for SSH-based access management include :

Account management

To prevent unauthorized users from accessing sensitive or regulated information, it is recommended that organizations proactively secure, manage and monitor the use of SSH keys that provide access to privileged accounts. Proposed guidelines related to account management include:

• Ensure that users only have access to the SSH keys needed for their role.
•  Track the usage of keys to gain an audit trail of who accessed what and when.
•  Rotate shared SSH keys as soon as a user leaves the authorized group.
•  Continuously ensure that SSH keys are compliant with organizational policy.

Access enforcement

A critical security measure is the control of access to enterprise systems, whether they are servers, virtual machines, operating systems, databases or applications. Any compromise at any level could result in serious consequences. As a result, recommended best practices in this area include:

• Create and enforce approval policies for SSH key-based access.
• Prevent users from propagating access rights by installing new private keys.
• Lock down ‘authorized keys’ files so that users are unable to install their public keys on unauthorized target systems.

Least privilege

Privileged accounts are at the heart of most data breaches, so it’s important to control SSH keys based on what type of access each user is granted. Privileges and access rights should be limited to only those required for a user’s role or function to provide the highest degree of security. Recommendations include:

• Continuously monitor the SSH key inventory and trust relationships between keys.
• Restrict what commands may be run with each SSH key.
• Only grant privileged SSH access if a task cannot be done using a non-privileged account.

Auditing and monitoring

Continuous auditing of privileged account access helps organizations ensure that the processes for provisioning, lifecycle management and key termination are being followed and enforced. Similarly, ongoing monitoring of privileged user activity helps organizations detect unauthorized activities, commands or changes to critical systems. Recommendations include:

• Track the use of SSH keys, including who used the private key and what target system was accessed with that key.
• Proactively prevent systems administrators from modifying SSH keys and files.
• Monitor for changes to ‘authorized keys’ files and configuration files.

Risk assessment

Security and risk assessments help organizations identify vulnerabilities and weaknesses that employees or attackers could exploit. Environments that use SSH keys for authentication often have several linked systems that can all subsequently be compromised if an attacker were to compromise a single private key. To effectively understand an SSH environment and make a plan to mitigate risks, some recommendations are:

•  Assess the entire IT environment to locate all SSH keys.
• Determine which users, systems or applications have access to which keys.
• Make an actionable plan to remove unnecessary keys from users and systems.

Identification and authentication

To easily identify who is doing what, it’s important to ensure that each user has a unique SSH key and that the SSH key cannot be shared with other users. In situations when it is not possible to distribute individual keys, organizations must limit which users have access to shared keys, control access to those keys, and monitor who is accessing the keys.  Recommendations include:

• Assign SSH keys on an individual user or system basis, and enforce policies that prohibit the sharing, copying, or moving of private keys.
• Ensure that shared SSH key pairs are rotated as soon as a user leaves the group.
• Proactively rotate all key pairs on a regular basis to eliminate static keys.
• Prohibit automated access that relies on hard-coded passwords.

In Conclusion

Secure Shell (SSH) ability to provide strong authentication and secure encrypted data communications between two computers connecting over an insecure network such as the Internet, makes it the preferred choice by network administrators.

SSH’s ability to guarantee the confidentiality, authenticity and integrity of information gives users a level of comfort that other protocols such as FTP, Telnet and TCP which provides file transfers, remote logins, and remote command executions doesn’t provide. Due to a lack of information assurance in the FTP, Telnet and TCP protocols, it became possible for an intruder to intercept data being communicated over a network. This problem was solved by SSH encryption and decryption standards. Finally, no single piece of software can provide a complete security solution. Therefore, the need for a complete security policy that governs the use of SSH is advised.