Telnet on macOS for EVE-NG: What Actually Works

Key Takeaways

Do not disable SIP, and do not copy binaries into /usr/bin. Every guide that tells you to is written for macOS 10.13. Since Catalina the system volume is a sealed, read-only snapshot — the copy cannot succeed even with SIP off.
brew install telnet is the whole fix for the missing binary. It builds Apple’s own telnet source, which is what was removed in the first place.
A working telnet binary still won’t make EVE-NG’s console links work. That is a separate problem: nothing on a stock Mac is registered to handle telnet:// URLs.
The HTML5 console avoids the entire issue. No local client, no URL handler, nothing to reinstall after an OS upgrade.
Telnet is cleartext. Fine to a lab node over a private network, never across anything you don’t own.

EVE-NG is a browser-driven network emulator that boots real vendor images as virtual machines, and it offers device consoles as clickable links, which is where this whole problem starts.

System Integrity Protection (SIP) is the macOS security feature that makes system directories and system-owned processes unmodifiable even by root, and since Catalina it is backed by a cryptographically sealed, read-only system volume. That combination is why the old advice in this post could not work regardless of how many security features you were willing to switch off.

This post has been rewritten. The version that sat here from 2019 was a copy of someone else’s article, and its instructions — disable System Integrity Protection, drop telnet and ftp into /usr/bin, re-enable SIP — stopped being possible on macOS several releases ago. Following them today means disabling a security feature for a copy operation that will fail anyway.

Two problems, not one

Clicking a node in EVE-NG and getting nothing looks like a single fault. It is two, and they need different fixes:

There is no telnet binary. Apple removed the telnet and ftp clients in macOS High Sierra (10.13) in 2017 and they have not come back.
Nothing handles telnet:// URLs. A URL scheme handler is the registration that tells the operating system which application should open a given link prefix, and macOS ships none for telnet://. EVE-NG’s web interface opens such a link and hands it to macOS, which looks for a registered handler and finds none. Installing the binary does not register anything.

Fix only the first and the command line works while the clickable interface still does nothing — which is precisely the state the old article’s readers ended up in.

Why the old recipe cannot work

System Integrity Protection has always protected /usr/bin. On High Sierra you could turn SIP off from Recovery, write there, and turn it back on, which is what those guides describe.

macOS Catalina (10.15) changed the shape of the problem. The operating system now lives on a separate volume that is cryptographically sealed — a Signed System Volume — and mounted read-only. It is not a permissions check that SIP relaxes; the volume’s contents are verified against a signature. Writing into /usr/bin is not a matter of having enough privilege any more.

Apple’s guidance on this predates the change and is still the right answer: third-party tools go in /usr/local. Installing there was never restricted, which is why the workaround was always unnecessary.

Getting the binary back

Homebrew packages the telnet client from Apple’s own open-source release — the same code that used to ship with macOS:

brew install telnet

Confirm where it landed:

$ which telnet
/opt/homebrew/bin/telnet

On Apple Silicon that is /opt/homebrew/bin; on Intel Macs it is /usr/local/bin. Both are on the default PATH, so nothing else is needed. If which comes back empty, your shell’s PATH is missing the Homebrew prefix — fix that rather than moving the binary.

You can now telnet to a node from a terminal, given the port EVE-NG assigned it:

telnet 192.168.1.50 32769

For many people that is enough, and it is the most robust option — nothing to break on the next macOS upgrade.

Making the console links clickable

If you want the web interface to work the way it does on Windows, something has to claim the telnet:// scheme.

Option 1 — the HTML5 console

Worth trying first, because it removes the requirement entirely. EVE-NG can run consoles in the browser over Guacamole, with no local client and no URL handler involved. Switch the lab’s console type to HTML5 in the lab settings and the node opens in a browser tab.

The trade-offs are the ones you would expect from a browser terminal: copy and paste behaves differently, and a slow link feels worse than a native client. But it survives OS upgrades, it works from a machine that is not yours, and it is the only option here with no local setup at all.

Option 2 — a terminal that registers the scheme

iTerm2 will claim telnet:// for you. In Settings → Profiles → General, tick telnet in the URL schemes list, and confirm when macOS asks whether to change the default handler. Several commercial clients — SecureCRT, ZOC, Royal TSX — register themselves the same way during installation.

To check or force which application owns the scheme, duti queries LaunchServices directly:

brew install duti
duti -x telnet

That prints the application currently registered for telnet://. An empty result is the stock state, and is exactly why nothing happens when you click a node.

Option 3 — roll your own handler

If you would rather not install a terminal you don’t otherwise want, a few lines of AppleScript will do it. Open Script Editor, save as an Application, and add telnet to its CFBundleURLTypes in Info.plist:

on open location this_URL
    set hostAndPort to text ((offset of "//" in this_URL) + 2) thru -1 of this_URL
    set AppleScript's text item delimiters to ":"
    set h to text item 1 of hostAndPort
    set p to text item 2 of hostAndPort
    tell application "Terminal"
        activate
        do script "telnet " & h & " " & p
    end tell
end open location

It is more moving parts than the other two options, and it is the one most likely to need attention after a macOS update. Reach for it only if options 1 and 2 are both unavailable.

One thing worth saying about telnet

Telnet sends everything, including the enable password, as cleartext. On a lab network on your own machine that is an acceptable trade for convenience, and it is what EVE-NG’s console ports speak.

It should not follow you out of the lab. If you find yourself installing a telnet client to reach production kit, that is the finding — not the missing binary. Anything reachable over telnet from a management network is a configuration to fix rather than a client to reinstall.

Sources

Apple — About System Integrity Protection on your Mac, on what SIP protects and why /usr/local is the supported location for third-party tools
Apple — About the read-only system volume in macOS Catalina or later
Homebrew — telnet formula, built from Apple’s open-source release
EVE-NG — Use HTML5 and native console