You are not logged in.
I determined that what I had in /etc/hosts.allow was not restricting SSH connections to just the domains I had specified. Then I found out tcp_wrappers was removed from Arch Linux in 2011. So, sshd on Arch is not linked against libwrap. I have this entry in /etc/hosts.allow on my VPS running Arch (named deltachunk):
sshd: .subdomain.isp1.com .subdomain.isp2.netSince I won't always know ahead of time which IP address remote connection attempts will be coming from, but knowing I'll be coming from one of these subdomains, I can reduce the attack surface for SSH. sshd will close the connection if the source IP address doesn't come from one of these subdomains. I use this for a few different VPS, and I only noticed that it wasn't doing what I expected on deltachunk. I was connected to my mobile phone's hot spot, on my carrier's 5G network. So definitely not in either of the subdomains listed. If tcp_wrappers were working, I wouldn't have been able to connect to deltachunk over SSH. But I was able to connect, so that's how I learned tcp_wrappers wasn't working.
deltachunk is running firewalld, but as far as I can tell firewalld expects IP addresses or IP network addresses in the source parameter for any zones I want to put ssh into. This appears to preclude specifying the subdomains the way I have for tcp_wrappers. I don't control the subdomains, and I don't have a static IP address for either of these ISPs. When my laptop is connected through one of these ISPs, I cannot be guaranteed to have the same IP address (or even the same subnet) that I had previously. This might lock me out of my VPS if my ISP IP address changes for any reason.
I'm not sure if I could exhaustively list the IP addresses in the subdomains, I thought DNS zone transfers are restricted for security reasons. And neither ISP is likely to give me a list of the network addresses in those subdomains, they likely add and remove networks all the time and none of their customers even notice. I could request and probably pay for a static IP address, but that might be prohibitively expensive. My Arch router at home (barbican, after the fortified gate in the outer wall of a castle) uses ddclient to update a dynamic DNS record with my current WAN IP address from my ISP, but I'd need to configure a way for the router to update the necessary firewalld zone on deltachunk with the new source address, something I'm not likely to be able to do since my WAN/ISP address just changed.
How would you solve this problem?
Last edited by ectospasm (2021-12-07 02:52:54)
Offline
How would you solve this problem?
Have sshd check the domain, as also suggested by Fedora:
https://fedoraproject.org/wiki/Changes/ … ic_filters
Offline
ectospasm wrote:How would you solve this problem?
Have sshd check the domain, as also suggested by Fedora:
https://fedoraproject.org/wiki/Changes/ … ic_filters
That blurb is rather short, and doesn't provide an example. However, reading the sshd_config and ssh_config man pages gives me a clue. I also just tested my VPS's ability to let me log in remotely through my VPS dashboard (they temporarily allow a VNC connection) if I ever change ISPs, so I have recourse if and when I move household or change ISPs. Here's how I will do it in /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication no
#...
Match Host *.subdomain.isp1.com,*.subdomain.isp2.net
PermitRootLogin prohibit-password
PasswordAuthentication yes
PubkeyAuthentication yesThis works, kind of. Tcp_wrappers will close the connection immediately if it's not from the approved domains. Using the Match stanza, sshd now presents its host key, and prompts for a password. If I'm connecting from outside these subdomains using a known good password, it won't let me in, which is the desired end result. But tcp_wrappers doesn't even get to that point. Which is what I'd prefer, honestly. But this will have to work, I don't see another way of getting sshd to refuse the connection if the attempt isn't from an approved domain.
Offline