How to remove SSH completely from my system?
Also are these vulnerabilities only happening when you have SSH connection?
I have sshfs, Avahi ssh server browser, ksshaskpass, lib32-libssh2 and libssh2.
Apparently that Avahi server browser is probably not recommended to uninstall at least.
Also seems that libssh2 cannot be uninstalled cause curl depends on it.
Better is not to, because it would break a whole lot of stuff.
You are only vulnerable if you allow incomingssh connections, and thus, if you have sshd running, and you allow such incoming connections from everywhere, which you would probably only want if you are running an internet-facing server. On a desktop workstation, you should either way always limit incoming ssh connections to your local LAN, and on a laptop you shouldn’t even have sshd enabled.
Also, in light of all the above, and just so as to avoid confusion, please note that there is a difference between connecting to a server via ssh and allowing a remote connection into your own machine via ssh. The latter requires that you’d be running sshd, which in this case, I would advise you to disable if you haven’t set it up properly.
No, on the contrary, Manjaro’s libssh2 is also affected. The -1 suffix to the package version simply means that it’s the first-packaged version.
Alternatively, you could firewall that port off to everyone else.
As mentioned, there are some apps that may rely on this. And not just the sshd service actually running, maybe even just to generate keys. So uninstalling openssh may be a little extreme.
So this is basically making a couple minor tweaks to the default firewall config:
Modify the file, and change the contents to:
/etc/nfttables.conf
#!/usr/bin/nft -f
# IPv4/IPv6 Simple & Safe firewall ruleset.
# More examples in /usr/share/nftables/ and /usr/share/doc/nftables/examples/.
destroy table inet filter
table inet filter {
chain input {
type filter hook input priority filter
policy drop
ct state invalid drop comment "early drop of invalid connections"
ct state {established, related} accept comment "allow tracked connections"
iif lo accept comment "allow from loopback"
meta l4proto { icmp, icmpv6 } accept comment "allow icmp"
tcp dport ssh iif lo accept comment "allow SSH from localhost"
tcp dport ssh drop comment "block SSH from everywhere else"
pkttype host limit rate 5/second counter reject with icmpx type admin-prohibited
counter
}
chain forward {
type filter hook forward priority filter
policy drop
}
}
Then just run:
sudo systemctl enable --now nftables
The configuration may look complex, but I only did two things to the default: /etc/ntftables.conf
Changed this from:
tcp dport ssh accept comment "allow sshd"
To this:
tcp dport ssh iif lo accept comment "allow SSH from localhost"
tcp dport ssh drop comment "block SSH from everywhere else"
This is what I do, and it makes you safe from these types of vulnerabilities. An attacker can’t simply spoof an IP address to establish an SSH connection.
This assumes the rest of your LAN is trusted and that attacks won’t originate from within it.
Most of us need a way to communicate with other hosts on the LAN, so this is a reasonable compromise. If you don’t, by all means block SSH unless it comes from localhost (and ignore the rest). In this context, that’s effectively as safe as uninstalling SSH.
For LAN access, you would just add a line in the middle of:
If your LAN is 192.168.1.0/24.
You would add this line in the middle:
tcp dport ssh iif lo accept comment "allow SSH from localhost"
tcp dport ssh ip saddr 192.168.1.0/24 accept comment "allow SSH from LAN"
tcp dport ssh drop comment "block SSH from everywhere else"
Probably not relavent, but if you use IPv6 you would need another line in the middle. e.g.:
Actually this vulnerability doesn’t work that way. The openssh package is not affected. It’s safe to have a SSH server (as safe as it could be being an open port )
The affected package is libssh2, that it’s used by curl. So actually we are exposed if we connect with curl and as a client to a site that is under the control of a malignant actor. A modified SSH server can send malformed messages that can allow the remote execution of commands on the client.
The -1 part is the Archlinux release version and it means this is the first version the packager has made of this library with this version. So the library version is 1.11.1 and it is affected. You can also see from pacman -Qi libssh2 that the package build date is January 2025, so it’s before this vulnerability was discovered.
The library developers haven’t released yet a new version. They have fixed the vulnerability in the code, but it is up to distro maintainers to add the patch to the distro package. It seems that ArchLinux packager is just doing that and I can see that there is already a 1.11.1-3 version in core-testing branch of Arch.
The many vulnerabilities coming out under the stones causes unnecessary panic with most users.
I answered the question How to remove SSH completely?.
The above comment by @cfinnberg brought to my attention - that @NZXT did not ask the right question.
The right question should have been - How do I remove libssh2 completely?
Then the comment by @Aragorn would be correct because libssh2 is a required component for various other packages.
$ pamac info libssh2
Name : libssh2
Version : 1.11.1-1
Description : A library implementing the SSH2 protocol as defined by Internet Drafts
URL : https://www.libssh2.org/
Licenses : BSD
Repository : core
Installed Size : 498,1 kB
Groups : --
Depends On : openssl zlib
Optional Dependencies : --
Required By : curl forgejo-cli gitui lib32-libssh2 libgit2 libvirt mc nmap
Optional For : --
Provides : libssh2.so=1-64
Replaces : --
Conflicts With : --
Packager : Tobias Powalowski <tpowa@archlinux.org>
Build Date : ons 01 jan 2025 16:56:10 CET
Install Date : man 22 sep 2025 06:46:13 CEST
Install Reason : Installed as a dependency for another package
Validated By : Signature
Backup files : --
As can be seen from the package info
Required By : curl forgejo-cli gitui lib32-libssh2 libgit2 libvirt mc nmap
So if you are using any of the depending packages, you cannot remove it easily
$ sudo pacman -R libssh2 --print
error: failed to prepare transaction (could not satisfy dependencies)
:: removing libssh2 breaks dependency 'libssh2' required by curl
:: removing libssh2 breaks dependency 'libssh2.so=1-64' required by curl
:: removing libssh2 breaks dependency 'libssh2' required by forgejo-cli
:: removing libssh2 breaks dependency 'libssh2.so=1-64' required by forgejo-cli
:: removing libssh2 breaks dependency 'libssh2' required by gitui
:: removing libssh2 breaks dependency 'libssh2' required by lib32-libssh2
:: removing libssh2 breaks dependency 'libssh2' required by libgit2
:: removing libssh2 breaks dependency 'libssh2.so=1-64' required by libgit2
:: removing libssh2 breaks dependency 'libssh2' required by libvirt
:: removing libssh2 breaks dependency 'libssh2' required by mc
:: removing libssh2 breaks dependency 'libssh2' required by nmap
If sshd is inactive, that machine is not accepting SSH logins, so the UFW/nftables question is mostly separate from the libssh2 CVEs. I’d still remove the broad ‘22 LIMIT Anywhere’ rules if you don’t intentionally run sshd; keep only your LAN allow if you later enable it. For this libssh2 issue the practical desktop step is: update when Manjaro ships the patched package, and avoid using tools that fetch over ssh:// from untrusted servers until then.
I should have looked up this bug before replying first. I haven’t even read up on it yet, at the time of my posting about restricting network access.
Generally speaking, most SSH vulnerabilities do require network access to sshd. I think it’s safe to say upwards of 90+%.
The remaining <10% would be requiring things like:
Local privilege escalation
An existing unprivileged user account (more rare than the former, but happen more than you know)
The even more rare, client-side SSH vulnerability
Protocol-level issues such this libssh2 one, I think are the most rare of all
openssh is affected as well, but only in versions before 9.6.
But generally anything compiled with, or using, these old libraries can be affected.
This bug is the quintessential example of why you keep your system up to date, and that is truly the simplest and most effective defence.
None-the-less, limiting network access further protects you the much more common server exploits. (But it is now kind of off topic for this now.) But this does matter for SSH security overall.
I see a lot of people doing overkill (not just here). Such as protecting against things that are practically impossible to happen, and really just convoluting things.
If this computer is going always going through a router for Inerrnet, you aren’t exposing SSH to the Internet (without port forwarding) you are generally safe. But if you don’t trust devices on your network, or use a laptop, I think allowing localhost, and blocking everything else is just as safe as disabling it.
Many of us (and a few of my apps) can’t live without ssh, it’s why I’d prefer to restrict than disable.
But ufw should just be a front end for nftables for you.
So either do it through ufwornftables. Since you have ufw already in place and working, I’d use that.
Right now you are letting all 192.168.0.X IPs through for everything: all ports, all protocols. This is fine, if you trust your network and do a lot of stuff between hosts.
And then SSH no matter where you’re from.
The SSH rule is moot if you only SSH from within your LAN.
Important if you have visitors. 
)