How to connect to your server over SSH from macOS and Linux

SSH (secure shell) is the protocol for a protected connection to a remote server's command line. To connect to a server over SSH from macOS and Linux you do not install anything: the client is already built in and everything happens in the Terminal app. This guide walks through getting the address and password, the first login with a password, moving to key authentication, and setting things up so you never type the long command again.

In short. Get the server IP and the root password from the server page in the my.weasel.cloud panel. In the terminal: ssh root@IP, confirm the fingerprint by typing yes, enter the password, then change it with passwd. Next create a key with ssh-keygen -t ed25519 and copy it to the server using ssh-copy-id (no more password). Add the server to ~/.ssh/config so you can connect with a single ssh myvps.

What you need first

• A Mac or a Linux desktop. The OpenSSH client is built into macOS and ships with every mainstream Linux distribution. Check it is there: ssh -V prints a version like OpenSSH_9.6p1.
• The server details: IP address, user name (on a fresh server this is root), and the initial password. Where to find them is the next section.
• A running server. Its status in the panel should be "active". If you just created it, give it a minute to boot.

No server yet? Start with How to order your first VPS.

Where to get the IP address, user, and password

All of this is issued when the server is created, in two places:

• The my.weasel.cloud panel. Open the server's page: it shows the IP address (four numbers separated by dots, for example 203.0.113.10), the user (root), and the password.
• The server-created email. It goes to the address on your account and carries the same details. The initial password is in plain text there, which is why step 2 replaces it.

If SSH does not work for some reason, the panel has a web console: browser access to the same server that bypasses SSH. Use it to fix your configuration.

Step 1. Connect to the server over SSH with a password

Open a terminal. On macOS: Applications -> Utilities -> Terminal, or Spotlight for terminal. On Linux: "Terminal" in the application menu. Run this, with your own IP:

ssh [email protected]

• root is the user on the server;
• @ separates the user from the address;
• 203.0.113.10 is the server IP from the panel.

On the first connection to a new server the client shows something like:

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

This is not an error. The fingerprint is a short identifier of the server's key. The client has not seen this server before, asks permission to remember it, and warns that from now on it will check: if the key ever changes, you get stopped (see the "REMOTE HOST IDENTIFICATION HAS CHANGED" error below).

When to check the fingerprint. The strict way: open the server's web console in the panel, run ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub there, and compare the SHA256:... string with what the client printed. On a server that was just created and has never been connected to, the risk of a swap is minimal, so you can type yes and press Enter. Type yes in full, not y.

The client then asks for the password:

[email protected]'s password:

Enter the password from the panel. Nothing is echoed as you type (no dots, no asterisks) - that is normal. You can paste it: Cmd+V on macOS, Ctrl+Shift+V in most Linux terminals.

What you should see. The prompt changes to something like root@vps-12345:~#. That is the server's command line. You are in.

Step 2. Change the root password

The initial password sat in the panel and the email in plain text, so set your own right away:

passwd

The command asks for the new password twice (no echo). Make it long: 16 characters or more.

What you should see: passwd: password updated successfully. The old password no longer works.

Connecting on a non-standard port or as a different user

SSH listens on port 22 by default. If the server was moved off it (a common step against password brute-forcing), pass the port with -p:

ssh -p 2222 [email protected]

Here -p 2222 is the port number and user is the user name. To log in as a specific user on the default port, just put the name before @:

ssh [email protected]

The flags combine: ssh -p 2222 [email protected].

Step 3. Set up key authentication

A password can be brute-forced, and you retype it every time. A key fixes both. A key pair is two linked files:

• the private key (id_ed25519) stays on your machine only and is never shared;
• the public key (id_ed25519.pub) goes on the server. The server lets in anyone who can prove they hold the matching private key.

Create the pair. Run this on your own computer, not on the server:

ssh-keygen -t ed25519 -C "kate@macbook"

• -t ed25519 is the key type. ed25519 is modern, short, and fast, and is the right default.
• -C "kate@macbook" is a label comment so you can tell on the server whose key it is. People usually put an email or a machine name.

Press Enter at the file-location prompt (keeps ~/.ssh/id_ed25519). At the passphrase prompt you choose: set a passphrase to protect the key file (useful if the laptop is stolen), or leave it empty. If you set one, see the keychain section below.

What you should see: two new files in ~/.ssh/ - id_ed25519 and id_ed25519.pub.

Now copy the public key to the server. The easy way (it asks for the root password one last time):

ssh-copy-id [email protected]

It creates ~/.ssh on the server, appends your public key to ~/.ssh/authorized_keys, and sets the right permissions.

If ssh-copy-id is not present (it sometimes is not on macOS), do the same by hand in one line:

cat ~/.ssh/id_ed25519.pub | ssh [email protected] 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

The command reads your public key, sends it over SSH to the server, and appends it to authorized_keys, fixing permissions along the way.

Check: run ssh [email protected] again. If the key was picked up, the server lets you in without asking for a password (it may still ask for the key file's passphrase if you set one).

Turning off password login on the server is the next sensible step, but that is an edit to the sshd config on the server. A separate guide on disabling password login is coming soon. Only do it after you have confirmed that key login works.

Step 4. Permissions on the key files

The SSH client refuses to use a private key that other users on the system can read - this protects the key from theft. On your own machine set:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

• 700 on ~/.ssh: only the owner can enter and read it.
• 600 on the private key: the owner reads and writes, nobody else has access.

The server has the same requirements for ~/.ssh (700) and ~/.ssh/authorized_keys (600). If you copied the key with ssh-copy-id or the command above, the permissions are already correct.

One more thing on the server side. With StrictModes yes (the default), sshd ignores the key if any of three things is writable by group or others: the home directory, ~/.ssh, or the authorized_keys file itself. So 700 and 600 are not enough on their own - $HOME must also not be group- or other-writable. The reason for the refusal shows on the server in journalctl -u ssh as Authentication refused: bad ownership or modes for directory .... Fix it on the server via the web console:

chmod go-w ~ ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

The symptom of broken permissions: the server keeps asking for a password even though the key is in place.

macOS: save the passphrase in the keychain

If you set a passphrase on the key file, macOS can remember it in the system keychain so you do not enter it on every connection:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

To keep this working after a reboot, add these lines to ~/.ssh/config - inside the Host block for that server, not a global Host *:

Host myvps
HostName 203.0.113.10
User root
IdentityFile ~/.ssh/id_ed25519
AddKeysToAgent yes
IgnoreUnknown UseKeychain
UseKeychain yes

• AddKeysToAgent yes: load the key into the agent on first use.
• UseKeychain yes: read the passphrase from the keychain.
• IgnoreUnknown UseKeychain: must come before the UseKeychain line.

The IgnoreUnknown UseKeychain and UseKeychain yes lines are macOS-only. On Linux the client does not know the UseKeychain option, and without the IgnoreUnknown wrapper ssh refuses to run for any connection using that config, with a parse error. If the config file is only ever used on Linux, do not add the UseKeychain line at all. If one file travels between a Mac and Linux, keep both lines in the order above. If the server is already described in ~/.ssh/config (step 5), do not add a second block - append the last three lines to the existing one.

On older macOS (before Monterey) the flag was -K instead of --apple-use-keychain. On Linux the passphrase is held for the session by ssh-agent, which is usually already running under GNOME and KDE, so no extra setup is needed.

Step 5. The ~/.ssh/config file: connect with one command

Typing ssh -p 2222 [email protected] every time gets old. Describe the server once in ~/.ssh/config on your machine (create the file if it does not exist):

Host myvps
HostName 203.0.113.10
User root
Port 22
IdentityFile ~/.ssh/id_ed25519

• Host myvps: a short alias you pick yourself.
• HostName: the real IP address or domain name of the server.
• User: the user to log in as.
• Port: the SSH port (22 by default, you can omit the line).
• IdentityFile: which private key to use for this server.

Set permissions on the file: chmod 600 ~/.ssh/config. Now connecting is just:

ssh myvps

The alias also works with scp, rsync, and sftp. You can list as many servers as you like, each in its own Host block.

Copying files to the server and back

scp copies over SSH in a single call. The syntax is like plain cp, except the remote side has the server name and a colon before the path:

scp ./archive.tar.gz myvps:/root/
scp myvps:/var/log/syslog ./

The first line puts a local file on the server; the second pulls a file from the server into the current directory. For a whole directory, add -r: scp -r ./site myvps:/var/www/.

rsync is better for large or repeated transfers: it compares the two sides and sends only the parts that changed.

rsync -avz ./site/ myvps:/var/www/site/

• -a: preserve permissions, timestamps, and nested directories;
• -v: print which files are transferred;
• -z: compress data in transit (faster on a slow link).

A trailing slash on the source (./site/) means "the contents of the directory"; without it the site directory itself is copied into the target. rsync has to be installed on the server too - recent Ubuntu and Debian images usually have it, otherwise apt install rsync.

Keeping a session alive

A session where you type nothing can drop silently: intermediate hardware and firewalls close idle connections. To have the client remind the server it is there, add this to a Host * block in ~/.ssh/config:

Host *
ServerAliveInterval 60
ServerAliveCountMax 3

The client sends a keep-alive packet every 60 seconds. If there is no reply three times in a row (about three minutes), the connection is treated as dead and closed - at least you find out right away.

For long jobs (data transfers, builds, upgrades) that is not enough: if your internet drops, the process on the server dies with the session. Run those inside tmux, a program on the server that keeps a shell session running independently of your connection.

tmux

Start your long-running command inside it. If SSH drops, reconnect and return to the same session:

tmux attach

The job kept running the whole time. If tmux is not installed, run apt install tmux on the server.

Common errors

• Permission denied (publickey) - the server did not accept the key and no password is offered. Causes: wrong user in the command; the public key never reached ~/.ssh/authorized_keys; permissions on ~/.ssh or the home directory on the server are too open. Via the web console, check on the server: ~/.ssh is 700, authorized_keys is 600, the home directory is not group-writable. Then run ssh-copy-id again.
• Permission denied (publickey,password) - on top of that the password was wrong, or password login is disabled on the server. Verify the password in the panel; use the web console if needed.
• Connection refused - the server is reachable but nothing listens on that port: the sshd service is not running, or SSH was moved to another port. Get in through the web console, check systemctl status ssh and the port in /etc/ssh/sshd_config.
• Connection timed out - packets are not reaching the server: wrong IP, the server is off, or the port is blocked by an external firewall. Verify the address and the server status in the panel.
• REMOTE HOST IDENTIFICATION HAS CHANGED - the server's key changed since last time. The usual cause is an OS reinstall on that server. Remove the old entry and reconnect, confirming the new fingerprint: ssh-keygen -R 203.0.113.10 If nobody reinstalled the OS, do not connect until you understand why the key changed.
• Too many authentication failures - you have several keys, the client offers them to the server one by one, and the server drops the connection before reaching the right one. Point at a single key and stop the cycling: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected] Or add IdentitiesOnly yes to this server's block in ~/.ssh/config.
• Host key verification failed - the entry in ~/.ssh/known_hosts does not match the key the server sent (often paired with the key-changed message above). Work out the cause, then remove the entry: ssh-keygen -R <address>.

FAQ

How do I connect to a server over SSH from a Mac?

Open Terminal (Applications -> Utilities, or Spotlight for terminal) and run ssh root@IP-address, where the IP comes from the server's page in the panel. The SSH client is built into macOS, so there is nothing to install. On the first connection, confirm the fingerprint by typing yes and enter the root password.

How do I SSH into a server from the Linux terminal?

The same as on a Mac: ssh root@IP-address in any terminal. The OpenSSH client ships with every mainstream distribution. If the command is not found, install the package: apt install openssh-client on Debian and Ubuntu, dnf install openssh-clients on Fedora and AlmaLinux.

Where do I find my server's IP address?

On the server's page in the my.weasel.cloud panel, and in the email sent after the server was created. The address looks like four numbers separated by dots, for example 203.0.113.10. The same place lists the user (root) and the initial password.

SSH keeps asking for a password after I added a key

Most often the server did not find your public key in ~/.ssh/authorized_keys, or the ~/.ssh directory on the server has permissions that are too open. Via the web console, run chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys. The other cause: the client is offering the wrong key. Point at the right one with -i ~/.ssh/id_ed25519 or an IdentityFile line in ~/.ssh/config.

How do I save an SSH connection so I don't type it every time?

Describe the server in ~/.ssh/config: a Host block with HostName, User, Port, and IdentityFile. After that ssh myvps is enough. If the key has a passphrase, on macOS store it in the keychain with ssh-add --apple-use-keychain; on Linux ssh-agent remembers it until the end of the session.

Takeaways

• IP address, user, and password are on the server's page in the panel and in the server-created email.
• First connection: ssh root@IP, confirm the fingerprint with yes, enter the password, then change it with passwd.
• Non-standard port: ssh -p 2222 user@host. Different user: ssh deploy@host.
• Key auth: ssh-keygen -t ed25519, then ssh-copy-id user@host. The private key is never shared.
• Permissions: ~/.ssh is 700, the private key is 600. On macOS, put the passphrase in the keychain.
• ~/.ssh/config gives you a Host alias, then just ssh myvps.
• Files go with scp or rsync -avz. Long jobs run inside tmux.

Next steps

• How to connect to a server over SSH from Windows - if you also connect from a Windows machine.
• How to set up a basic ufw firewall - keep only the ports you need open.
• How to order your first VPS - if you do not have a server yet.
• Turning off SSH password login - a separate guide, coming soon.