ssh-keygen on Mac: No Terminal Means No Passphrase, Exit 0

I ran ssh-keygen on my Mac mini from a launchd job, the way a setup script or CI runner would, and gave it a passphrase through a pipe. I typed the two lines differently on purpose. It printed Passphrases do not match. Try again., then saved the private key with no passphrase at all and exited 0. Feeding it nothing did the same thing. In three of the four inputs I tried without a terminal, the result was a key anyone with the file can use, and none of them returned an error.

That is the part the usual "ssh-keygen mac" guide skips, because every guide assumes you are typing into Terminal. Below are the results from macOS 26.4.1 and its bundled OpenSSH 10.2p1: what the defaults are now, how the passphrase prompt behaves with and without a terminal, what Apple's keychain flags really do, and a count of the 644 Ask Different questions with "ssh" in the title, which shows where Mac users actually get stuck.

The short answer

# interactive, in Terminal: Ed25519 is already the default type
ssh-keygen -t ed25519 -C "[email protected]"

# in a script: never let it prompt. Pass the passphrase explicitly...
ssh-keygen -t ed25519 -N "$PASSPHRASE" -f "$HOME/.ssh/id_ed25519" -C "[email protected]"
# ...or say out loud that you want no passphrase
ssh-keygen -t ed25519 -N '' -f "$HOME/.ssh/deploy_key"

# store the passphrase in the login keychain (Apple's ssh-add only)
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

The flag that matters for scripts is -N. With it, ssh-keygen never asks, so it never reads whatever happens to be on standard input.

What a script without a terminal gets

When there is a terminal, ssh-keygen opens /dev/tty for the passphrase and ignores standard input. I checked that inside a tmux pane: I piped pw1 into it, typed zz at the prompt, and zz became the passphrase. A launchd job, a cron job, an SSH command without -t or a CI step has no terminal, so the prompt falls back to standard input. My shell's tty said not a tty, and these are the four runs:

The mismatch case is the nasty one. After the first try fails, ssh-keygen loops back to the prompt, reads end-of-file, takes that as an empty passphrase on both lines, and saves. The warning goes to standard error, which a lot of scripts throw away. The same thing happens if a heredoc or printf sends one line instead of two.

Two other prompts behave better. If the target file already exists, Overwrite (y/n)? reads end-of-file as no and exits 1 without touching the old key; I confirmed the fingerprint didn't change. And a path in a folder that doesn't exist fails with Saving key ... failed: No such file or directory, exit 1. Reading an encrypted key back with ssh-keygen -y and no terminal gives a misleading error, though: incorrect passphrase supplied to decrypt private key, exit 255, when what really happened is that it read an empty one. Pass -P and it works. The broader version of this problem, across the 73 bundled tools that reference /dev/tty, is in my post on open /dev/tty: Device not configured.

What the Mac's ssh-keygen defaults to now

Command	Result on macOS 26.4.1
ssh-keygen (no -t)	Ed25519, 256-bit
-t rsa	3072 bits
-t rsa -b 1024	Accepted, exit 0
-t rsa -b 1023	minimum is 1024 bits, exit 255
-t rsa -b 16385	maximum is 16384 bits, exit 255
-t dsa	unknown key type dsa, exit 255
-t ed25519-sk	No FIDO SecurityKeyProvider specified, exit 255
Comment (no -C)	[email protected]
File modes	private -rw-------, public -rw-r--r--

Ed25519 became the default in OpenSSH 9.5, and DSA was removed entirely in OpenSSH 10.0, so old tutorials that start with -t dsa now fail outright. The -sk types are listed but can't be created, because Apple ships no FIDO provider; I covered that in YubiKey SSH on Mac. The 1024-bit RSA key being accepted is worth knowing about: it's legal, it's weak, and nothing warns you.

Size and speed don't argue for RSA either. The Ed25519 private key was 432 bytes with a 113-byte public key. An RSA-4096 pair was 3,401 and 757 bytes. Five Ed25519 keys took 0.018 seconds in total; five RSA-4096 keys took 3.6 seconds.

Apple's keychain flags, measured

GitHub's Mac instructions have you add UseKeychain yes to ~/.ssh/config and run ssh-add --apple-use-keychain. Those are Apple additions, not part of upstream OpenSSH. I tested them against throwaway agents started with ssh-agent -a, never the real one:

• ssh-add -K still works but prints a five-line WARNING: The -K and -A flags are deprecated and exits 0. The man page says future releases will drop them unless you set APPLE_SSH_ADD_BEHAVIOR=macos. With APPLE_SSH_ADD_BEHAVIOR=openssh, -K means the upstream "load keys from a FIDO token" and fails with Cannot download keys without provider.
• --apple-use-keychain on an encrypted key stored the passphrase instantly, with no dialog, even in a headless launchd session. A fresh agent then loaded the key with --apple-load-keychain and no prompt.
• I couldn't see that stored entry with security find-generic-password or security dump-keychain; both came back empty. To remove it, use ssh-add -d --apple-use-keychain <key>. After that, --apple-load-keychain printed No identity found in the keychain. and still exited 0.
• Apple's ssh -G accepts UseKeychain yes without echoing it back. A typo like UseKeychainx fails with Bad configuration option, exit 255. I didn't install Homebrew's OpenSSH for this; GitHub documents that it rejects UseKeychain and suggests IgnoreUnknown UseKeychain.
• An encrypted key added from a script with no terminal and no SSH_ASKPASS printed the prompt and exited 1. With SSH_ASKPASS pointing at a helper and SSH_ASKPASS_REQUIRE=force, it loaded.

One more GitHub step to think about on a Mac: eval "$(ssh-agent -s)". macOS already runs an agent per login session through launchd (com.openssh.ssh-agent), and SSH_AUTH_SOCK pointed at its socket even inside my launchd job. Running eval starts a second agent and points only the current shell at it, so keys you add there are invisible to every other window and are gone once that agent exits.

Where Mac users actually get stuck

I pulled every Ask Different question with "ssh" in the title through the Stack Exchange API: 644 questions from August 2010 to July 2026, with 6,494,547 views between them. I sorted them by title keywords, first match wins:

Topic in title	Questions	Views
Passphrase, keychain, agent	72	1,547,755 (23.8%)
Keys: generation, RSA, Ed25519, permissions	69	535,000
Remote Login and sshd	54	330,721
Everything else	449	4,081,071

One question in nine is about passphrases, and those questions get almost a quarter of the views. The most-viewed, how to permanently add an SSH key to Keychain, has 1,033,648 views on its own. Next is macOS Sierra not remembering SSH keys between reboots (176,017), which is the change that made UseKeychain necessary. Making the key is rarely the problem. Living with its passphrase is. That's also why scripts are tempted to pipe one in, which is exactly the case that fails without a sound.

Once the key exists, which file it goes in on the server is a separate mix-up; known_hosts vs authorized_keys covers that with probes on a spare sshd.

FAQ

How do I generate an SSH key on a Mac?

Open Terminal and run ssh-keygen -t ed25519 -C "[email protected]", accept the default path ~/.ssh/id_ed25519, and enter a passphrase. macOS ships OpenSSH, so nothing needs installing. Then run ssh-add --apple-use-keychain ~/.ssh/id_ed25519 to store the passphrase in your login keychain, and paste the contents of the .pub file into GitHub or the server's authorized_keys.

Should I use RSA or Ed25519 on macOS?

Use Ed25519. It has been ssh-keygen's default since OpenSSH 9.5, the key is far smaller (a 113-byte public key versus 757 bytes for RSA-4096), and it generates much faster. Use RSA only for an old server that doesn't accept Ed25519, and then use -b 4096. DSA no longer works at all on current macOS: ssh-keygen -t dsa fails with "unknown key type dsa".

Why did ssh-keygen make a key without a passphrase in my script?

Without a terminal, ssh-keygen reads the passphrase from standard input. If that input is empty, has only one line, or has two lines that don't match, it ends up with an empty passphrase, saves an unencrypted key and exits 0. Pass the passphrase with -N "secret", or -N '' when you really want none, so it never prompts.

How this was tested: Mac mini (Mac16,10), macOS 26.4.1 (25E253), the bundled OpenSSH_10.2p1 with LibreSSL 3.3.6, run as a normal user from a launchd agent with no terminal; the terminal comparison ran in a separate tmux server with bash 3.2. All test keys were written to a scratch folder and deleted afterwards, ~/.ssh was not touched, ssh-add ran only against temporary agents started with ssh-agent -a, and the one keychain entry the test created was removed with ssh-add -d --apple-use-keychain and checked gone. Homebrew's OpenSSH was not tested. Timings are wall-clock for five keys of each type on October 13, 2026. The Ask Different count covers every question with "ssh" in the title returned by the Stack Exchange API on the same day, sorted by title keywords, so a question about agents whose title only says "key" is counted under keys. If your script runs from launchd, what a launchd job's environment really contains is the next thing to check.