How to SSH From an iPhone: Setup, Keys, and Staying Connected

Reaching a server from your phone is a genuinely useful skill, and the setup takes about ten minutes once. This covers what you need, how to handle keys without a laptop, the specific cases people ask about most, and the one problem that catches everybody out.

A quick disambiguation first, because two very different questions share the same words. This guide is about using an iPhone as an SSH client to reach a server. If you are trying to SSH into an iPhone, that requires a jailbroken device running its own SSH daemon, and none of this applies.

Can you SSH from an iPhone?

Yes, and with no compromises on the protocol side. iOS SSH clients give you a real interactive terminal running a real login shell, speaking standard SSH. The server cannot tell a phone from a laptop and needs no special configuration to accept one.

What differs is everything around the connection. A touch keyboard has no Ctrl, Esc, Tab, or arrow keys, so clients add a key bar to supply them. Screen space means long command output wraps hard. And iOS suspends backgrounded apps, which ends sessions in a way desktops never do. The first two are annoyances you adapt to within a day. The third is structural and is covered further down.

What do you need before you start?

• A server that accepts SSH. A VPS, a Raspberry Pi, a Mac with Remote Login enabled, a NAS. Anything running an SSH daemon.
• Its address and a username. A public IP or hostname for a VPS; a local address for something on your own network.
• A way to authenticate. A password if the server still allows them, or preferably a key.
• A path to the machine. Trivial for a VPS with a public IP. If the machine is at home behind a router, it has no public address and you will need a way in, which is a separate problem covered in SSH without port forwarding.

How do you SSH into a server from an iPhone?

The flow is the same in every client. Install one from the App Store, add a host with its address, port (22 unless someone changed it), and username, pick your authentication method, and connect. You land in your normal login shell.

Two things worth getting right the first time. Check the host key fingerprint when the client shows it on first connect. That prompt is the one moment SSH asks you to verify you are talking to the machine you think you are, and tapping through it blindly defeats the protection. Compare it against ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub run on the server. And use the right username, which on cloud images is rarely root: Ubuntu images use ubuntu, Amazon Linux uses ec2-user, Debian uses debian or admin. A correct key with the wrong username fails in a way that looks like a broken key.

How do you generate an SSH key on an iPhone?

In the client. Every serious iOS SSH app can create a keypair on the device, generally under a keys or identities screen. Pick ed25519 rather than RSA. The keys are shorter, faster to verify, and sidestep the SHA-1 signature deprecation that stops older ssh-rsa keys working against OpenSSH 8.8 and later, a failure that surprises people whose key worked for years.

The private key stays in the iOS Keychain, protected by the Secure Enclave, and never has to leave the phone. Only the public half travels. Getting that public half onto the server is the fiddly part when the phone is all you have:

• If you can already get in with a password, connect once and append the key by hand. Copy the public key from your client, then run mkdir -p ~/.ssh && chmod 700 ~/.ssh, open nano ~/.ssh/authorized_keys, paste it on its own line, save, then chmod 600 ~/.ssh/authorized_keys. Those permissions are not optional: sshd silently ignores the file if they are looser.
• If the provider offers a console, most cloud dashboards have a web or serial console that reaches a login prompt without SSH. Paste the key there.
• If you are building the server now, paste the public key into the provider's "SSH keys" field at creation time and it is installed before first boot.

Watch for line breaks. A public key is one single line, and an editor or messaging app that wraps it produces a key that silently never matches. If it does not work, Permission denied (publickey) walks through the causes in order.

How do you SSH from an iPhone to a Mac or a Raspberry Pi?

To a Mac

Turn on Remote Login on the Mac in System Settings under General, then Sharing. That starts the OpenSSH server already built into macOS and displays the address to use. Connect from the phone to that address on port 22 with your macOS account name, and authenticate with your login password or a key you have installed.

To a Raspberry Pi

SSH is off by default on Raspberry Pi OS. Enable it with sudo raspi-config under Interface Options, or, for a headless setup before first boot, put an empty file named ssh in the boot partition of the SD card. Connect as the user created during setup. Key-based authentication matters more here than anywhere else, because a Pi is the machine most likely to end up exposed to the wider internet with a weak password.

To either, from outside your home network

Both sit behind NAT with no public address, so neither is reachable from outside without help. That is a networking problem rather than an SSH one, and it has four possible answers, compared in SSH without port forwarding.

Why does the session drop when you lock the phone?

Two causes, and neither is a bug in your client.

iOS gives an app a short grace period after it leaves the foreground and then stops scheduling it entirely. The socket goes unserviced, the server eventually gives up, and by the time you reopen the app there is nothing to resume. Separately, moving between wifi and cellular changes your source IP address, and since a TCP connection is defined by its address pair, changing one ends the connection instantly. Walking out of your front door is enough.

Keepalives help with idle timeouts but cannot save you from either of these. Two things genuinely work:

• Run your work in tmux. Start with tmux new -s work and reattach with tmux attach -t work. Your shell then lives in a process on the server rather than inside the connection, so a dropped session costs you nothing but a reattach.
• Use Mosh where you can. Mosh replaces the SSH transport with a UDP protocol built for roaming, so it survives IP changes and sleep that SSH cannot. It needs a UDP port range open on the server and has no native scrollback, so most people run it alongside tmux rather than instead of it.

The full picture, including what client_loop: send disconnect: broken pipe is really telling you, is in why SSH sessions keep disconnecting.

Which SSH client should you use on iPhone?

The established options each optimise for something different. Termius is the polished all-rounder with cross-device sync and SFTP. Blink Shell is open source, keyboard-first, and has the best Mosh support on the platform. Prompt from Panic is the minimal, well-made choice if you want a terminal and nothing else.

What actually separates them in daily use is not terminal quality, which is good across the board, but three things worth checking before you commit: how good the key bar is, since you will press Ctrl and Esc constantly; whether it can generate and store keys on device; and what happens when the connection drops, because that is the interaction you will have most often.

How do you keep SSH secure from a phone?

1. Use keys, not passwords. Then disable password auth server side with PasswordAuthentication no in /etc/ssh/sshd_config, which removes brute forcing as a threat entirely.
2. Set a passcode and biometrics on the phone. Your keys live in the Keychain, so device security is server security.
3. Verify host key fingerprints on first connect, and treat a changed fingerprint as a real warning rather than something to dismiss.
4. Do not disable host key checking to make an error go away. It exists to detect exactly the attack it looks like.
5. Use a jump host for production. Reaching sensitive infrastructure through a bastion rather than exposing each machine is worth the extra hop.
6. Keep a second key from another device. A lost phone should not mean a lost server.

Editing sshd_config from a phone deserves one specific warning: keep your current session open while you test the change in a second connection. An existing session survives a broken config, so you always have a way back until you disconnect.

Can you SSH from an iPad?

Yes, and everything above applies unchanged, since iPadOS runs the same clients. The differences are all in your favour: more room for output, Split View alongside documentation, and hardware keyboard support that gives you back the modifier keys. The one thing that does not improve is app suspension, which behaves exactly as it does on iPhone.

The short version

Generate an ed25519 key in your client, get the public half into ~/.ssh/authorized_keys with 600 permissions, connect with the right username, and verify the host key the first time. Expect the session to drop when you lock the phone or change networks, and run anything that matters inside tmux so it does not cost you.

That last point is the one worth designing around rather than working around, which is what Onepilot does differently: shells run in a daemon on the host rather than inside the phone's connection, so backgrounding the app or switching from wifi to cellular leaves the session running and reconnecting replays what you missed, with no reattach command to type. It pairs a server by scanning a code the host prints, so there is no key to move by hand either. For choosing between the established clients, see the Termius vs Blink Shell comparison.