Apple Magic Keyboard on Linux: pairs, connects, doesn’t type. Here’s the fix.

My Magic Keyboard (A2450) worked with my Linux desktop for over a year. Then I paired it to a MacBook for a week, brought it back, and lost an afternoon to it. It showed up in Bluetooth settings but wouldn’t connect. Then it paired but dropped after seconds. Then it connected — GNOME said so! — and produced zero keystrokes.

This is the guide I wish I’d found: the debugging session compressed into the right steps, with the real commands and error messages.

The two traps:

1. A Magic Keyboard that was paired to a Mac hides from everyone else. It only broadcasts anonymous beacons under rotating random addresses. “Disconnect” on macOS doesn’t release it — the bond has to be destroyed properly.
2. bluetoothctl pair without a pairing agent creates an unauthenticated pairing with no bond. The keyboard tolerates it for about three seconds, then hangs up and revokes it. Paired: yes next to Bonded: no in bluetoothctl info is the tell.

Setup: Arch-based distro (CachyOS), BlueZ 5.86, GNOME. Should transfer to anything with recent BlueZ.

Step 0 — Plug it in

The keyboard works perfectly over USB the whole time, so a Lightning cable gives you a working keyboard for the rest of this guide. You’ll unplug it only for the actual pairing moment — while wired, it doesn’t advertise properly over Bluetooth.

If typing over the cable doesn’t work, check that the cable carries data (charge-only Lightning cables are everywhere):

$ lsusb | grep -i apple
Bus 005 Device 019: ID 05ac:029c Apple, Inc. Magic Keyboard

Step 1 — Release the keyboard from the Mac

Do this exactly in this order:

1. Let the keyboard connect to the Mac (turn the Mac’s Bluetooth on if needed — it’ll connect instantly, that’s the whole problem).
2. System Settings → Bluetooth → Magic Keyboard → ⓘ → Forget This Device.
3. Turn the Mac’s Bluetooth off.

The order matters: forgetting the keyboard while it’s not connected only cleans up the Mac’s side, and the keyboard keeps its bond and keeps hiding. The unpair command has to reach the keyboard over an active connection.

Get Nils Jonas Fink’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

How to recognize this trap in bluetoothctl with scan on: a nameless device with a very strong signal (it's on your desk) that keeps changing its MAC address:

[NEW] Device 5C:30:82:50:20:85 5C-30-82-50-20-85
...
[NEW] Device 5D:B7:24:BB:39:B4 5D-B7-24-BB-39-B4    ← same device, new address

info on it shows Apple manufacturer data, a (random) address type, and no keyboard class:

Device 5D:B7:24:BB:39:B4 (random)
        ManufacturerData.Key: 0x004c (76)

Those are the keyboard’s “I belong to a Mac” beacons. Pairing attempts against them fail with org.bluez.Error.AuthenticationFailed. A keyboard that's actually ready to pair shows up with a stable (public) address.

Step 2 — Remove the stale pairing

$ bluetoothctl remove 88:4D:7C:E7:91:45
Device has been removed

Colons in the MAC, not dashes — bluetoothctl won't recognize 88-4D-7C-E7-91-45. If you don't know the address, bluetoothctl devices lists what BlueZ has stored; the keyboard is usually still in there from better days.

Step 3 — Pair with an agent (the step everyone gets wrong)

Don’t just run pair — register an agent first, inside an interactive bluetoothctl session:

$ bluetoothctl
[bluetoothctl]> agent KeyboardDisplay
Agent registered
[bluetoothctl]> default-agent
Default agent request successful
[bluetoothctl]> scan on

Now the physical ritual: unplug the cable, switch the keyboard off, wait five seconds, switch it on. Freshly orphaned and power-cycled, it advertises under its real (public) address:

[NEW] Device 88:4D:7C:E7:91:45 88-4D-7C-E7-91-45

Pair it quickly — the pairable window is short:

[bluetoothctl]> pair 88:4D:7C:E7:91:45
Attempting to pair with 88:4D:7C:E7:91:45
Request confirmation
[agent] Confirm passkey 652146 (yes/no): yes
[CHG] Device 88:4D:7C:E7:91:45 Bonded: yes
Pairing successful

The Confirm passkey prompt is why the agent matters. Answering it upgrades the pairing to an authenticated bond — the Bonded: yes line. Without an agent, BlueZ falls back to unauthenticated "Just Works" pairing, and the keyboard, which requires authentication before acting as an input device, drops the link seconds later and takes the pairing with it:

[SIGNAL] BREDR.Disconnected - org.bluez.Reason.Remote, Connection terminated by remote user
[CHG] Device 88:4D:7C:E7:91:45 Paired: no

Reason.Remote disconnects and evaporating pairings mean the keyboard is hanging up on you: back to the top of this step.

Two practical notes:

• No working keyboard to type pair and yes with? Pre-type the commands in a text editor before unplugging, then select each line — including its trailing newline — and middle-click-paste it into the terminal; the paste executes in one click. Or borrow any USB keyboard for five minutes.
• Instead of a yes/no confirmation, you may get a passkey to enter. Type it on the Magic Keyboard and press Enter — on the Magic Keyboard. This works even though it isn’t connected yet; passkey entry is part of the pairing protocol itself.

Step 4 — Trust, connect, verify

[bluetoothctl]> trust 88:4D:7C:E7:91:45
[bluetoothctl]> connect 88:4D:7C:E7:91:45
Connection successful
[bluetoothctl]> info 88:4D:7C:E7:91:45

trust restores automatic reconnect after power cycles. In the info output, one line decides everything:

Paired: yes
        Bonded: yes      ← this one
        Trusted: yes
        Connected: yes

Paired and bonded are not synonyms — pairing establishes an encrypted session, bonding stores authenticated long-term keys, and the Magic Keyboard insists on the latter. Every failed state I hit had Bonded: no in it, and I looked straight past it for hours.

Then type something. My confirmation was a proud aaaaaaaaaaaa landing in the terminal mid-command, over the air. Flip the switch off/on once as a final test — it should reconnect by itself within seconds.

Closing remark

Nothing here was broken. Apple’s address randomization and the keyboard’s authentication requirement are security mechanisms doing their jobs — and their combined effect is a keyboard that pairs, reports as connected, and types nothing, while every status readout tells you something technically true and practically useless. Debug from journalctl -u bluetooth -f and bluetoothctl info, not from the GUI; GNOME's panel hides nameless devices and cheerfully reports "connected" for links that carry no input.

I’m fairly sure I solved a version of this a year ago and left no notes. This post is the notes.