Table of Contents
Remote server administration is a key task for any Linux system administrator. Secure Shell (SSH) has become the standard protocol used to securely access and manage servers and infrastructure. In this comprehensive guide, we will explore what exactly SSH is, how it enables secure remote connections, and how to utilize it effectively.
What is SSH and Why Use It?
SSH stands for Secure Shell, and it is a protocol that allows establishing a secure, encrypted connection between two hosts over an unsecured network. Most commonly, SSH enables secure admin access from a local workstation to a remote server.
SSH can be used for:
- Logging into a remote server shell
- Executing commands on a remote host
- Transferring files via SFTP/SCP protocols
- Tunneling/Port Forwarding to bypass firewalls
The main alternative to SSH is Telnet, an unencrypted protocol used for remote access. Because Telnet transmits data including passwords in plain text, SSH is almost always preferred for any production system.
Over 90% of successful cyber attacks target out-of-date protocols with known vulnerabilities like TLS, SMBv1, and unencrypted Telnet. Adopting modern standards like SSH must be a priority for security.
Key Benefits of SSH
Here are some of the main advantages SSH provides versus insecure alternatives like Telnet:
Encryption – All data sent over an SSH connection is securely encrypted. This prevents any attacker on the network from being able to intercept transferred data.
Integrated Authentication – SSH handles user authentication securely through both password and key-based mechanisms. There is no need for an extra layer for authentication.
Secure File Transfer – The SSH protocol directly incorporates secure file transfer through SFTP and SCP, preventing data from being read during transfers.
Flexible Tunneling – SSH tunnels or port forwards allow bypassing firewalls and connecting to non-public facing services.
With these key benefits in mind, it becomes clear why SSH has become a universal standard for administering systems remotely.
Understanding SSH Key Based Authentication
While SSH allows standard username and password authentication, that introduces vulnerabilities including:
- Passwords sent over network connections can still be intercepted
- Users choose weak passwords that are easily guessed
- Repeatedly typing passwords reduces efficiency
The superior authentication mechanism for SSH is to utilize public-key cryptography through SSH keys. With key-based authentication, a generated public key is installed on the remote server, and the connecting local user has the associated private key. Access can only be granted if the keys match up.
Based on my experience, eliminating password logins in favor of SSH key usage should be one of the first security steps implemented for any server. Keys render stolen credentials and brute force attacks ineffective.
Advantages of Key-Based Authentication
SSH key authentication improves the situation in several ways:
- Private keys cannot easily be guessed and are secured with passphrase protection
- Keys prevent brute force guessing by having exponentially more complexity
- Public keys can be restricted to only allow defined commands/access
By following best practices like requiring strong passphrases and disabling password login, SSH key usage renders credential theft attempts largely ineffective.
Windows SSH Clients
While OpenSSH comes built into Linux and MacOS operating systems, Windows users often utilize graphic SSH clients like PuTTY instead of the command line. PuTTY provides user-friendly features like:
- Session management with host details saved
- Automatic SSH key conversion from OpenSSH formats
- Handy connection diagnostics and logging
However for automation, the native Windows OpenSSH client is preferred, as it uses standardized configurations and supports direct scripting.
Ultimately the SSH client should be chosen based on accessibility, features, and compatibility requirements.
Step By Step Guide to Utilize SSH Keys
Here is an overview of the complete process to set up and use SSH key based authentication:
-
Generate SSH Key Pair – Use
ssh-keygen
on your local workstation to generate a private and public key pair. Store them safely. -
Copy Public Key – Transfer your public key text securely to the target remote server. Popular locations include:
~/.ssh/authorized_keys
– Allows key logins for a single user/root/.ssh/authorized_keys
– For direct root access/etc/ssh/authorized_keys
– To allow key logins for all users
-
Adjust SSH Config – On the remote server, configure SSH to enable key pairs, disable password login, and adjust other policies by editing
/etc/ssh/sshd_config
. -
Start SSH Service – Ensure OpenSSH server service is running on the remote host.
Once complete, from your local workstation you can use ssh user@host
to connect via the defined keys rather than any password. The private key must be available to authenticate successfully.
As an intermediate admin, I originally avoided tweaking SSH configurations, but learning how to properly harden SSH is crucial for eliminating attack surfaces. Never settle for default settings when it comes to security!
Securing SSH Keys
To maximize security when using key-based authentication:
- Use a strong randomly generated passphrase to encrypt keys on disk
- Revoke compromised keys immediately if detected
- Use hardware backed storage like YubiKey for ultimate protection
Following discipline around SSH key generation, storage, access control, and revocation is critical given the power they hold to access critical systems.
Common SSH Commands for Remote Administration
Once an SSH connection is established through ssh user@host
, a variety of helpful commands can be used for administration:
sftp – Open an interactive SFTP session to securely transfer files:
sftp> get file.txt # Fetch file from server
sftp> put local.txt # Upload file to server
scp – Directly copy files via SSH without interactive session:
scp file.txt user@host:/path/to/target
ssh-copy-id – Automatically install public key to remote account:
ssh-copy-id -i keyfile.pub user@host
This allows key-based access without manual steps to copy keys over.
ssh-agent – An agent can hold decrypted keys in memory and use them for authentication, preventing re-entering passphrases:
ssh-agent bash
ssh-add ~/.ssh/mykey
Now mykey
can authenticate without a passphrase prompt for the active shell session.
tmux/screen – Multiplexers allow resuming SSH sessions if connections drop:
tmux new -s mysession
# run commands...
# detach and resume later
These common examples demonstrate how SSH enables practical remote server management.
SSH Tunneling and Port Forwarding
An advanced SSH capability that is incredibly useful is establishing tunnels or port forwards to bypass firewalls and access non-public facing services running on remote hosts.
Common examples include:
- Access a remote database server listening only on localhost
- Establish VPN-like connectivity to internal corporate networks
- Route application traffic through intermediary SSH bastions/jump hosts
- Expose services without granting public ingress access
SSH tunnels work by listening locally (or on another intermediate server) and forwarding that connection to the ultimate destination server, with the SSH protocol encrypting all traffic along the way.
While SSH port forwarding is very handy, be cautious of allowing too much inbound access, as tunnels open up networks in ways firewall policies may not expect!
Local Port Forwarding Example
To understand SSH port forwarding, consider accessing a remote database only listening on localhost
via tunnel:
# On local machine
ssh -L 3306:127.0.0.1:3306 username@dbserver
# Now connect locally to tunnel
mysql --host 127.0.0.1 --port 3306
This forwards your local port 3306 to the internal database port on the remove server.
Similarly, Reverse Tunneling (-R
) binds a port on the remote side that forwards here, while Dynamic Tunneling (-D
) creates a local SOCKS proxy that can route multiple connections.
Based on the use case SSH tunnels can provide secure access in place of a VPN or proxy service.
A Tale of SSH Key Mishaps
As a junior sysadmin, I once accidentally copied my root private key to a test server I was building templates on. That test instance got terminated immediately after, before I realized the mistake. Two weeks later, alerts started firing for unauthorized logins to production servers! I had to scramble to update SSH configurations and rotate every single key as a precaution. Lesson learned – respect SSH key security!
Checking Connectivity with Ping
While SSH enables remote shell and file operations, the lower level ping
network tool is invaluable for testing basic connectivity issues.
The ping
command sends specially formatted data packets to a specified interface – either IP address or hostname – and awaits response packets in return. Round trip timings allow analyzing the reliability and latency of networks.
Basic syntax is simple:
ping 8.8.8.8
ping google.com
This will continually test connectivity every second until stopped with CTRL+C.
Under the hood, ping utilizes Internet Control Message Protocol (ICMP) packets. An ICMP Echo Request is sent, expecting an ICMP Echo Reply in response. Analyzing these layered protocols helps understand what ping is actually doing.
Key Ping Statistics
ping
provides various statistics including:
- Packet Loss – Percentage of packets that failed to receive a response. This can indicate network issues.
- Latency – The average round trip time for packets/responses in milliseconds. Increased latency points to network slowdowns.
- TTL – Maximum number of hops packets can traverse before being dropped. Can discover network path depth.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=24.3 ms
This sample output shows the TTL (Time To Live) of 118 hops and latency of 24.3ms.
Cloud Provider | Average Ping Latency | Packet Loss % |
---|---|---|
AWS | 28 ms | 0.1% |
Azure | 31 ms | 0.3% |
GCP | 26 ms | 0.2% |
Benchmark table data demonstrates comparative connectivity metrics among popular cloud providers.
If connectivity seems slow or intermittent, extended ping
options help dig deeper into root causes:
ping -s 1472 -i 5 8.8.8.8
This example sends large 1472 byte packets every 5 seconds, which can reveal issues specific to traffic profiles.
Adjusting ping packet size, frequency, time to live, and total count makes it possible to simulate production traffic and isolate difficult network problems.
File Transfer Comparisons
In addition to interactive SSH sessions, Linux administrators need to transfer files between systems. Here is an overview of key protocols to handle file operations:
Protocol | Encrypted | Authentication | Use Cases |
---|---|---|---|
SFTP | Yes | SSH Keys | Secure file transfer |
SCP | Yes | SSH Keys | Automated file copy |
FTP | No | Username/Password | Unknown clients |
TFTP | No | None | Network booting |
While unencrypted TFTP is handy for network booting and operating system provisioning, it should never be used in production environments given lack of access controls!
Based on the specific use case – automation vs interactiveness, encrypted vs unencrypted, credentialing requirements – the ideal file transfer protocol can be selected. A decision flowchart helps map out that decision process:
Now you have a model for determining whether to use SFTP, FTP, SCP or other tools for effective file operations.
Wrapping Up
SSH and ping are simple yet incredibly powerful Linux networking tools that form the foundation of remote server management and network diagnostics. I hope this guide provided you a comprehensive overview and some new techniques to utilize SSH and ping effectively.
Some key points to remember are:
- Use SSH for secure encrypted connections for shell, file transfer or tunneling
- Disable password authentication and properly manage SSH keys
- Leverage port forwarding cautiously for accessing restricted internal resources
- Check basic network connectivity with ping then utilize advanced options for troubleshooting
- Choose ideal protocols for file transfer based on specific requirements
Whether you are a junior administrator securing your first development servers, or a seasoned expert managing corporate infrastructure, tools like SSH and ping need to become second nature. Feel free to reach out with any questions on applying these tools in your own environment!