SSH to a HIP hiplet from Mac and Linux: connection, keys, ~/.ssh/config // HIP-HOSTING

macOS and Linux already ship with an SSH client, so there's nothing to install beyond opening a terminal. We walk through the first password login to a HIP hiplet, moving to ed25519 key auth, a ~/.ssh/config alias, and what to do if SSH stops responding entirely.

If you want to SSH into a HIP server from macOS and Linux, there's nothing to install: both systems ship an OpenSSH client, and the whole process lives inside the Terminal app. The protocol itself doesn't change from the Windows version of this task, but the small details do: how the fingerprint prompt looks, where keys live on disk, and which built-in tools make the routine parts faster. Below: where to find your hiplet's IP and password, how the first login goes, how to move to ed25519 key auth, and what the most common connection errors actually mean.

Quick summary. Your root password and IP address live on your hiplet's Information tab in my.hip.hosting, inside the How to connect block. From a terminal: ssh root@IP, answer yes to the fingerprint prompt, then enter the password. Next, generate a key with ssh-keygen -t ed25519 and push it to the server with ssh-copy-id root@IP. Add the server to ~/.ssh/config so future logins are just ssh myhiplet. If SSH ever stops responding entirely, HIP has a real web console under the Console tab that bypasses the server's network stack and doesn't need SSH at all.

What you need before starting

A Mac or Linux machine. Both ship an OpenSSH client. Confirm yours is there: ssh -V should print something like OpenSSH_9.6p1.
A running hiplet. Its Information tab should show an active status. If you just created it, give it a minute or two to boot.
The IP and root password, covered in the next section.

No hiplet yet? Start with the guide to creating a server in the HIP panel. Connecting from Windows instead of Mac or Linux? You want the SSH-from-Windows guide with PuTTY instead.

Where to find your hiplet's IP address and password

Open the server in my.hip.hosting. You land on the Information tab by default. Below the server specs and status sits the How to connect block, holding the IP address and the root password. The password is hidden behind a blur with a copy icon next to it; clicking the field itself reveals it as plain text if you need to read it rather than just copy it.

Блок «Подключение» на вкладке «Информация» в панели HIP с IP-адресом сервера и скрытым паролем root.

The same Information tab has a Change password button, useful if you've forgotten the current password or want to reset it from the panel side instead of from inside the server with passwd (covered next). Both change the exact same root password, just from opposite directions: the panel resets it directly, passwd changes it from an already-open session.

Open a terminal. On macOS: Applications, Utilities, Terminal, or Spotlight search for "terminal." On Linux: Terminal in your applications menu. Type the command, swapping in your own IP:

ssh [email protected]

root: the account HIP sets up on a brand new hiplet;
45.14.247.252: the IP from the How to connect block.

The first time your client talks to a new server, it prints something like:

The authenticity of host '45.14.247.252 (45.14.247.252)' 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])?

That's not an error and not a sign of tampering. The fingerprint is a short digital summary of the server's key. Your client has never seen this server before and wants permission to remember that key. If it ever changes later, SSH stops you with a warning instead of silently letting you through.

Verifying a fingerprint for real means checking it over a channel that doesn't go through SSH itself. The HIP panel doesn't expose a field with the server's fingerprint anywhere, not on the Information tab, not on the Console tab either (the console connects through the hypervisor, but what it shows you is a login screen, not SSH key metadata). So the honest version of this step is plain trust-on-first-use: on a hiplet you just created, one nobody else has touched yet, the odds of the key already being spoofed are close to nothing. Type the full word yes, not just y, and hit Enter.

The client then asks for the password:

[email protected]'s password:

Enter the password from the panel. Nothing shows on screen while you type, no dots, no asterisks; that's normal terminal behavior. 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@hiplet-117445:~#. You're in.

You just typed the panel's password into a terminal in plain text, so it's worth setting your own before doing anything else:

passwd

It asks for a new password twice, with nothing displayed. Go long, sixteen characters or more.

What you should see: passwd: password updated successfully. One thing to keep in mind: the panel won't know about this change and will keep showing the old password in the How to connect block unless you also hit Change password there. That's fine for SSH, but hold onto that detail for the web console section further down.

Passwords can be brute-forced, and typing one every time gets old fast. A key handles both problems at once. A key pair is two files: the private one stays only on your own machine, the public one goes to the server, and the server lets in whoever can prove they hold the matching private key, without that private key ever traveling over the network itself.

	Password login	Key-based login
Setup	none, the password is already there	generate a key once and copy it over
Every connection	you type a password	nothing to type (or just the key file's passphrase)
Resistance to guessing	an automated scanner can brute-force it	an ed25519 key can't be brute-forced in any practical sense
When to rely on it	only for that first login	everywhere after, as the main way in

Generate a key pair. Run this on your own machine, not on the server:

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

-t ed25519: the key type, modern, compact, fast, and a sensible default;
-C "kate@macbook": a comment label so it's obvious later, on the server, whose key this is.

Hit Enter at the file location prompt to keep the default (~/.ssh/id_ed25519). For the passphrase prompt, it's your call: leave it blank for convenience, or set one if your laptop could realistically go missing.

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

Copy the public key to the server. This command creates the ~/.ssh directory on the server for you and appends the key to the right file (it'll ask for the password one last time):

ssh-copy-id [email protected]

If ssh-copy-id isn't available (it sometimes isn't on a stock macOS install without Homebrew), do the same thing manually 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'

It reads your public key, sends it to the server over the password login that still works, appends it to authorized_keys, and sets the correct permissions along the way.

Check this before moving on: run ssh [email protected] again. The server should let you in without a password (or ask only for the key file's passphrase, if you set one). Don't skip ahead to the next step until this works, or you risk locking yourself out entirely.

Once key login is confirmed, it's worth disabling password authentication in sshd completely. The reason isn't theoretical: any server with a public IP gets picked up fairly quickly by automated scanners that try common usernames and passwords across huge swaths of the internet. It's background noise, not a targeted attack on you specifically, but a password stays guessable while an ed25519 key, in any practical sense, doesn't. The full walkthrough of editing sshd_config, restarting the service, and checking you haven't locked yourself out is in Securing a Fresh VPS: Setting Up Ubuntu in Ten Minutes.

One thing worth remembering specifically for HIP: even after you disable password auth in sshd entirely, the root password itself keeps existing and working, just not for SSH. HIP's web console, under the Console tab, presents a system login prompt that bypasses sshd entirely, and by that logic it should still accept that same password - we deliberately did not test this exact combination live (did not want to risk losing SSH access to a working server to prove it), so treat it as an architectural inference, not a direct test. So don't delete or forget the root password once you move to keys; it stays your backup route if SSH itself ever breaks.

~/.ssh/config: connecting with one short command

Typing ssh [email protected] every time is unnecessary work. Describe the server once in ~/.ssh/config on your own machine (create the file if it doesn't exist):

Host myhiplet

HostName 45.14.247.252

User root

IdentityFile ~/.ssh/id_ed25519

Host myhiplet: a short name you pick yourself;
HostName: the server's actual IP address;
User: which account to log in as;
IdentityFile: which private key to use for this particular server.

Lock down the file: chmod 600 ~/.ssh/config. Now the whole connection is:

ssh myhiplet

scp and rsync understand the same alias, so copying files over gets shorter too. You can list as many servers as you like, each in its own Host block.

Common SSH errors and what they mean

Message	What it means	What to do
`Permission denied (publickey)`	The server rejected your key and isn't offering a password, meaning password login is already off	Check whether the public key actually landed in `authorized_keys` with correct permissions; if you can't log in any other way, use the web console
`Permission denied (publickey,password)`	Neither the key nor the password worked	Double-check the password against the panel; if it still fails, reset it with the button on the Information tab
`Connection refused`	The server answers on that IP, but nothing is listening on the SSH port: sshd isn't running or moved to another port	Log in through the web console and check `systemctl status ssh`
`Connection timed out`	Packets aren't reaching the server at all: wrong IP, server powered off, or an external firewall dropping the traffic	Check the hiplet's status and IP on the Information tab, power it on from Power control if needed

The first two are fixable as long as you have some way in, a working password or a working key. Things get worse when everything breaks at once: a botched sshd_config edit, port 22 accidentally blocked in ufw, a network interface that didn't come back up. That's the situation HIP's Console tab exists for. It connects to the server directly through the hypervisor, bypassing the network stack inside the machine entirely, and logs you in with the root password regardless of what's wrong with sshd or the firewall. For a full walkthrough of diagnosing and fixing a specific failure from inside it, see HIP's Web Console: Getting Into Your Server When SSH Won't Work.

Frequently asked questions

How do I SSH into my HIP hiplet from a MacBook?

Open Terminal (Applications, Utilities, or Spotlight search for terminal) and run ssh root@IP, using the IP from the How to connect block on your hiplet's Information tab. macOS already includes an SSH client, nothing extra to install.

ssh-copy-id is missing on my Mac, what do I do?

Copy the public key manually in one line: cat ~/.ssh/id_ed25519.pub | ssh root@IP 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'. Same result, just without the helper tool.

What does Permission denied (publickey) mean?

The server rejected your key and isn't falling back to a password prompt, which means password login is already disabled. If the key never worked to begin with, log in through HIP's web console and check whether the public key actually made it into ~/.ssh/authorized_keys with correct permissions.

How do I stop SSH from asking for a password every time?

Set up key-based login: ssh-keygen -t ed25519 on your own machine, then ssh-copy-id root@IP. After that, the server logs you in by key with no password prompt, unless you deliberately set a passphrase on the key file.

Yes, once key login is confirmed and actually working. Passwords can be guessed by automated scanners; an ed25519 key, in practice, can't. See the guide to securing a fresh VPS for the details.

What do I do if SSH won't connect to my HIP server at all?

Check the server's status in the panel first: it might simply be powered off rather than an SSH problem. If the server is running but SSH itself is broken (crashed sshd, a firewall rule, a lost key), open the Console tab in my.hip.hosting. It connects directly through the hypervisor and logs in with a password even when SSH is completely unreachable.

Takeaways

The root password and IP address sit in the How to connect block on your hiplet's Information tab in my.hip.hosting; the password stays blurred until you click it.
The first login is ssh root@IP, and you confirm the fingerprint with yes on trust-on-first-use grounds: the HIP panel doesn't display a fingerprint field anywhere to cross-check against.
Key-based login means ssh-keygen -t ed25519 plus ssh-copy-id. Confirm the key actually works before disabling password auth.
Disabling password login in sshd is worth doing, but only after the key is confirmed: automated scanners can guess passwords, they can't guess an ed25519 key.
A Host block in ~/.ssh/config shortens every future login to ssh myhiplet.
If SSH is fully broken (a bad sshd_config, a firewall lockout, a lost key), HIP's Console tab is a real fallback that bypasses sshd entirely and by that logic should still accept the root password even after password auth is turned off for SSH, though we have not tested that exact combination live.