Skip to main content
added 1128 characters in body
Source Link
grawity
  • 15.5k
  • 1
  • 34
  • 53

Use a firewall rule – for example, nftables or iptables. (Firewalld may also be able to do this with "zones".) This is the most versatile option; both nftables and iptables support wildcards, and both actually prevent connections from the incorrect interface (which is not relevant against internet bots, but can be relevant when guarding against malicious local users on wlan0).

  • For example, in nftables you would write:

    table inet filter {
        chain input {
            [...]
            tcp dport 22 iifname "eth*" accept
            tcp dport 22 reject
            [...]
        }
    }
    
  • In iptables .rules files, the same is:

    [...]
    -A INPUT -p tcp --dport 22 -i eth+ -j ACCEPT
    -A INPUT -p tcp --dport 22 -j REJECT
    [...]
    

Your system uses per-connection sshd instances ("inetd style" or "socket activated") rather than the usual standalone daemon. In this mode, the listen addresses are not decided by the sshd but by the supervisor (super-server).

With systemd socket activation, run systemctl edit --full sshd.socket to define the listen addresses, replacing the existing ListenStream= options with:

[Socket]
ListenStream=192.168.55.101:22

Alternatively, you can keep the global ListenStream=, but bind the socket to only a specific interface (exact name only, wildcards not allowed):

[Socket]
ListenStream=0.0.0.0:22
ListenStream=[::]:22
BindToDevice=eth0

Afterwards, restart sshd.socket to apply the changes.

Note that this inetd-mode is generally not recommended for sshd, as the bruteforce bots may cause systemd's rate-limiting to kick in and prevent you from making even legitimate connections. You should consider disabling sshd.socket and enabling the "standalone" sshd.service instead. (After doing so, the listen addresses will be controlled by /etc/ssh/sshd_config instead.)

Use a firewall rule – for example, nftables or iptables. (Firewalld may also be able to do this with "zones".)

  • For example, in nftables you would write:

    table inet filter {
        chain input {
            [...]
            tcp dport 22 iifname "eth*" accept
            tcp dport 22 reject
            [...]
        }
    }
    
  • In iptables .rules files, the same is:

    [...]
    -A INPUT -p tcp --dport 22 -i eth+ -j ACCEPT
    -A INPUT -p tcp --dport 22 -j REJECT
    [...]
    

Use a firewall rule – for example, nftables or iptables. (Firewalld may also be able to do this with "zones".) This is the most versatile option; both nftables and iptables support wildcards, and both actually prevent connections from the incorrect interface (which is not relevant against internet bots, but can be relevant when guarding against malicious local users on wlan0).

  • For example, in nftables you would write:

    table inet filter {
        chain input {
            [...]
            tcp dport 22 iifname "eth*" accept
            tcp dport 22 reject
            [...]
        }
    }
    
  • In iptables .rules files, the same is:

    [...]
    -A INPUT -p tcp --dport 22 -i eth+ -j ACCEPT
    -A INPUT -p tcp --dport 22 -j REJECT
    [...]
    

Your system uses per-connection sshd instances ("inetd style" or "socket activated") rather than the usual standalone daemon. In this mode, the listen addresses are not decided by the sshd but by the supervisor (super-server).

With systemd socket activation, run systemctl edit --full sshd.socket to define the listen addresses, replacing the existing ListenStream= options with:

[Socket]
ListenStream=192.168.55.101:22

Alternatively, you can keep the global ListenStream=, but bind the socket to only a specific interface (exact name only, wildcards not allowed):

[Socket]
ListenStream=0.0.0.0:22
ListenStream=[::]:22
BindToDevice=eth0

Afterwards, restart sshd.socket to apply the changes.

Note that this inetd-mode is generally not recommended for sshd, as the bruteforce bots may cause systemd's rate-limiting to kick in and prevent you from making even legitimate connections. You should consider disabling sshd.socket and enabling the "standalone" sshd.service instead. (After doing so, the listen addresses will be controlled by /etc/ssh/sshd_config instead.)

Source Link
grawity
  • 15.5k
  • 1
  • 34
  • 53

Use a firewall rule – for example, nftables or iptables. (Firewalld may also be able to do this with "zones".)

  • For example, in nftables you would write:

    table inet filter {
        chain input {
            [...]
            tcp dport 22 iifname "eth*" accept
            tcp dport 22 reject
            [...]
        }
    }
    
  • In iptables .rules files, the same is:

    [...]
    -A INPUT -p tcp --dport 22 -i eth+ -j ACCEPT
    -A INPUT -p tcp --dport 22 -j REJECT
    [...]