How to Log In to a Server via SSH Using Terminal on macOS

In short: In Terminal, type ssh, your username, an at sign and the server name, press Return, compare the fingerprint with one from your host before accepting it on the first visit, then enter the account password. A key and a short name in ~/.ssh/config make later logins one word.

A Mac needs no extra software to reach a server over SSH: the SSH client is built into macOS and runs in the Terminal app, so there is no PuTTY to install. This guide covers the first login, the host key question, other ports, key login, a short name for the server and the errors people meet first. Older posts and guides call the system Mac OSX; the commands are the same. Tested on macOS 27.0.1 with Apple's OpenSSH 10.3p1 against a test server running OpenSSH 9.7 (see the field note).

Before you start: the first steps only connect, but the key and configuration steps change files on your Mac and on the server. Try them on a test account first, save a copy of ~/.ssh/config before editing it, and apply everything at your own risk. iLogr cannot see your server or your Mac and accepts no responsibility for changes made to them.

How do you log in to a server over SSH from Terminal on a Mac?

Open the Terminal app and type ssh, then the account name, an at sign and the server's name or address:

ssh [email protected]

You can use an address instead of a name, for example ssh your-user@203.0.113.10 (an address from a block reserved for documentation, so it is safe to copy^[7]). The account must be allowed to use SSH on that server, and the name or address is the one your host gave you. Press Return. If it is the first visit you will see the host key question described below. Then SSH asks for the account's password:

[email protected]'s password:

Nothing appears while you type, not even dots. Press Return when you are done. A correct password drops you at the server's prompt, and every command you type now runs on the server^[2]. Type exit or press Control+D to leave. If a session freezes, press Return, then type ~. (tilde, dot) to drop the connection^[2].

Terminal also has a menu route: choose Shell, then New Remote Connection, pick ssh in the Service list, and enter the user name and server address^[1]. It builds the same connection, but the command is easier to repeat, script and save.

What is the question SSH asks the first time you connect?

On a first visit SSH shows the server's host key fingerprint and waits:

The authenticity of host 'server.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is SSH asking you to confirm that you are talking to the right machine before you send a password. Compare the fingerprint with one you can trust, such as your host's control panel or, if you can already reach the server another way, the output of this command on the server^[2][5]:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

If they match, type the whole word yes and press Return. SSH saves the key in ~/.ssh/known_hosts, and it does not ask again for that server. In a test the second connection went straight to the password prompt.

What if the server does not use port 22?

SSH assumes port 22. If your host uses another port, add -p and the number^[2]:

ssh -p 2222 [email protected]

-p comes before the user and host. If you leave it out, SSH tries port 22. In the lab that produced Connection refused (see the errors below); a firewall or another service on the server may produce a different error.

Why is logging in as root a poor idea?

The old version of this post logged in as root. A current OpenSSH server defaults to PermitRootLogin prohibit-password, which means root can log in with a key but not with a password^[4]. Hosts can change that setting, so your server may differ, but the sensible habit is the same: log in as a normal named account and use sudo for administrator tasks. Ask your host for such an account, or create one from the control panel.

How do you log in with a key instead of a password?

A key pair replaces the password with a private file that stays on your Mac. Create one in Terminal; Ed25519 is the default type^[5]:

ssh-keygen -t ed25519 -C "your-mac"

Choose a passphrase when asked. Accept the default file name only if you do not already have a key of that name. If ssh-keygen says the file already exists and asks whether to overwrite it, answer n and stop: replacing that key can lock you out of every server that depends on it. Reuse the existing key, or run the command again with -f ~/.ssh/id_ed25519_myserver (any unused name) and use that name in the commands and the configuration below. You end up with two files in ~/.ssh: the private key (id_ed25519) and the public key (id_ed25519.pub). Never share the private one. Install the public key on the server while you can still log in with the password:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

ssh-copy-id ships with macOS. The -i option names the public key to install; without it the script may pick up keys that your agent holds instead^[6]. It asks for the account password once and adds the key to the server's ~/.ssh/authorized_keys. In a test it reported one key added. For a non-standard port, add -p and the port number. Test the installed key with ssh -i ~/.ssh/id_ed25519 your-user@server.example.com, using your own private-key file name if it differs (add -p and the port number for a non-standard port). If the key is accepted, SSH asks for its passphrase, not the server password, unless an agent already supplies it. The configuration below saves the key path for later logins. If you kept the default name, the plain ssh command finds the key by itself.

To have macOS remember that passphrase through restarts, follow How to Add SSH Keys to ssh-agent on macOS After Restart.

How do you save the server under a short name?

Put the details in ~/.ssh/config and connect with one word. Create the folder and file if they do not exist, and keep any entries you already have:

mkdir -p ~/.ssh
nano ~/.ssh/config

Host myserver
  HostName server.example.com
  User your-user
  Port 22
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

In nano, press Control+O and Return to save, then Control+X to leave. Now ssh myserver does the same as the long command^[3]. Host is the short name you type, HostName is the real address, and IdentitiesOnly yes restricts SSH to the identity files configured for the connection instead of also offering every key the agent holds^[3]. SSH uses the first value it finds for each setting, so put specific blocks above a general Host * block, and note that several IdentityFile lines add up rather than replace each other^[3]. The file must not be writable by other users^[3]; chmod 600 ~/.ssh/config is a safe setting.

To see what SSH will actually use for a name, run ssh -G myserver. It prints the resolved user, host name, port and identity file without connecting^[6].

What do the common errors mean?

Connection refused. SSH reached the machine, but nothing was listening on that port, or a firewall turned the connection away. Check the port with your host. In a test it appeared when the server listened on a different port from the one SSH tried.

Permission denied (publickey,password,keyboard-interactive). The server rejected every method offered. Check the user name, retype the password, and for key login check that the public key is on the server and that the key file is the one you meant. The list in brackets shows which methods the server accepts, so yours may differ.

WARNING: UNPROTECTED PRIVATE KEY FILE! The private key is readable by other users, so SSH ignores it. Run chmod 600 ~/.ssh/id_ed25519. In a test a key with mode 0644 was ignored and the login fell through to Permission denied.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! The server's host key no longer matches the saved one. It can mean the server was reinstalled, which is common after a rebuild, or that something is intercepting the connection. Confirm the new fingerprint with your host first. If it is a known rebuild, remove the old entry and connect again^[5]:

ssh-keygen -R server.example.com

For a server on another port, give the name as "[server.example.com]:2222". SSH keeps the previous file as known_hosts.old.

Too many authentication failures. This one surprises people because the password may be right. The server limits authentication attempts per connection with MaxAuthTries, which defaults to 6^[4]. Keys your agent offers that the server does not accept can use up some of those tries before you get to type the password. In a test with three keys offered, the connection ended after two wrong passwords with Too many authentication failures. With the agent switched off and IdentitiesOnly yes, the same test allowed three password tries and then Permission denied. The test does not show an exact count for every server. If you hold many keys, name the one you want with IdentityFile and set IdentitiesOnly yes in the server's block^[3].

Field note. The prompts and messages above come from one test, with the host name, address and fingerprint replaced by placeholders: a test server running OpenSSH 9.7 in a disposable container, a throwaway user and throwaway keys, and Apple's /usr/bin/ssh 10.3p1 on macOS 27.0.1. The Terminal menu route and the root-login default were checked against Apple's guide and the OpenSSH manual rather than run.

References

Numbers in square brackets in the text link to these sources.

1. Apple, "Connect to servers" (Terminal User Guide) (opens in a new tab).Used for: the Shell, New Remote Connection route.
2. OpenBSD, "ssh(1)" (opens in a new tab).Used for: user@host form, -p, the host key question, the tilde-dot escape.
3. OpenBSD, "ssh_config(5)" (opens in a new tab).Used for: Host, HostName, User, Port, IdentityFile, IdentitiesOnly and file permissions.
4. OpenBSD, "sshd_config(5)" (opens in a new tab).Used for: the PermitRootLogin and MaxAuthTries defaults.
5. OpenBSD, "ssh-keygen(1)" (opens in a new tab).Used for: Ed25519 default, fingerprint check and removing a known_hosts entry.
6. Apple, manual pages ssh-copy-id(1) and ssh(1) on macOS 27.0.1 (run man ssh-copy-id in Terminal).Used for: what ssh-copy-id does and the -G option.
7. IETF, "RFC 5737: IPv4 Address Blocks Reserved for Documentation" (opens in a new tab).Used for: why the example address 203.0.113.10 is safe to copy.