LiveChat 
Support 
How to SSH Into a Linux Machine From a Mac: The Complete Step-by-Step Guide
If you manage a Linux server, a VPS, or even a Raspberry Pi on your network, you will eventually need a secure way to reach its command line from your Mac. SSH (Secure Shell) is the standard tool for this, and the good news is that macOS already ships with everything you need. There is no extra software to install, no third-party client to configure, and no licensing to worry about.
This guide walks you through how to SSH into a Linux machine from a Mac, from your very first connection to setting up password-free, key-based access that turns connecting into a single command.
Key Takeaways
• macOS includes a built-in SSH client in Terminal. You do not need to install anything.
• The basic command is `ssh user@host`. Add `-p` to specify a non-standard port.
• SSH keys are more secure and more convenient than passwords once configured.
• A `~/.ssh/config` file lets you replace long commands with a short, memorable alias.
• Most connection errors come from the wrong port, permissions, a changed host key, or a firewall.
Do You Need to Install Anything on macOS?
No. Every modern version of macOS includes OpenSSH, the same SSH client used across the Linux and Unix world. You access it through Terminal, which lives in `Applications > Utilities > Terminal`, or you can open it with Spotlight (press `Cmd + Space` and type “Terminal”).
To confirm SSH is available, open Terminal and run:
“`bash ssh -V “`
You should see output similar to `OpenSSH_9.x`. If you see a version number, you are ready to connect.
What Is the Basic SSH Command Syntax?
The core syntax is straightforward. You tell SSH which user to log in as and which host to connect to:
“`bash ssh username@hostname “`
For example, to connect as a user named `deploy` to a server at the IP address `203.0.113.45`:
“`bash ssh [email protected] “`
You can use a domain name instead of an IP if one points at your server:
“`bash ssh [email protected] “`
Connecting to a Non-Standard Port
By default, SSH listens on port 22. If your server administrator moved SSH to a different port (a common security practice), specify it with the `-p` flag:
“`bash ssh -p 2222 [email protected] “`
The first time you connect to a new server, SSH will ask you to verify the server’s host key fingerprint. Type `yes` to continue, and the fingerprint is saved to `~/.ssh/known_hosts` so you are not asked again.
Common SSH Flags
Here are the flags you will reach for most often:
| Flag | What it does | Example |
|---|---|---|
| `-p` | Connect to a specific port | `ssh -p 2222 user@host` |
| `-i` | Use a specific identity (private key) file | `ssh -i ~/.ssh/work_key user@host` |
| `-v` | Verbose output, useful for debugging | `ssh -v user@host` |
| `-L` | Forward a local port to the remote (tunneling) | `ssh -L 8080:localhost:80 user@host` |
| `-X` | Enable X11 forwarding for graphical apps | `ssh -X user@host` |
| `-C` | Enable compression on the connection | `ssh -C user@host` |
How Do You Generate an SSH Key Pair?
Passwords work, but SSH keys are both safer and more convenient. A key pair consists of a private key (which never leaves your Mac) and a public key (which you copy to the server). Authentication happens by cryptographic proof, so no password ever travels across the network.
Generate a modern Ed25519 key pair in Terminal:
“`bash ssh-keygen -t ed25519 -C “[email protected]” “`
When prompted, accept the default location (`~/.ssh/id_ed25519`) by pressing Enter, and optionally set a passphrase to encrypt the private key on disk. A passphrase adds a second layer of protection if your laptop is ever lost or stolen.
When the command finishes, you have two files:
- `~/.ssh/id_ed25519` — your private key (keep this secret, never share it)
- `~/.ssh/id_ed25519.pub` — your public key (safe to copy to servers)
If your server is older and does not support Ed25519, fall back to a strong RSA key with `ssh-keygen -t rsa -b 4096`.
How Do You Copy Your Public Key to the Server?
You need to place your public key into the server’s `~/.ssh/authorized_keys` file. The easiest way is with `ssh-copy-id`:
“`bash ssh-copy-id [email protected] “`
If SSH runs on a custom port, pass it through:
“`bash ssh-copy-id -p 2222 [email protected] “`
You will be asked for your password one last time. After that, your key handles authentication automatically.
Copying the Key Manually
`ssh-copy-id` is included with macOS, but if you ever need to do it by hand, this one-liner appends your public key to the server:
“`bash cat ~/.ssh/id_ed25519.pub | ssh [email protected] “mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys” “`
The `chmod` commands matter. SSH refuses to use an `authorized_keys` file or `.ssh` directory with loose permissions, which is one of the most common reasons key-based login silently fails.
Key-Based vs Password Authentication: Which Should You Use?
Both methods get you a shell, but they are not equal. Use this comparison to decide:
| Factor | Password Authentication | Key-Based Authentication |
|---|---|---|
| Security | Vulnerable to brute-force and guessing | Practically immune to brute-force |
| Convenience | Type a password every login | Connect automatically (or with one passphrase) |
| Network exposure | Secret travels to the server | Private key never leaves your Mac |
| Automation | Awkward to script safely | Ideal for scripts and CI/CD |
| Setup effort | None | A few minutes, one time |
The verdict for almost every use case: set up key-based authentication. Once configured, disable password login on the server entirely to shut the door on automated attacks.
How Do You Create SSH Shortcuts With a Config File?
This is where SSH goes from “useful” to “effortless.” The `~/.ssh/config` file lets you define named hosts with all their settings baked in, so you never have to type long commands again.
Here is the part most tutorials gloss over: when you combine key-based authentication with a `~/.ssh/config` entry, you do the setup exactly once and connecting becomes a single word for the life of that server. You stop memorizing IP addresses, ports, usernames, and key paths. And because keys replace passwords, that one-word shortcut is also dramatically more secure than the long, password-prompting command it replaces. Convenience and security usually pull in opposite directions; this is the rare case where they reinforce each other.
Create or edit the config file:
“`bash nano ~/.ssh/config “`
Add an entry like this:
“`text Host myserver HostName 203.0.113.45 User deploy Port 2222 IdentityFile ~/.ssh/id_ed25519 “`
Save and close. Now, instead of typing the full command, you simply run:
“`bash ssh myserver “`
That is it. SSH reads the host alias, fills in the address, port, user, and key, and logs you straight in. You can add as many `Host` blocks as you like, one per server you manage.
What Are the Most Common SSH Problems and Fixes?
Even a clean setup runs into snags. Here are the issues you are most likely to hit and how to resolve them.
Permission Denied (publickey, password)
This usually means the server rejected your credentials. Check that:
- You are using the correct username for that server.
- Your public key is actually in the server’s `~/.ssh/authorized_keys`.
- The permissions are right: `~/.ssh` should be `700` and `authorized_keys` should be `600`.
Run with `-v` to see exactly which authentication methods are being tried:
“`bash ssh -v [email protected] “`
Remote Host Identification Has Changed
If you see a large warning about a changed host key, the server’s identity no longer matches what is saved in `known_hosts`. This is expected after a server rebuild or IP reassignment, but it can also signal a problem, so verify the cause before proceeding. To remove the stale entry:
“`bash ssh-keygen -R 203.0.113.45 “`
Then reconnect and accept the new fingerprint.
Connection Refused or Connection Timed Out
These point to a network or service issue rather than credentials:
- Wrong port — confirm whether SSH is on `22` or a custom port.
- Firewall — a local or cloud firewall may be blocking the port. On many hosts you control firewall rules from a panel or with tools like `ufw`.
- SSH service down — the `sshd` daemon may not be running on the server.
Connect to a Server You Actually Control: DarazHost VPS and Dedicated Servers
Every technique in this guide assumes you have a Linux machine to connect to. DarazHost VPS and dedicated servers give you exactly that, with full SSH root access from any Mac or PC out of the box.
- Full root access over SSH so you can install, configure, and manage your server freely.
- Secure key-based access supported, so you can drop password logins and lock down your server the way this guide recommends.
- Reliable connectivity built for low-latency, stable SSH sessions whether you are deploying code or running maintenance.
- 24/7 expert support ready to help you generate keys, harden your SSH configuration, or troubleshoot a stubborn “permission denied.”
If you are looking for a server that pairs cleanly with the workflow above, are built for developers and administrators who live in the terminal.
How Do You Harden SSH Security?
Once you can connect comfortably, spend a few minutes locking things down. These changes are made on the server, typically in `/etc/ssh/sshd_config`, and applied with `sudo systemctl restart sshd`.
Disable Root Login
Logging in directly as `root` is risky because attackers know the username already. Create a normal user with `sudo` privileges and set:
“`text PermitRootLogin no “`
Disable Password Authentication
After confirming your key login works, turn off passwords entirely so brute-force attempts have nothing to target:
“`text PasswordAuthentication no “`
Change the Default Port
Moving SSH off port `22` will not stop a determined attacker, but it dramatically cuts the noise from automated bots scanning the standard port:
“`text Port 2222 “`
Remember to allow the new port through your firewall and update your `~/.ssh/config` to match.
Frequently Asked Questions
Do I need to install PuTTY or another client on a Mac?
No. PuTTY is a Windows tool. macOS includes the OpenSSH client natively, so you connect directly from Terminal with the `ssh` command. There is nothing extra to download.
Where are SSH keys stored on a Mac?
By default, keys live in the hidden `~/.ssh` directory in your home folder. Your private key is typically `id_ed25519` (or `id_rsa`) and your public key has the same name with a `.pub` extension. You can view the folder with `ls -la ~/.ssh`.
How do I connect to SSH on a different port?
Use the `-p` flag followed by the port number, for example `ssh -p 2222 user@host`. If you connect to that server often, add a `Port` line to its entry in `~/.ssh/config` so you never have to type it again.
Why does SSH keep asking for my password after I added a key?
The most common causes are incorrect permissions on the server’s `~/.ssh` directory or `authorized_keys` file, the key being placed in the wrong user’s home directory, or the server having password fallback enabled. Run `ssh -v user@host` to see which authentication methods SSH is attempting and where it fails.
Is key-based authentication really more secure than a strong password?
Yes. A private key is far longer and more random than any memorable password, and it never leaves your machine during login. This makes key-based authentication effectively immune to the brute-force and credential-stuffing attacks that target password logins.
Wrapping Up
Connecting to a Linux machine from a Mac is built into the operating system you already use. Start with the basic `ssh user@host` command, then invest a few minutes in generating an SSH key, copying it to your server, and creating a `~/.ssh/config` shortcut. After that one-time setup, secure access is as simple as typing a single word, and your server is meaningfully harder to attack.
