One essential tool to master as a system administrator is SSH.
SSH, or Secure Shell, is a protocol used to securely log onto remote systems. It is the most common way to access remote Linux servers.
In this guide, we will discuss how to use SSH to connect to a remote system.
Deploy your frontend applications from GitHub using DigitalOcean App Platform. Let DigitalOcean focus on scaling your app.
Open your terminal.
Run the SSH command:
ssh username@your_server_ip
Review and accept the host fingerprint if prompted.
Authenticate using your password or an SSH key (if configured).
You’re connected!
Type exit
to close the SSH session and return to your local shell.
Successful SSH connection using Termius, showing Ubuntu welcome screen and shell prompt
To connect to a remote system using SSH, we’ll use the ssh
command.
If you are using Windows, you’ll need to install a version of OpenSSH in order to be able to ssh
from a terminal. If you prefer to work in PowerShell, you can follow Microsoft’s documentation to add OpenSSH to PowerShell. If you would rather have a full Linux environment available, you can set up WSL, the Windows Subsystem for Linux, which will include ssh
by default. Finally, as a lightweight third option, you can install Git for Windows, which provides a native Windows bash terminal environment that includes the ssh
command. Each of these are well-supported and whichever you decide to use will come down to preference.
If you are using a Mac or Linux, you will already have the ssh
command available in your terminal.
The most straightforward form of the command is:
ssh remote_host
The remote_host
in this example is the IP address or domain name that you are trying to connect to.
This command assumes that your username on the remote system is the same as your username on your local system.
If your username is different on the remote system, you can specify it by using this syntax:
ssh remote_username@remote_host
Once you have connected to the server, you may be asked to verify your identity by providing a password. Later, we will cover how to generate keys to use instead of passwords.
To exit the ssh session and return back into your local shell session, type:
exit
SSH works by connecting a client program to an ssh server, called sshd
.
In the previous section, ssh
was the client program. The ssh server was already running on the remote_host
that we specified.
On nearly all Linux environments, the sshd
server should start automatically. If it is not running for any reason, you may need to temporarily access your server through a web-based console or local serial console.
The process needed to start an ssh server depends on the distribution of Linux that you are using.
On Ubuntu, you can start the ssh server by typing:
sudo systemctl start ssh
That should start the sshd server, and you can then log in remotely.
As a bonus, if you’re using DigitalOcean, you don’t necessarily need an SSH client at all. DigitalOcean provides a built-in Console feature for each Droplet. This browser-based terminal lets you access your server even if your SSH client is misconfigured or unavailable. It’s especially helpful for first-time users or emergency access, keeping you fully within the DigitalOcean ecosystem without relying on third-party tools.
Access your server through DigitalOcean’s browser-based Console, ideal for emergency access without an SSH client.
For a more detailed explanation of how SSH servers and clients interact, check out SSH Essentials: Working with SSH Servers, Clients, and Keys.
When you change the configuration of SSH, you are changing the settings of the sshd
server.
In Ubuntu, the main sshd
configuration file is located at /etc/ssh/sshd_config
.
Back up the current version of this file before editing:
sudo cp /etc/ssh/sshd_config{,.bak}
Open it using nano
or your favorite text editor:
sudo nano /etc/ssh/sshd_config
You will want to leave most of the options in this file alone. However, there are a few you may want to take a look at:
Port 22
The port declaration specifies which port the sshd
server will listen on for connections. By default, this is 22
. You should probably leave this setting alone unless you have specific reasons to do otherwise. If you do change your port, we will show you how to connect to the new port later on.
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
The host key declarations specify where to look for global host keys. We will discuss what a host key is later.
SyslogFacility AUTH
LogLevel INFO
These two items indicate the level of logging that should occur.
If you are having difficulties with SSH, increasing the amount of logging may be a good way to discover what the issue is.
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
These parameters specify some of the login information.
LoginGraceTime
specifies how many seconds to keep the connection alive without successfully logging in.
It may be a good idea to set this time just a little bit higher than the amount of time it takes you to log in normally.
PermitRootLogin
selects whether the root user is allowed to log in.
In most cases, this should be changed to no
when you have created a user account that has access to elevated privileges (through su
or sudo
) and can log in through SSH in order to minimize the risk of anyone gaining root access to your server.
strictModes
is a safety guard that will refuse a login attempt if the authentication files are readable by everyone.
This prevents login attempts when the configuration files are not secure.
X11Forwarding yes
X11DisplayOffset 10
These parameters configure an ability called X11 Forwarding. This allows you to view a remote system’s graphical user interface (GUI) on the local system.
This option must be enabled on the server and given to the SSH client during connection with the -X
option.
After making your changes, save and close the file. If you are using nano
, press Ctrl+X
, then when prompted, Y
and then Enter.
If you changed any settings in /etc/ssh/sshd_config
, make sure you reload your sshd
server to implement your modifications:
sudo systemctl reload ssh
You should thoroughly test your changes to ensure that they operate in the way you expect.
It may be a good idea to have a few terminal sessions open while you are making changes. This will allow you to revert the configuration if necessary without locking yourself out.
~/.ssh/config
for Multiple SSH ConnectionsTo simplify access to multiple servers, create or edit ~/.ssh/config
:
Host dev-server
HostName 192.168.1.10
User devuser
Port 2222
IdentityFile ~/.ssh/dev_key
Then connect using:
ssh dev-server
This is useful if you manage multiple SSH keys and nonstandard ports.
While it is helpful to be able to log in to a remote system using passwords, it is faster and more secure to set up key-based authentication.
Key-based authentication works by creating a pair of keys: a private key and a public key.
The private key is located on the client’s machine and is secured and kept secret.
The public key can be given to anyone or placed on any server you wish to access.
When you attempt to connect using a key pair, the server will use the public key to create a message for the client computer that can only be read with the private key.
The client computer then sends the appropriate response back to the server, which will tell the server that the client is legitimate.
This process is performed automatically after you configure your keys.
To dive deeper into the mechanics behind SSH encryption and how the connection process works, read Understanding the SSH Encryption and Connection Process.
SSH keys should be generated on the computer you wish to log in from. This is usually your local machine.
Enter the following into the command line:
ssh-keygen -t rsa
You may be prompted to set a password on the key files themselves, but this is a fairly uncommon practice, and you should press enter through the prompts to accept the defaults. Your keys will be created at ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa.
For a comprehensive walkthrough on configuring SSH key-based access, see How to Configure SSH Key-Based Authentication on a Linux Server.
Change into the .ssh
directory by typing:
cd ~/.ssh
Look at the permissions of the files:
ls -l
Output-rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys
-rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa
-rw-r--r-- 1 demo demo 396 Sep 9 23:13 id_rsa.pub
As you can see, the id_rsa
file is readable and writable only to the owner. This helps to keep it secret.
The id_rsa.pub
file, however, can be shared and has permissions appropriate for this activity.
If you currently have password-based access to a server, you can copy your public key to it by issuing this command:
ssh-copy-id remote_host
This will start an SSH session. After you enter your password, it will copy your public key to the server’s authorized keys file, which will allow you to log in without the password next time.
There are a number of optional flags that you can provide when connecting through SSH.
Some of these may be necessary to match the settings in the remote host’s sshd
configuration.
For instance, if you changed the port number in your sshd
configuration, you will need to match that port on the client side by typing:
ssh -p port_number remote_host
Note: Changing your ssh port is a reasonable way of providing security through obscurity. If you are allowing SSH connections to a widely known server deployment on port 22
as normal and you have password authentication enabled, you will likely be attacked by many automated login attempts. Exclusively using key-based authentication and running SSH on a nonstandard port is not the most complex security solution you can employ, but you should reduce these to a minimum.
If you only want to execute a single command on a remote system, you can specify it after the host like so:
ssh remote_host command_to_run
You will connect to the remote machine, authenticate, and the command will be executed.
As we said before, if X11 forwarding is enabled on both computers, you can access that functionality by typing:
ssh -X remote_host
Providing you have the appropriate tools on your computer, GUI programs that you use on the remote system will now open their window on your local system.
Error | Possible Cause | Recommended Solution |
---|---|---|
SSH Connection Refused | SSH service (sshd ) not running or port blocked |
Start SSH: sudo systemctl start ssh ; check firewall rules |
Permission Denied (Publickey) | Incorrect file permissions or missing public key | Fix permissions: chmod 700 ~/.ssh , chmod 600 ~/.ssh/authorized_keys |
SSH Timeout or Hang | DNS issue, unreachable host, or blocked port | Use verbose debug: ssh -vvv user@host ; check network/firewall |
Error | Possible Cause | Advanced Solution |
---|---|---|
Host key verification failed | Mismatch in known_hosts file due to IP/host change |
Remove old key: ssh-keygen -R server_ip ; or edit ~/.ssh/known_hosts manually |
Too many authentication failures | Too many keys attempted by SSH agent | Force identity: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_rsa user@host |
Connection closed by remote host | Idle timeout or restricted config on remote server | Check sshd_config for ClientAliveInterval , MaxAuthTries , or login limits |
Bad owner or permissions on .ssh | Loose file permissions pose a security risk | Ensure: chmod 700 ~/.ssh , chmod 600 ~/.ssh/id_rsa , chmod 644 ~/.ssh/id_rsa.pub |
Cannot resolve hostname | Typo in hostname or DNS failure | Verify DNS, correct typos, or edit /etc/hosts for static resolution |
Authentication refused: no methods available | Both password and key-based auth disabled on server | Ensure keys are installed or enable one method in /etc/ssh/sshd_config |
If you have created SSH keys, you can enhance your server’s security by disabling password-only authentication. Apart from the console, the only way to log into your server will be through the private key that pairs with the public key you have installed on the server.
Warning: Before you proceed with this step, be sure you have installed a public key to your server. Otherwise, you will be locked out!
As root or user with sudo privileges, open the sshd
configuration file:
sudo nano /etc/ssh/sshd_config
Locate the line that reads Password Authentication
, and uncomment it by removing the leading #
. You can then change its value to no
:
PasswordAuthentication no
Two more settings that should not need to be modified (provided you have not modified this file before) are PubkeyAuthentication
and ChallengeResponseAuthentication
. They are set by default and should read as follows:
PubkeyAuthentication yes
ChallengeResponseAuthentication no
After making your changes, save and close the file.
You can now reload the SSH daemon:
sudo systemctl reload ssh
Password authentication should now be disabled, and your server should be accessible only through SSH key authentication.
PasswordAuthentication no
)PermitRootLogin no
Windows:
Use PowerShell, Git Bash, or WSL to access SSH.
Example:
ssh user@server_ip
macOS/Linux:
Use the built-in terminal and the same command.
Generate keys using:
ssh-keygen
Q: What is SSH used for?
SSH, or Secure Shell, is primarily used to securely log into remote systems, typically Linux-based servers. It creates an encrypted channel over an unsecured network, allowing you to execute commands, transfer files, and manage infrastructure securely. SSH is critical for system administrators, developers, and DevOps teams to remotely access virtual machines (like DigitalOcean Droplets), automate tasks with scripts, and even forward ports or tunnel traffic through secure connections for added protection and control.
Q: How do I generate SSH keys?
SSH keys are generated using the ssh-keygen
utility, which creates a secure public-private key pair. Run ssh-keygen -t rsa -b 4096
to create strong RSA keys. The private key remains on your local machine, typically stored in ~/.ssh/id_rsa
, while the public key (id_rsa.pub
) is placed on the remote server. When connecting, the server uses the public key to verify your identity without transmitting passwords. Key-based authentication enhances both security and automation for server access.
Q: What does “Permission denied” mean in SSH?
The “Permission denied” error in SSH usually indicates an authentication failure. This may be caused by incorrect usernames, expired or improperly set permissions on your .ssh
directory or key files, or missing public keys on the remote server. SSH requires the ~/.ssh
directory to have 700
permissions and private keys like id_rsa
to have 600
. It could also mean that the SSH server disallows password authentication or root login, depending on how sshd_config
is set.
Q: Is SSH safe to use?
Yes, SSH is considered one of the most secure methods for accessing remote systems. It uses asymmetric encryption and modern cryptographic algorithms to ensure confidentiality and data integrity. Security can be improved by disabling password authentication, using key pairs, changing the default port, enabling two-factor authentication (2FA), and using tools like Fail2Ban to prevent brute-force attempts. Regularly updating the SSH server and auditing logs also helps mitigate vulnerabilities and unauthorized access.
Q: Can I use SSH on Windows?
Absolutely. Windows now supports SSH natively through PowerShell and OpenSSH, especially in Windows 10 and later. You can also use Git Bash, which includes an SSH client, or enable the Windows Subsystem for Linux (WSL) for a full Linux environment. Each method allows you to use the ssh
command to connect to servers. Generating SSH keys and configuring SSH access works similarly to Linux/macOS, making Windows a viable platform for remote system management via SSH.
Learning your way around SSH will greatly benefit any of your future cloud computing endeavors. As you use the various options, you will discover more advanced functionality that can make your life easier. SSH has remained popular because it is secure, lightweight, and useful in diverse situations.
To deepen your SSH knowledge, you can refer to these additional resources:
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Former Senior Technical Writer at DigitalOcean, specializing in DevOps topics across multiple Linux distributions, including Ubuntu 18.04, 20.04, 22.04, as well as Debian 10 and 11.
Helping Businesses stand out with AI, SEO, & Technical content that drives Impact & Growth | Senior Technical Writer @ DigitalOcean | 2x Medium Top Writers | 2 Million+ monthly views & 34K Subscribers | Ex Cloud Engineer @ AMEX | Ex SRE(DevOps) @ NUTANIX
Building future-ready infrastructure with Linux, Cloud, and DevOps. Full Stack Developer & System Administrator @ DigitalOcean | GitHub Contributor | Passionate about Docker, PostgreSQL, and Open Source | Exploring NLP & AI-TensorFlow | Nailed over 50+ deployments across production environments.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
The ssh-copy-id was not working on my Mac, so I’d like to share how I got it working.
Install ssh-copy-id sudo curl https://raw.github.com/beautifulcode/ssh-copy-id-for-OSX/master/ssh-copy-id.sh -o /usr/local/bin/ssh-copy-id sudo chmod +x /usr/local/bin/ssh-copy-id
Copy the public key: ssh-copy-id -i ~/.ssh/id_rsa.pub ‘-p <port number> <username>@<ip address’
Thank you very much, Mr. Justin. I can install whmsonic from ubuntu from your article.
I did exactly as instructed and it all seemed to work but it changed nothing in regards to having to type in a password. I still have to type one in. Did you miss stating the obvious, like that we still have to make config changes on the server or something?
@forgotmyorange: If you connect with <code>ssh -vv root@your.ip.address</code> it will add debugging output so that you can see what is happening behind the scenes. If it is actually connecting with the key, you should see something like:
<pre> debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/asb/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 </pre>
Hey thanks. It’s the clearest tutorial I found! and your blog looks nice.
I guess you forgot to mention you can disable password authentication after setting up SSH keys, as not to be exposed to brute force attacks.
Hey thanks. It’s very helpful tutorial.
I have query regarding to see the server console for the running processes. So, can you please suggest me the command to see the running server console, so that i will be able to see the errors if occurs?
Hi, Thanks, extremely clear guidance. The local system is Cygwin on a WIndows 7 PC, The remote system is Ubuntu.
I still have a problem :
"we sent a publickey packet" - but there is no reply :
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/jbww/.ssh/id_rsa (0x80061bd0),
debug2: key: /home/jbww/.ssh/id_dsa (0x0),
debug2: key: /home/jbww/.ssh/id_ecdsa (0x0),
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jbww/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/jbww/.ssh/id_dsa
debug1: Trying private key: /home/jbww/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Does anyone have an idea as to what I can try ?
On cPanel based server you can connect it easily.
Follow this video: https://www.youtube.com/watch?v=9Yx1gZKgb5Y
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Full documentation for every DigitalOcean product.
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.
New accounts only. By submitting your email you agree to our Privacy Policy
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.