Glossary term

SSH

Secure Shell provides secure administration of a remote server, execution of a specific remote command, and tunnelling of other network traffic through an encrypted connection. Its security also depends on host-key verification, sound user-key management, and restricted privileges.

In brief

A secure protocol for remote services—not just a remote terminal

SSH connects a client and server through an encrypted, integrity-protected transport. A typical target is a Linux server where the client opens an interactive shell, runs one command, or uses forwarding. The command line, shell, and terminal are separate concepts: SSH can expose them remotely, but is itself neither a shell nor a terminal application.

The client and server first negotiate cryptographic parameters and derive session keys while establishing the connection. The server authenticates itself with a host key, then the user authenticates through a separate mechanism. This distinction matters: the user public key does not encrypt the entire session, and the host key does not determine which user account may access the server.

What problem it solves

Managing a remote system across an untrusted network

SSH replaces insecure remote login with a protocol that protects the confidentiality and integrity of communication and authenticates the parties. One connection can carry multiple logical channels, so it is not limited to one interactive shell or a single network port.

administrator or developer access for diagnosing applications and system services
running a single remote command from a script or managed deployment
transferring files with SFTP or scp without a separate insecure protocol
local, remote, or dynamic forwarding of selected TCP traffic
reaching a network through a jump host when it is not directly accessible from a developer machine

Practical example

Checking a PHP service and opening a local database tunnel

The developer first logs in with a restricted account. The second command runs without an interactive shell, prints the PHP-FPM status, and returns its exit code. The exact service name depends on the distribution and installed PHP version.

The third command opens port 15432 on the client loopback address and carries its traffic through SSH to port 5432 as seen from the server. The database does not need to be exposed to the internet. For a longer interactive investigation, the developer can start tmux after logging in so that a brief client outage does not destroy the working terminal session.

Shell

ssh deploy@app.example.cz
ssh deploy@app.example.cz 'systemctl --no-pager status php8.4-fpm'
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15432:127.0.0.1:5432 deploy@app.example.cz

How it works

From a target server to a secure channel

Text diagram: SSH client → key exchange and host-key verification → encrypted transport → user authentication → shell, command, or forwarding. The layers work together, but each verifies a different part of the connection.

Target and transport The client connects to the hostname or IP address and TCP port of the SSH server. Port 22 is the common default, not a security guarantee.
Key exchange The client and server negotiate algorithms and derive temporary session keys that protect the confidentiality and integrity of subsequent communication.
Server authentication The server presents the public part of its host key. The client verifies its fingerprint or association with the host and usually records an accepted key in known_hosts for later connections.
User authentication Depending on server policy, accepted methods may include a public key, a password, a keyboard-interactive challenge, or a combination of methods.
Connection channels After login, the connection can open an interactive shell, a remote command, the SFTP subsystem, or an allowed forwarding channel. The server can restrict these capabilities for both an account and a particular key.

Core concepts

Host keys, user keys, and session keys have different roles

Distinguishing these keys precisely prevents the dangerous assumption that merely having a private-key file solves the entire security problem.

SSH client and server

The ssh program initiates a connection, while the sshd daemon on the target host accepts it and enforces server policy. OpenSSH is a widely used implementation; SSH primarily names the protocol.

Host key and known_hosts

A host key identifies the server. The client stores accepted public host keys in known_hosts and warns when one changes, because the cause may be either a legitimate reinstallation or a man-in-the-middle attack. The fingerprint of a first-seen key should be verified through another trusted channel.

User public and private keys

With public-key authentication, the server knows the authorised public key and the client proves possession of the private key with a cryptographic signature. The private key stays with the user and should not be copied to managed servers.

Passwords and multiple methods

A password is checked inside the encrypted transport that has already been established, so it is not sent as plaintext. Public-key authentication is usually more practical for resisting password guessing and for automation, but only with proper protection, rotation, and, where appropriate, an additional factor.

SSH agent

An agent makes loaded identities available and performs signing operations without repeatedly reading a private key from disk. Agent forwarding should be enabled deliberately: a compromised remote host with access to the socket may not be able to steal the key, but it can abuse the available signing operations.

Forwarding

Local forwarding exposes a target reachable from the server to the client; remote forwarding works in the opposite direction; dynamic forwarding creates a SOCKS proxy. Every forwarding rule extends the network path and should be restricted by address, port, and server policy.

SSH and TLS

SSH and TLS both protect network communication, but they are not interchangeable. TLS commonly secures application protocols such as HTTPS and often authenticates servers through certificate chains. SSH creates channels for remote services and commonly relies on host keys or its own SSH certificate authority.

Benefits and limitations

A strong protocol still needs careful identity and access management

Benefits

protects commands, output, and tunnelled channels from passive eavesdropping and modification in transit
supports interactive and non-interactive administration through one protocol
public-key authentication can be automated more safely and restricted to a specific purpose
forwarding exposes an internal service without publishing it directly
client configuration can name hosts, users, identities, and jump hosts

Limitations and common mistakes

blindly accepting a host key or disabling its verification removes an important defence against an impersonated server
a leaked, unprotected private key may unlock every account where its public counterpart is authorised
overly broad forwarding or agent forwarding increases the impact of a compromised server
direct root login and shared administrator accounts make containment and auditing more difficult
changing the default port alone does not address authentication, updates, or access restrictions

Practical use

Remote administration, automation, and tightly scoped tunnels

SSH is a good fit for server diagnostics, controlled deployments, repository access, or temporary access to an internal service. An automation account should have its own identity and only the permissions it needs; an authorized_keys entry can further restrict the command, forwarding, source address, or terminal allocation.

SSH does not replace a VPN, secrets management, an audit system, or a standard application interface. When many people make routine production changes by hand, some of that work should move into versioned automation and CI/CD. Emergency access remains valuable when it is individual, recorded, and reviewed regularly.

Security and operations

Server and user credentials must be replaceable, and access must be revocable

A key is not a permanent pass. Without an inventory of authorisations and a rotation process, it is difficult to know where someone still has access after they leave or an identity is compromised.

never share a private key; protect it with file permissions, a suitable passphrase, or a hardware authenticator according to the risk
verify the fingerprint of a new or changed host key through a trusted channel instead of merely deleting the known_hosts warning
choose the preferred combination of authentication methods for the environment and limit accounts with administrative privileges
allow root access only when—and in the form—the specific operating environment genuinely requires
after a compromise, remove the public key or certificate authorisation from every server, issue a new identity, and review access logs
keep clients and servers updated, and do not enable obsolete algorithms merely to support an undocumented legacy system

Frequently asked questions

SSH keys, host keys, and secure access

Is SSH just a remote terminal?

No. SSH is a protocol and a suite of tools. An interactive remote shell is one use case alongside running a single command, transferring files, and forwarding network traffic.

Does my user public key encrypt the connection?

Not directly. The key exchange establishes the encrypted transport. The user key pair then proves the user identity inside that protected connection.

What should I do when SSH reports a changed host key?

Do not overwrite the record blindly. A legitimate reinstallation can change the key, but so can an impersonated server. First confirm the reason and the new fingerprint with the administrator or through another trusted channel.

Is key-based authentication always safer than a password?

A well-managed key is generally more resistant to password guessing and easier to automate for administration. It is not automatically secure without private-key protection, restricted privileges, an inventory, and rotation.

What should I do if a private key is compromised?

Remove its public counterpart or the relevant certificate authorisation from every target system, create a new identity, and review access logs. A passphrase may delay abuse, but it does not replace rotation.

How I work with servers

I keep remote access separate from application permissions and routine deployment.

When operating applications, I use individual access, restricted accounts, and traceable procedures so that manual diagnostics do not bypass the operational rules of a project.

Explore my technical expertise Discuss your project

OpenSSH ssh(1) manual