Connecting to a Remote Server Over SSH on a Mac
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
A secure shell (SSH) is used for secure communication between devices. When most people refer to SSH, it is within the context of connecting from a local computer to a remote server, commonly for administration tasks related to website hosting.
This article covers the basics of connecting to a remote server (such as a Linode) over SSH on macOS.
Ensure you have a Linux server with an SSH server (like OpenSSH) installed. Most Linux distributions have an SSH server preinstalled. If you wish to deploy a new server, follow the Creating a Compute Instance guide to create a Linode.
On your local computer, open the terminal application you wish to use. The terminal allows you to access your operating system’s shell environment and run programs through the command line.
The default terminal emulator for macOS is called Terminal. To open this program, access Spotlight by pressing
Space on the keyboard and type “Terminal” in the search box. In the search results, click on Terminal.app. Refer to Apple’s Open or Quit Terminal on Mac guide for additional methods of opening Terminal.
Within the terminal, enter the following command, replacing [username] with the username of the remote user and [ip-address] with the IP address or domain name of the remote server.
The SSH client attempts to connect to the remote server over port 22 (the default SSH port).
If the server’s SSH port is something other than 22, it needs to be specified in the SSH command. To do this, use the
-poption as shown in the command below. Replace [port-number] with the port number that the remote SSH server is using.
ssh [username]@[ip-address] -p [port-number]
When you connect with a server for the first time, the SSH client prompts you to check and verify the host key’s fingerprint. This is normal, and results in output similar to:
The authenticity of host ‘example.com (220.127.116.11)’ can't be established. ECDSA key fingerprint is SHA256:d029f87e3d80f8fd9b1be67c7426b4cc1ff47b4a9d0a84. Are you sure you want to continue connecting (yes/no)?
You can verify the fingerprint by following the instructions on the Verifying the Authenticity of a Remote Server guide.
If you recently rebuilt your server, you might receive an error message when you try to connect. This happens when the remote host key changes. To fix this, revoke the key for that IP address.
ssh-keygen -R 198.51.100.4
Accept the prompt by entering
yes, which results in a one-time warning that is similar to:
Warning: Permanently added 'example' (ECDSA) to the list of known hosts.
Once you have successfully connected, your terminal should be using the remote shell environment for the server. Your command prompt should now show the username and hostname configured for the server. You can now run any commands that you have available on that server. This includes many of the basic Linux commands, such as
rm, and those covered in Using the Terminal guide. Getting to know these commands will help you navigate around your server.
After you are done, log out of the session by typing
exit. The terminal then shows something similar to:
logout Connection to 18.104.22.168 closed.
At this point, the shell prompt returns to the one for the local workstation and the terminal application can be closed if it’s no longer needed.
Instead of using SSH to open your remote server’s console, you can run commands on your server without leaving your local shell environment. This can enable you to quickly run commands both locally and remotely in the same terminal window.
To run a single command on your remote server, use the following command. Replace [username] with the username of the remote user, [ip-address] with the IP address or domain name of the remote server, and [command] with the command you wish to run.
ssh [username]@[ip-address] [command]
As an example, running
ssh firstname.lastname@example.org ls lists all the files in the home directory of the user called
me. This can be useful to find the uptime of the server (
ssh email@example.com uptime) or maybe determine its Linux distribution and version (
ssh firstname.lastname@example.org lsb_release -a).
To run multiple commands on your remote server (one after the other), use the following command. Replace [command-1], [command-2], and [command-3] with the commands you wish to run.
ssh [username]@[ip-address] "[command-1]; [command-2]; [command-3]"
The commands should be separated by a semi-colon (
;) and all of the commands together should be surrounded by double quotation marks (
"). For example, if you wanted to create a file named bar.txt in a directory called foo within the user me’s home directory, run:
ssh email@example.com "mkdir foo; cd foo; touch bar.txt.
It’s recommended to disable root access over SSH and only log in to your remote server through a limited user account. However, some commands require elevated privileges, which can usually be accomplished by prepending the command with
sudo. If you attempt to do this while running commands directly through the SSH command, you may receive an error such as “no tty present” or there isn’t a “stable CLI interface”. To run the
sudo command in these instances, use the
-t option, which forces a pseudo-terminal allocation. For example, to update your packages on a Debian-based system, run
ssh firstname.lastname@example.org -t "sudo apt update".
If SSH isn’t connecting you to your Linode, you may need to investigate the state of your server. See the guide Troubleshooting SSH for assistance.
Now that you can connect from your Linux machine to the Linode over SSH, save not only time but also make the connection even more secure by using SSH public key authentication. For more information, see SSH add keys.
See the “Harden SSH Access” section of Setting Up and Securing a Compute Instance guide to review how to secure SSH on the server’s side, and the Advanced SSH Server Security for more information on making it even more secure.
This page was originally published on