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.
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
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.
No comments:
Post a comment