The "Allow USB debugging" prompt that appears the first time you connect a phone to a new computer isn't just a yes/no toggle — it's approving an RSA public key that your machine generated and is now presenting to the device. Understanding where that key lives and how the approval actually works explains a handful of ADB behaviors that otherwise look like bugs: why you get re-prompted after a factory reset, why a cloned VM suddenly loses authorization, and why CI machines need a different setup than a laptop.
The first time adb runs on a machine, it generates an RSA key pair and stores it locally — the private key in adbkey and the public key in adbkey.pub, both inside ~/.android on macOS and Linux or %USERPROFILE%\.android on Windows. When you connect a device, adb sends the public key and asks the device to confirm the connection. Tapping "Always allow from this computer" on the on-device dialog stores that public key in the device's own trusted-keys list; every future connection from a machine holding the matching private key is then auto-approved without a prompt.
~/.android was deleted, reinstalled, or you're on a fresh OS profile, adb generates a brand new key pair, which the device has never seen and therefore doesn't recognize, regardless of how many times you'd approved the old one.adbkey in it, every clone shares the identical private key, and devices that trusted the original VM will silently trust every clone too — usually not what you want for isolated test environments. Regenerate the key pair on each clone by deleting ~/.android/adbkey and adbkey.pub and letting adb create fresh ones on next launch.A device listed as unauthorized in adb devices means the key exchange happened but hasn't been approved yet — check the phone screen for the confirmation dialog, which sometimes appears behind other windows or gets missed. That's a distinct situation from a key that was once approved and later became invalid; the fix for the general unauthorized case is covered in the adb unauthorized troubleshooting guide, while this article focuses on the key management underneath it.
Android doesn't offer a way to revoke a single computer's key individually from the device side — Developer Options only has a blanket "Revoke USB debugging authorizations" that clears every trusted key at once. If you need to deauthorize one machine while keeping others trusted, the practical approach is revoking all of them on the device, then re-approving only the machines you still want, one at a time.
For lab benches, CI runners, or any setup with many devices and a need to skip interactive approval entirely, adb supports pre-authorizing keys via the ADB_VENDOR_KEYS environment variable. Set it to a directory containing one or more .pub key files, and any device that already trusts one of those keys (or is factory-provisioned to trust them, which is how OEM factory test stations work) connects without a prompt. This doesn't bypass the requirement that a device must have that public key in its trusted list at some point — it just lets a build server present a stable, known key instead of a fresh one generated per container, which matters because a freshly built CI container normally has no ~/.android directory and would otherwise re-trigger the approval prompt on every job.
Back up adbkey/adbkey.pub from a machine whose key is already trusted on many devices before reinstalling that OS, so you can restore the same identity instead of re-approving every device by hand. Conversely, treat a leaked or shared private key as a real access-control issue on devices where USB debugging stays enabled long-term — anyone with that private key and physical or network access to the device's ADB port inherits the same trusted access.
Reference: Android Debug Bridge (adb) documentation.