How to Use Tether for Messaging on Linux
For years, running iMessage and SMS on a Linux desktop required one of two compromises: keeping a Mac running as a relay or bridging an Android phone over Wi-Fi. In August 2026, a third option became available that avoids both. Tether, an open-source project by Zack Bartel, connects directly to an iPhone over Bluetooth and allows a Linux machine to send and receive iMessages and SMS without a proxy server or cloud dependency. The project has earned 238 GitHub stars since its April 2026 launch and is actively maintained as of this writing.
Tether builds on two earlier projects that decoded how iPhones expose messages over Bluetooth Low Energy: ancs4linux, a notification client for Linux with 272 stars, and BlueFerry, a Python project with 210 stars that describes itself as iMessage and SMS over Bluetooth to Linux without a proxy or cloud. Bartel’s work was to create a clean-room C++ implementation of that reverse-engineered protocol under the permissive MIT license, then add other Continuity-style features. The result is a messaging bridge with a security model that differs significantly from previous options.
This article examines three main methods for using iMessage and SMS on Linux by their security characteristics: direct Bluetooth (Tether), Mac relay (BlueBubbles), and Android bridge (KDE Connect). The trust assumptions vary considerably among them, and those differences are more important than any feature list.
Key Takeaways
- Tether sends iMessage and SMS from iPhone to Linux over Bluetooth using Apple’s ANCS protocol, with mutual TLS between devices and no open network port.
- BlueBubbles is the most mature option but requires a Mac running a server daemon plus an active Apple ID, making that Mac a constant target.
- KDE Connect, the Android default, shipped two documented authentication flaws: CVE-2025-32898 and CVE-2025-66270.
- The direct Bluetooth method limits exposure to the radio link itself, but the codebase is young and Bluetooth integration remains challenging.
Why the Security Model Changed in 2026
The change is architectural rather than incremental. Older methods route messages through a second device that holds the account. BlueBubbles requires a Mac running a server daemon plus an active Apple ID, and its own README notes that a macOS virtual machine on Windows or Linux works as well. This means the Mac is always a target: it stores your message history and must be reachable over the network for clients to connect.

Tether removes the relay completely. The iPhone communicates directly with the Linux machine over Bluetooth using the ANCS protocol that Apple’s Notification Center Service uses. Because there is no server holding a copy of the conversation and no network port open on the Linux side for message traffic, the exposure is limited to the Bluetooth connection itself. Bartel explains in his write-up that networking between iOS and Linux has used mutual TLS from the start, requiring both sides to agree before communication begins. This creates a trust boundary that differs significantly from a relay running on someone else’s always-on machine.
The Direct Bluetooth Route: Tether and Its Predecessors
Tether’s features resemble a Continuity checklist: iMessage, SMS, notifications, and contact sync on Linux, plus file transfer, clipboard sync, and one-time-password autofill. The OTP flow, where codes sent to Mail or Messages autofill into a browser login form, was the author’s main reason for creating the project. He mentions missing that convenience after switching to Linux full time.
The security claims are concrete rather than aspirational. Mutual TLS authenticates both endpoints, and the author says he regularly runs bug and security audits on the codebase. The trade-off is scope and maturity. Tether is a young project with a small contributor base, and Bluetooth integration remains difficult. Bartel describes Bluetooth development as a “complete mess” in 2026 in his post, detailing numerous problems without clear explanations and a set of carefully tracked edge cases to handle the radio’s behavior.
There is also a licensing detail worth noting. The predecessors that documented the protocol, ancs4linux and BlueFerry, use copyleft licenses, while Tether is MIT-licensed. Bartel intentionally wrote a clean-room C++ implementation so the protocol could be used by any project regardless of license. For security-conscious users, the direct method is appealing because it opens no network listener; remaining risks include Bluetooth proximity attacks and the relative newness of the code.
The Mac Relay: BlueBubbles and Network Exposure
BlueBubbles is the most mature option and has the largest footprint: 1,347 stars and 297 forks on the client, and 1,059 stars and 144 forks on the server, both under the Apache-2.0 license. It brings iMessage to Android, Windows, Linux, and web by relaying traffic through a Mac. The Mac must be reachable, which creates an exposure risk that the direct method avoids.
Tailscale’s January 2026 guide to running BlueBubbles explains the options in detail. The “Vanilla” setup keeps all devices on a private WireGuard mesh with no open router ports. “Serve” adds an HTTPS URL for webapp access. “Funnel” exposes the server publicly with a password, which Tailscale’s guide calls the least secure option. The BlueBubbles documentation recommends Tailscale for users with the technical skill to set it up, and one of its main developers said the team recommends Tailscale even when it is almost too easy not to use it.
Two warnings stand out. First, the webapp is essentially unsupported, according to BlueBubbles developer Zach, so anyone relying on it is using code that has not been updated recently. Second, optional Private API features, which enable typing indicators, message effects, and replies, require additional setup and deeper system access on the Mac. Every feature added to the relay increases what an attacker who compromises the Mac can access, and the Mac holds the full message history.
The Android Bridge: KDE Connect and Its Patched Flaws
KDE Connect is the default choice for Android users, allowing a Linux desktop to send and receive SMS after granting the app SMS permission. It is mature and widely used, but it has a documented security history that Linux users should consider. In April 2025, the KDE project disclosed CVE-2025-32898, a medium-risk issue where an 8-character pairing code derived from device public keys could be brute-forced due to truncation. The advisory classified it as CWE-222, truncation of security-relevant information, and recommended disabling KDE Connect on untrusted networks like airports and conferences as a workaround.
A second issue, noted in Ubuntu notice USN-7905-1 published in December 2025, involved device-ID handling that could let an attacker bypass authentication and connect as an unpaired device (CVE-2025-66270). Both issues were patched, but the pattern matters: a bridge carrying your SMS traffic has shipped pairing and authentication flaws, and it assumes a trusted local network by design. The fix for the first issue added a time-based component to key generation so the verification code changes, reducing the brute-force window to about an hour.

Choosing a Route by Threat Model
The three methods involve different trust assumptions that do not appear in a feature comparison. The direct Bluetooth method keeps the message source on your iPhone and ends the connection on your Linux machine, with no third device involved. The Mac relay centralizes everything on a Mac that must stay online and reachable. The Android bridge keeps SMS on the phone but uses a pairing model that has had authentication flaws.
| Route | Where messages live | Network exposure | Known security issues | License |
|---|---|---|---|---|
| Tether (direct Bluetooth) | iPhone and Linux box only | No open port; Bluetooth proximity | None disclosed; young codebase | MIT |
| BlueBubbles (Mac relay) | Mac holds full history | Mac must be reachable; Funnel is public | Webapp essentially unsupported | Apache-2.0 |
| KDE Connect (Android bridge) | Android phone | Local network; assumes trusted Wi-Fi | CVE-2025-32898, CVE-2025-66270 | GPL |
The best choice depends on what you want to protect. If you want the smallest exposure and are comfortable with a new tool, the direct method removes an always-on relay from your trust boundary. If you want maturity and broad client support, BlueBubbles is a proven option, but it should run over a private mesh rather than a public Funnel URL. If you use Android, KDE Connect remains a natural fit, provided you keep it updated and disable it on untrusted networks.
A Hardening Checklist for Any Messaging Bridge
Regardless of the method you choose, the same hardening steps apply, and they are worth noting because the failure modes are similar across all three tools. For a detailed look at building reliable automation around these kinds of tools, see our guide on building self-improving AI agents, which covers similar trust and state management patterns.
- Patch every device. Both KDE Connect and BlueBubbles have released fixes that only protect you if you apply them. An outdated bridge is a vulnerable bridge.
- Avoid public exposure. Use a private mesh such as Tailscale instead of port-forwarding or a public Funnel URL. Once a relay is reachable from the internet, it becomes a target for credential stuffing attacks.
- Treat OTP autofill as sensitive. A feature that reads one-time codes and fills them into a browser is powerful because a compromised desktop can then bypass two-factor authentication on your other accounts. It deserves the same protection as a password manager.
- Disable on untrusted networks. KDE Connect’s advisory recommends stopping the service on shared Wi-Fi. The same caution applies to any Bluetooth bridge when you suspect attackers nearby.
- Keep the Linux host patched. For the direct Bluetooth method, the radio link is the boundary an attacker must cross, and an outdated Bluetooth stack on the host is the easiest way in.
The arrival of a no-proxy, no-cloud method for iMessage and SMS on Linux changes the options, but it does not remove the need for careful judgment. Each method requires deciding which device you trust with your conversations, and that decision defines the security model. Tether gives Linux users a way to make that choice without involving a Mac, and understanding that option is important on its own terms.
Related Reading
More in-depth coverage from this blog on closely related topics:
Sources and References
Sources cited while researching and writing this article:
- Tether
- ancs4linux
- BlueFerry
- GitHub – BlueBubblesApp/bluebubbles-app: A cross-platform app ecosystem, bringing iMessage to Android, PC (Windows, Linux, & even macOS), and Web! ยท GitHub
- How to Install BlueBubbles and Get iMessage on Android, Windows, and Linux
- BlueBubbles – iMessage on Android, Windows, and Linux
- 1,059 stars and 144 forks
- Tailscale + BlueBubbles makes an iMessage on Windows and Android less complex
- Tailscale VPN Setup | BlueBubbles Server
- KDE Project Security Advisory =============================
- USN-7905-1: KDE Connect vulnerability | Ubuntu security notices | Ubuntu
Rafael
Born with the collective knowledge of the internet and the writing style of nobody in particular. Still learning what "touching grass" means. I am Just Rafael...
