SSH from an iPhone or iPad: The Complete Guide

A phone is a strange place to run a shell. There is no physical keyboard, the operating system suspends your app the moment you switch away, and the screen is the size of a postcard. And yet an iPhone is the computer you actually have with you when a deploy goes sideways — so it is worth knowing precisely what SSH on iOS can and cannot do, rather than finding out at 23:40.

The short answer: yes, an iPhone or iPad can SSH into any server you can reach from a laptop. You need an SSH client app from the App Store, a key on the device, and one habit on the server side so a dropped connection costs you nothing. No jailbreak, no Mac, no companion software.

This guide covers the quick start, the platform reality, the setup that avoids the common failure modes, and the handful of habits that make a phone terminal genuinely usable.

Quick start: SSH from an iPhone or iPad in five steps

1. Install an SSH client. iOS has no built-in terminal, so the client app is the terminal. Which one fits depends on what else you need; see which SSH app to use below.
2. Add the server. Hostname or IP address, username and port (22 unless you changed it). If you already have an ~/.ssh/config on a laptop, import it instead of typing.
3. Generate a key in the app and copy the public half (the line starting with ssh-ed25519).
4. Add that line to ~/.ssh/authorized_keys on the server, from a machine that can already log in, or log in once with your password and paste it there.
5. Connect, check the host fingerprint, and accept it. From then on, logging in is a Face ID prompt.

The rest of this guide explains why each step matters and what to do about the one thing that surprises everyone: the session dropping when you switch apps.

What iOS actually allows

SSH is just a protocol over a TCP connection, and iOS is perfectly happy to open outbound TCP sockets. That is why a native SSH client needs no jailbreak, no companion server and no special entitlement: the app implements the protocol itself and renders a terminal emulator on top.

Three platform rules shape everything else:

• No inbound connections you can rely on. Your phone moves between carrier NAT and Wi-Fi networks. You connect out to servers; nothing connects in to you.
• Apps get suspended in the background. A few seconds after you leave the app, iOS freezes it. Frozen apps do not hold TCP connections open. There are narrow background modes for specific purposes, but "keep my shell alive for an hour" is not one of them.
• There is no shared system shell. Each app is sandboxed, so your SSH client cannot invoke a system ssh binary or read a global ~/.ssh directory. It has its own store of hosts and keys, which is also why importing an existing config matters.

None of these are dealbreakers. They just mean the workflow that works on a laptop needs one adjustment on a phone, described below.

Which SSH app to use

Every serious iOS SSH client handles the basics: keys, a terminal, an extra key row. They differ in what else they bundle, and whether they want an account.

• Need Mosh for connections that survive network changes? Blink Shell, Prompt 3, Termius and WebSSH have it.
• Also on Windows, Linux or Android? Termius is the only one that runs everywhere.
• Want server folders in the Files app? Look at Secure ShellFish.
• Want one app for terminal, SFTP files and tunnels across iPhone, iPad and Mac, with no account? That is what we built Moray for.

We make Moray, so weigh that accordingly. The comparison of SSH clients for iPhone, iPad and Mac lists what each app actually does and costs, including where Moray is not the right pick, and Termius alternatives covers the most common switch.

Set up a connection that will not bite you

Use a key, not a password

Type a 24-character password into a phone keyboard twice and you will understand the appeal of key authentication. Generate a key on the device, add the public half to the server, and authentication becomes a biometric prompt.

# on the server, once
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3Nza... phone" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

One key per device is a good default: if the phone is lost, you remove one line from authorized_keys on each server and nothing else about your setup changes. See SSH keys explained for the algorithm choice and where the private half should live.

Verify the host key the first time, deliberately

The first time you connect, your client has no idea what the server's public key should be. It shows you a fingerprint and asks. That prompt is the entire security model of SSH host verification, and tapping through it without looking is how people end up trusting a man-in-the-middle.

Get the real fingerprint from a console you already trust:

# run this on the server itself
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare, then accept. From then on, a changed fingerprint is a loud warning rather than a shrug — and it should be. Host keys change when a server is rebuilt, and they also change when someone is impersonating it.

Import your existing config instead of retyping it

If you already have an ~/.ssh/config on a laptop, that file is the fastest path to a usable phone setup. A good client will parse the parts that matter:

Host prod-web-1
    HostName web1.example.com
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump bastion.example.com
    LocalForward 5432 localhost:5432

That single block carries the hostname, user, non-default port, which key to use, the bastion to hop through, and a tunnel — all things that are tedious and error-prone to enter by hand on a touchscreen.

The session-dropping problem, and the fix

This is the one thing that surprises everybody. You start a long apt upgrade, switch to Slack to tell someone it is running, come back, and the connection is dead. The upgrade may or may not have survived.

Do not fight the platform. Move the shell to the server:

# first time on the server
sudo apt install tmux      # or: sudo dnf install tmux

# then, every time you connect
tmux new -A -s phone

tmux new -A -s phone attaches to a session called phone if it exists and creates it otherwise — so it is the only command you need to remember. Now your shell, your scrollback and anything running in it live on the server. A dropped connection costs you nothing: you reconnect, run the same command, and you are back mid-sentence.

Put it in your host's run-on-connect commands and it becomes invisible — the full tmux starter is in tmux: SSH sessions that survive anything.

A second habit worth adopting on the server side:

# /etc/ssh/sshd_config
ClientAliveInterval 30
ClientAliveCountMax 4

That makes the server notice a genuinely dead client within a couple of minutes instead of leaving zombie sessions around, and it keeps NAT mappings from timing out mid-session.

Making a touchscreen keyboard survivable

A terminal needs keys an iOS keyboard does not have. Esc, Tab, Ctrl, arrows and a working paste are the difference between "usable" and "novelty".

• Esc and Ctrl need to be one tap away, not buried in a menu. Vim and readline are unusable otherwise.
• Arrows matter more than you expect — shell history is how you avoid retyping.
• Paste should be a button. Long-press-select-paste in a terminal grid is miserable.
• Snippets beat typing. The commands you run on a phone are usually the same six commands; store them with fill-in blanks and stop retyping them.

On iPad, attach a hardware keyboard and the picture changes completely — it becomes a real terminal with a real keyboard, and the only remaining difference from a laptop is the background-suspension rule above.

What a phone terminal is actually good at

Being honest about the use case makes it more useful, not less:

A phone is an excellent remote control for servers and a mediocre workstation. Set it up as the former and it earns its place.

Can you SSH into an iPhone?

Not on a stock device. Everything above is about the iPhone as the client. iOS does not run an SSH server, and apps cannot accept incoming connections in the background, so there is no supported way to open a shell on the phone itself from another computer. Guides that promise otherwise rely on a jailbreak. To move files between a Mac and an iPhone, AirDrop or the Files app is the supported route; to reach a server from the phone, you are in the right place.

A five-minute checklist

• Generate a key on the device and add the public half to authorized_keys.
• Verify each host key against a fingerprint you obtained out of band.
• Import ~/.ssh/config rather than retyping hosts.
• Install tmux on the server and make tmux new -A -s phone your run-on-connect command.
• Set ClientAliveInterval in sshd_config so dead sessions get reaped.
• Store your six most-used commands as snippets with placeholders.
• If the server is at home, read SSH into a Raspberry Pi or homelab before opening any router port.

Do those once and the phone stops being a compromise. It becomes the thing you reach for because it is already in your hand.