How To Install AnyDesk on Kali Linux

Two things go wrong when people put AnyDesk on Kali. The install itself is three commands and almost never fails. What fails is everything after: anydesk --get-id prints an empty line, anydesk --set-password reports success while doing nothing, and the box sits there listening on port 7070 with no way to reach it.

Original content from computingforgeeks.com - post 51520

This guide installs AnyDesk on Kali Linux from the official AnyDesk apt repository, enables the systemd service, pulls the AnyDesk ID, sets an unattended access password, and locks down who can connect. It also explains the empty-ID behaviour, which is a permissions rule nobody documents, not a timing problem you wait out. AnyDesk publishes a single Linux build for the whole Debian family, so the install steps carry over to Debian and Ubuntu unchanged. Everything below was run on a fresh Kali Linux rolling install (kernel 7.1.5) with AnyDesk 8.0.4 in September 2026.

Prerequisites

• A Kali Linux host, desktop or headless. The install is identical on Debian and Ubuntu.
• A user with sudo rights.
• Outbound access to *.net.anydesk.com on TCP 80, 443 or 6568. AnyDesk needs at least one of the three and relays through it, so nothing needs port forwarding for a basic connection.
• About 43 MB of disk for the package itself. A minimal Debian without the GTK3 and X11 stack pulls considerably more.
• An Xorg session on the host if you want to connect into it. AnyDesk supports outgoing sessions only under Wayland and requires Xorg for incoming ones. Kali’s Xfce and LightDM combination is Xorg, so the default desktop is fine. On a Wayland desktop, log into an X11 session if your desktop still offers one. Recent GNOME releases have removed the X11 session entirely, in which case install an X11 desktop such as Xfce.

A graphical session is optional for the install itself but it changes how the CLI behaves, which is covered below. If you are provisioning the host from scratch, the Kali Linux installation walkthrough covers the base system.

Add the AnyDesk apt repository

AnyDesk signs its repository with its own GPG key. Put the dearmored key under /etc/apt/keyrings and reference it from the source file, which is the signed-by pattern current Debian and Kali releases expect:

sudo mkdir -p /etc/apt/keyrings
wget -qO- https://keys.anydesk.com/repos/DEB-GPG-KEY | sudo gpg --dearmor -o /etc/apt/keyrings/anydesk.gpg

The dearmored key lands at roughly 1.7 KB. Confirm it before adding the source, because an empty keyring is the usual cause of the signature error later:

ls -l /etc/apt/keyrings/anydesk.gpg

A healthy key looks like this:

-rw-r--r-- 1 root root 1759 Sep 17 13:11 /etc/apt/keyrings/anydesk.gpg

Now register the repository. AnyDesk ships one suite called all for every Debian-family release, so there is no codename to substitute and nothing to change when Kali rolls forward:

echo "deb [signed-by=/etc/apt/keyrings/anydesk.gpg] https://deb.anydesk.com/ all main" | sudo tee /etc/apt/sources.list.d/anydesk-stable.list

Refresh the package lists so apt picks up the new source:

sudo apt update

The AnyDesk lines should appear among the rest with no warnings attached:

Get:2 https://deb.anydesk.com all InRelease [7,386 B]
Get:3 https://deb.anydesk.com all/main amd64 Packages [613 B]
Get:4 https://deb.anydesk.com all/main amd64 Contents (deb) [254 B]

Install AnyDesk from the repo

Check what the repository is actually offering before installing. This is also the fastest way to confirm the source is wired up correctly:

apt-cache policy anydesk

One candidate comes from deb.anydesk.com, and nothing from Kali’s own repos competes with it:

anydesk:
  Installed: (none)
  Candidate: 8.0.4
  Version table:
     8.0.4 500
        500 https://deb.anydesk.com all/main amd64 Packages

Install it:

sudo apt install -y anydesk

The package pulls about 16 MB and wires up the systemd unit during setup. One line in the output looks alarming and is not:

Preparing to unpack .../anydesk_8.0.4_amd64.deb...
Failed to stop anydesk.service: Unit anydesk.service not loaded.
Unpacking anydesk (8.0.4)...
Setting up anydesk (8.0.4)...
Created symlink '/etc/systemd/system/multi-user.target.wants/anydesk.service' -> '/etc/systemd/system/anydesk.service'.

That Failed to stop anydesk.service is the maintainer script trying to stop a service that does not exist yet on a first install. It is harmless on a clean box and disappears on upgrades.

Verify the service and pull the AnyDesk ID

The unit is enabled and started automatically. Confirm both states:

systemctl is-active anydesk
systemctl is-enabled anydesk

Both answers should be affirmative, meaning the daemon survives a reboot:

active
enabled

Every AnyDesk host gets a numeric address that remote clients dial. Pull it with sudo, and read the next section before you drop the sudo:

sudo anydesk --get-id

A ten digit address comes back, and it stays the same across reboots as long as /etc/anydesk/ survives:

1928424441

Here is the version, the ID, the service state and the listening socket on our test box. These were run from a terminal inside the Kali desktop session, which is why the unprivileged form works there:

With an ID in hand the host is reachable, and the next question is what happens when you run those same commands without elevation.

Why anydesk –get-id prints nothing

Run anydesk --get-id as your normal user over SSH and you get an empty line and exit status 1. Most guides blame this on the daemon not having registered yet and tell you to wait. That is wrong. Waiting changes nothing, and the daemon is already registered.

The AnyDesk client refuses to run when the user invoking it is not the user who owns the active graphical session. The reason is in its own trace file at ~/.anydesk/anydesk.trace:

explode  app.common_path - The logged in user differs from the (non-root) user this process runs as. Process UID: 1000 , logged in UID: 106

UID 106 is lightdm, sitting on the login greeter. UID 1000 is the account on the SSH session. They do not match, so the client aborts with a backtrace and prints nothing to the terminal. The same thing happens on a fully headless box with no display manager running at all.

The rule that comes out of testing all three states:

• Headless, or nobody logged into the desktop: run the AnyDesk CLI as root. sudo anydesk --get-id works in every case.
• Logged into the Kali desktop as that user: plain anydesk --get-id works, with or without DISPLAY set.
• SSH’d in as a different user than the one at the desktop: it fails, and always will. Use sudo.

Scripts that provision Kali boxes should always use sudo anydesk --get-id, because the unprivileged form works only by accident of who happens to be sitting at the screen.

Set an unattended access password

Without a stored password, every incoming connection waits for a human at the Kali end to click Accept, which defeats remote access on a lab or headless box. Set one:

echo "Str0ngLabPass#2026" | sudo anydesk --set-password

This command has a trap worth knowing about. Run it without sudo and it prints a refusal but still exits 0, so any script checking the exit code concludes it worked:

Setting the password requires administrator privileges and an installed service. 1 / 1000

Never trust the exit code here. Check that the hash actually landed in the service config instead:

sudo grep -oE '^ad\.anynet\.(pwd_hash|pwd_salt)' /etc/anydesk/service.conf

Two keys appear once the password is genuinely stored, and neither exists before:

ad.anynet.pwd_hash
ad.anynet.pwd_salt

Rotating the password later is the same command with a new value. The old hash and salt are replaced in service.conf straight away, so verify with the same grep after every rotation.

Control who can connect from the AnyDesk GUI

On a Kali desktop the client itself carries settings the CLI does not expose, including the access control list. Launch it from the applications menu or run anydesk in a terminal inside the desktop session. The main window shows the host’s own address under “Your Address”:

The hamburger menu at the top right opens Settings, where the General page holds language and capture paths:

The page that matters for security is Security, then Access. Note the red Unlock button at the top: every control below it is greyed out until you click it and authenticate through polkit. People routinely assume the settings are broken when they are simply locked.

Three settings on that page decide how exposed the box is. Interactive Access chooses whether incoming requests are shown at all, and “Never show incoming session requests” is the right pick for an unattended lab box where nobody can click Accept. Unattended Access is where two factor authentication lives, which is worth enabling on anything reachable from outside the LAN. Access Control List is where you list the AnyDesk addresses allowed to connect, and it is the tightest control on the page by design: a box configured to accept only your own workstation’s address gives nothing to somebody dialling IDs at random. We configured these settings but did not exercise them against a second client, so treat the behaviour as what the setting declares rather than as something measured here.

Open the firewall for direct connections

The relay path over outbound 443 works through almost any firewall with no inbound rule at all. Direct LAN connections are faster because packets skip AnyDesk’s network, and those need TCP 7070 open. The daemon listens on it regardless:

sudo ss -tlnp | grep anydesk

Sockets are bound on both address families:

LISTEN 0  10  0.0.0.0:7070  0.0.0.0:*  users:(("anydesk",pid=1191,fd=73))
LISTEN 0  10     [::]:7070     [::]:*  users:(("anydesk",pid=1191,fd=74))

Before writing any rule, understand what Kali actually ships. There is no firewall running and no ufw binary at all, which catches out anyone copying firewall steps from an Ubuntu guide. Confirm it for yourself:

sudo nft list ruleset
command -v ufw || echo "ufw not installed"

On a stock Kali install the ruleset prints nothing and the lookup fails, meaning every port the daemon opens is already reachable from the whole network:

ufw not installed

Install ufw and scope the rule to the networks you trust rather than opening it to the internet. The allow OpenSSH line is not optional if you administer this box remotely, because ufw enable sets a default deny on inbound traffic and will otherwise lock you out on the next connection:

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow from 10.0.0.0/8 to any port 7070 proto tcp comment 'AnyDesk direct LAN'
sudo ufw enable

We left the SSH rule out on the first run of this lab. The session already open survived, because conntrack keeps established sockets alive, and that is exactly what makes the mistake easy to miss: nothing appears broken until you reconnect or reboot, at which point the box is gone. The enable step also prompts for confirmation when it detects an SSH session, and answering y is safe once the OpenSSH rule is in place. Check what landed:

sudo ufw status

The AnyDesk rule appears with the comment attached, alongside the SSH rule that keeps you connected:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
7070/tcp                   ALLOW       10.0.0.0/8                 # AnyDesk direct LAN
OpenSSH (v6)               ALLOW       Anywhere (v6)

That rule covers connections where you dial the ID directly. AnyDesk also has a discovery feature that finds other clients on the same segment, and it uses UDP 50001 to 50003 against multicast 239.255.102.18. Add sudo ufw allow from 10.0.0.0/8 to any port 50001:50003 proto udp if you want discovery, and skip it otherwise.

Skipping ufw and appending a single ACCEPT rule with iptables is the common shortcut, and on Kali it accomplishes nothing. The INPUT chain policy is already ACCEPT and the ruleset is empty, so allowing 7070 from one subnet leaves it open to every other subnet too. What restricts the port is the default deny that ufw enable installs. If you want to stay on nftables directly, the rule has to drop the traffic you do not want rather than accept the traffic you do:

sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0; policy accept; }'
sudo nft add rule inet filter input tcp dport 7070 ip saddr 10.0.0.0/8 accept
sudo nft add rule inet filter input tcp dport 7070 drop

The order matters and so does the shape. Writing this as a single ip saddr != 10.0.0.0/8 drop rule looks equivalent and is not: ip saddr is an IPv4 expression, so an IPv6 packet never matches it, falls through to the accept policy and reaches the port anyway. That is not theoretical, because the ss output above shows AnyDesk bound to [::]:7070 as well. We tested both forms against the daemon and the single-rule version left IPv6 open while the accept-then-drop pair closed both:

BAD rule: ip saddr != 10.0.0.0/8 drop
  v4 127.0.0.1 -> blocked
  v6 ::1       -> OPEN

GOOD rule: accept 10.0.0.0/8 then unqualified drop
  v4 127.0.0.1 -> blocked
  v6 ::1       -> blocked

One more difference from the ufw path: nft add only touches the running ruleset, so a reboot wipes it and reopens the port. Persist it:

sudo nft list ruleset | sudo tee /etc/nftables.conf
sudo systemctl enable --now nftables

Connecting only through the relay needs no inbound rule at all, which is the simplest position of the three.

Install without the apt repo

Lab and pentest networks often block third party repositories outright. In that case fetch the package on a machine that can reach AnyDesk and carry it across. Resolve the current filename from the repository index rather than hardcoding a version, because AnyDesk removes older builds from its download directory and a pinned URL eventually 404s:

ANYDESK_DEB=$(curl -fsSL https://deb.anydesk.com/dists/all/main/binary-amd64/Packages | awk -F': ' '/^Filename/{print $2}')
echo "https://deb.anydesk.com/${ANYDESK_DEB}"
wget "https://deb.anydesk.com/${ANYDESK_DEB}"

The echo prints the exact URL that was resolved, which is what you would copy to the offline host:

https://deb.anydesk.com/pool/main/a/anydesk/anydesk_8.0.4_amd64.deb

Copy the file to the isolated host and install it there with apt rather than dpkg -i, so the GTK3, Cairo and X11 dependencies resolve from Kali’s own repositories. Stage it in /tmp rather than a home directory, which avoids the unsandboxed-download warning apt emits when _apt cannot read the path:

scp anydesk_*_amd64.deb [email protected]:/tmp/
ssh [email protected] 'sudo apt install -y /tmp/anydesk_*_amd64.deb'

You end up with the same binary and the same systemd unit, minus automatic updates. That is fine for a box that lives a few weeks. For a long lived Kali workstation use the repository instead.

Uninstall AnyDesk

Stop the service and purge the package, which also removes /etc/anydesk/ along with the stored ID and password hash:

sudo systemctl disable --now anydesk
sudo apt remove --purge -y anydesk
sudo apt autoremove -y

Drop the repository and its key too if you are not reinstalling:

sudo rm -f /etc/apt/sources.list.d/anydesk-stable.list /etc/apt/keyrings/anydesk.gpg
sudo apt update

Purging destroys the ID. A rebuilt host gets a new one, so anything referencing the old address needs updating. One directory is left behind: ~/.anydesk/ keeps the per-user GUI config, the connection history and the trace file, and apt never touches it. Remove it by hand with rm -rf ~/.anydesk if you are handing the machine on.

Troubleshooting

anydesk –get-id prints an empty line and exits 1

The user running the command does not own the active graphical session. Run it as sudo anydesk --get-id. This is a permissions check inside the client, not a registration delay, and it is covered in full above.

Setting the password requires administrator privileges and an installed service

You ran anydesk --set-password without sudo. The command still exits 0, so re-run it with sudo and verify with the grep on /etc/anydesk/service.conf rather than trusting the exit status.

apt update reports NO_PUBKEY or a signature error

The keyring is missing or zero bytes. Check ls -l /etc/apt/keyrings/anydesk.gpg reports roughly 1.7 KB and re-run the wget and gpg --dearmor pipeline if it does not. Then confirm the source file points at that exact path with grep signed-by /etc/apt/sources.list.d/anydesk-stable.list.

Failed to stop anydesk.service: Unit anydesk.service not loaded

Expected on a first install. The package’s pre-install script tries to stop a unit that does not exist yet. Nothing is broken and the service starts normally afterwards.

Black screen after connecting

Two causes, and they need different fixes. AnyDesk captures an Xorg session, so a headless box has nothing to send and the client draws an empty frame even though the connection itself succeeded. Install a desktop with sudo apt install -y kali-desktop-xfce, and note that a display manager on its own only gets you the login greeter: somebody has to actually log in, or you enable autologin, before there is a session to capture. The second cause is Wayland, where AnyDesk supports outgoing sessions only. If the host runs a Wayland desktop, switch to an X11 session where one is still offered, and install an X11 desktop such as Xfce where it is not.

Connection times out

The client cannot reach AnyDesk’s relay. Test the bootstrap host, which is the one that actually resolves, because bare net.anydesk.com has no A record and will always look broken:

curl -sI https://boot.net.anydesk.com/

A reachable relay answers with a redirect and identifies itself in the server header:

HTTP/1.1 303 See Other
access-control-allow-origin: *
content-length: 0
location: https://anydesk.com/
server: anydesk

If that fails, the filter needs *.net.anydesk.com allowed on at least one of TCP 80, 443 or 6568. Two machines on the same LAN can skip the relay entirely and use the direct path on 7070.

Hardening AnyDesk on an exposed Kali box

A Kali host running AnyDesk unattended is an attractive target, and the defaults are tuned for convenience rather than safety. Four changes matter in roughly this order.

Start with the access control list in Settings, then Access. Restricting inbound connections to your own AnyDesk addresses removes the entire class of attack where somebody dials IDs looking for an open desk, and it costs nothing. Enable two factor authentication on the same page next, because the unattended password is a single shared secret that ends up in provisioning scripts and chat logs.

Keep the unattended password out of the shell history that echo "..." | sudo anydesk --set-password writes into. Pull it from a password manager or an environment file that is not committed anywhere, and rotate it when people leave the project.

Finally, resist the urge to open 7070 to the world. If you genuinely need direct connections across the internet rather than through the relay, put the Kali box behind a WireGuard tunnel and allow 7070 only on the tunnel interface. For hosts where remote desktop is a convenience rather than a requirement, compare the alternatives in the roundup of open source remote desktop tools first, since Xrdp and Apache Guacamole keep the whole session inside your own network. Other Debian family hosts follow the identical process, covered in the Debian, Ubuntu and Linux Mint versions of this guide, and if you are still building out the Kali box, Metasploit Framework and Wine are the usual next installs.