Secure shell (SSH) is a cryptographic protocol that protects data exchange by using public key cryptography for authentication and data encryption. This means that all session data, including commands and file contents, travel inside the encrypted tunnel to block eavesdropping and spoofing.
SFTP and SCP both run on SSH, most commonly connecting on port 22. SSH also allows administrators to specify encryption and key generation ciphers, along with file compression, which can help offset SFTP’s heavier packet sizes.
SSH-2 is the current version of the protocol and is in widespread use across the internet for securing client-server connections.
Core SSH capabilities
Beyond basic encryption, SSH provides operational tools that enable and simplify secure file workflows. These functions include:
- Built‑in port forwarding that secures auxiliary services, such as database or API calls, over the same channel
- Host fingerprint validation that stops rogue servers by comparing stored keys at connection start
- Single-port connections to streamline network configuration
- Standardized logging that captures session start, end and command activity for compliance audits
- Subsystem delegation that isolates SFTP or SCP, so shell access is withheld from file transfer accounts
- The ability to sync access keys to role‑based permission sets to grant read, write or command rights per user or group
How does SSH encryption and security work?
SSH establishes a secure session through a two‑step exchange. First, a key‑exchange algorithm, such as ECDH or Curve25519, creates a shared secret that the parties use to verify each other. Next, the peers agree on symmetric ciphers and message authentication codes that shield each packet. Once this encryption is established, other credentials, file contents and commands then travel inside the encrypted wrapper to defeat eavesdropping and tampering attempts as the information passes over untrusted networks.
SSH security can be enhanced in the following ways:
- Defined key management policies that specify generation algorithms and expiration periods
- FIPS-validated cryptography modules to demonstrate compliance with federal mandates
- Strict banner and version checks that block downgrade attempts
- The ability to separate SFTP keys from SSH keys to add an additional level of authentication security
- The ability to upgrade to specified encryption ciphers that meet specific security requirements, such as HIPAA compliance
SSH vs. legacy remote access protocols
Before SSH, organizations relied on open or less secure methods of data transfer, such as Telnet, rlogin or plain FTP, for remote management and file exchange. These protocols send credentials and data in clear text, which leaves them open to interception and tampering. SSH replaces legacy connection methods with an encrypted channel that combines authentication, integrity and confidentiality while preserving command versatility.
Key differences between SSH and prior protocols include:
- Audit trail: Standardized logs capture commands, transfers and login events that older tools miss.
- Authentication: Public key or MFA options replace password-only logins.
- Encryption: 256-bit symmetric ciphers secure every packet, while Telnet and RSH don’t use any.
- Integrity: MAC values detect alteration, whereas legacy flows lack checks.
- Port use: SSH uses a single port 22 session, as opposed to the multiple sockets FTP requires for data and control.
SSH tools and protocols built on SSH
SSH’s encrypted tunnel can protect any utility or application that moves files, automates jobs and sends or receives remote commands. Because of its flexibility, a number of tools and protocols commonly use SSH. These include:
- Git over SSH: Version control operations that keep commits private across public networks
- MFT: Most MFT systems will include SSH support.
- rsync over SSH: Sync tool that copies only changed blocks to shrink transfer windows
- SCP: Secure copy uses SSH authentication and encryption to secure basic file transfers.
- SFTP: Single‑channel file transfer that supports resumable uploads and directory listings without exposing data
- SSHFS: A remote file system client that mounts remote directories as if they’re local for ad‑hoc access
Secure shell (SSH) FAQs
SSH is used for encrypting connections between a client and server that travel over untrusted networks, such as remote system administration, file transfer and command execution. File transfer protocols such as SFTP and SCP use the encrypted SSH tunnel to perform their operations.
SSH is an ideal protocol for file transfer automation, due to its key‑based authentication, which lets orchestration tools push updates or collect metrics at scale without interactive logins. Port forwarding can wrap services like databases or APIs inside the encrypted session to avoid separate VPN paths. Its versatility and straightforward key management have made SSH a default choice for connecting to cloud instances, containers and network appliances.
Yes. SSH is the primary remote‑access protocol for Unix, Linux and macOS hosts. Microsoft added native support to Windows releases in 2018, and the protocol is broadly deployed across cloud environments and on‑premises servers.
The SSH authentication method confirms both server and user identities after the encrypted transport channel is established. The client first verifies the server’s host key to detect spoofing, then submits credentials over the protected link so no sensitive data travels in clear text.
Supported methods include password, public key, keyboard‑interactive, Kerberos or FIDO2 tokens, with public key login favored for automated file transfers because keys can be scoped and rotated without downtime. Successful authentication unlocks subsystems such as SFTP, which means this step is the gatekeeper for remote administration and MFT workflows.
SSH and SSL/TLS are encryption protocols that protect data in transit, but they transmit data and provide encryption in different ways.
SSH creates an authenticated tunnel for remote administration and file exchange, most often over port 22. SSL, now standardized as TLS, wraps application protocols such as HTTP, SMTP and IMAP with certificate‑based encryption. The best‑known example is HTTPS on port 443. While both provide confidentiality and integrity, SSH is session-oriented and grants shell or subsystem access, whereas TLS is designed to secure arbitrary application traffic without direct command execution.
The trust model also differs. SSH relies on key pairs distributed between the client and the server, which allows rapid deployment without a certificate authority (CA). TLS depends on X.509 certificates signed by public or private CAs, so browsers and other clients can validate server identity.
In MFT workflows, different file transfer protocols use different security layers. SFTP operates over SSH, while FTPS and HTTPS rely on TLS.
