SSH Remote Login

SSH (Secure Shell) is the core protocol for implementing secure remote management in Linux systems. It establishes encrypted channels between local and remote hosts, effectively preventing data from being intercepted or tampered with during transmission. For system administrators, mastering SSH operations is not only a fundamental skill for daily operations but also the first line of defense for server security. This article delves into the working principles of SSH, configuration methods, key management, and best practices to help readers build a robust remote access capability.
The SSH protocol operates over TCP port 22. Its workflow consists of three main steps: authentication, encryption negotiation, and session establishment. When a user inputs the ssh command in their local terminal, the client initiates a connection request to port 22 on the target server. Upon receiving the request, the server performs public key verification or password verification. Once authentication succeeds, both parties negotiate a temporary symmetric key for subsequent encrypted communication.

Common SSH command-line tools include:

  • Basic Connection: ssh user@host, where user is the remote username and host is the target IP address or domain name.
  • Specify Port: ssh -p 2222 user@host, suitable for non-standard port configurations.
  • Specify Key File: ssh -i /path/to/key user@host, used for automation scripts or passwordless login scenarios.

Example: Assuming we need to connect to a Linux server named server.example.com with the username admin, execute the following command to establish the connection:

ssh admin@server.example.com

Upon successful connection, the terminal will prompt for the remote server's password (if no key is configured).

SSH Key Authentication Mechanism

Compared to traditional password login, SSH key-based authentication offers higher security. It relies on asymmetric encryption technology, consisting of a pair of public and private keys: the public key can be distributed openly for identity verification, while the private key must be strictly kept by the user to complete the login operation. This method avoids the risk of passwords being intercepted during transmission and supports batch automated deployment.

Configuring key-based authentication typically involves the following steps:

  1. Generate Key Pair: Use the ssh-keygen tool to generate RSA or Ed25519 type keys.

    ssh-keygen -t ed25519 -C "your_email@example.com"

    The system will create id_ed25519 (private key) and pub_ed25519 (public key) in the ~/.ssh/ directory.

  2. Copy Public Key to Remote Server: Paste the public key content into the ~/.ssh/authorized_keys file on the remote server.

    ssh-copy-id user@server.example.com

    This command automatically completes the public key upload and sets correct permissions, avoiding errors from manual operations.

  3. Test Connection: Delete old password files (such as id_rsa) in the .ssh directory, then attempt a passwordless login to verify if the key is working.

SSH Server Configuration and Security Hardening

While client configuration is relatively simple, server security policies are equally crucial. By modifying the /etc/ssh/sshd_config file, you can control access permissions, disable dangerous features, and optimize performance. Here are several key configuration items:

  • Disable Password Login: Set PasswordAuthentication no to force key-based authentication.
  • Limit Login Users: Use the AllowUsers directive to allow only specific users to connect.
  • Disable Empty Passwords: Ensure PermitEmptyPasswords no is active to prevent brute-force attacks.
  • Enable Logging: Configure LogLevel VERBOSE to track abnormal access behavior.

After applying new configurations, restart the SSH service:

sudo systemctl restart sshd

Additionally, it is recommended to regularly update the OpenSSH version to fix known vulnerabilities and pair this with firewall rules restricting access to port 22 only from trusted IP ranges.

Common Issues and Troubleshooting

In practical usage, users often encounter issues such as connection timeouts, permission denied errors, or invalid keys. Below are diagnostic approaches for frequent problems:

  • Connection refused: Check if the target server has SSH enabled and if the firewall allows port 22.
  • Permission denied (publickey): Verify that the public key is correctly added to authorized_keys and check if file permissions are set to 600 or 400.
  • Authentication failed: Validate username spelling, key format, and server time synchronization status.

Use the sshd -t command to quickly detect syntax errors in configuration files; combining this with journalctl -u sshd to view system logs can also help pinpoint the specific cause.

Best Practices and Future Outlook

To build a secure remote access environment, it is recommended to follow these principles:

  • Always prioritize key-based authentication over passwords.
  • Enable two-factor authentication (e.g., Google Authenticator) for production environments.
  • Regularly audit SSH logs to identify abnormal login behavior.
  • Implement IP whitelist policies for high-value servers.

With the widespread adoption of cloud-native architectures, SSH is gradually evolving towards containerized and stateless services, yet its status as the cornerstone of remote management remains solid. Mastering SSH technology will lay a solid foundation for learning advanced operations skills such as Docker and Kubernetes in the future.