Re: Restrict SSH to local network only except for Git users?
You might consider keeping your repo in an web/http directory for pulling and having your other users submit patches to you via eg email. That way you don't need ssh exposed to the public internet at all. That's how I have my self hosted git repos set up anyway. On Thu, Jul 27, 2023 at 09:24:56AM +0900, lain. wrote: > I have a pretty nifty network setup that allows me to host from home via > WireGuard. > But there's one thing I'm struggling with. > Because for security reasons, I made it impossible for people outside > the network to connect via SSH, but for Git to function properly, I need > to allow SSH only for git@(DOMAIN) or git@(PUBLIC IP), and redirect that > to my home network so they can do stuff like "git pull", "git push", and > all the other fancy stuff. > > My pf.conf rules look like this: > > pass in quick on wg0 proto tcp from 192.168.0.0/24 to any port 22 > > pass in on $externalinterface proto tcp from any to $externalip port 22 > > rdr-to $internalip > > block in quick on egress proto tcp from any to any port 22 > > And my sshd_config: > > AllowUsers lain@192.168.0.0/24 > > AllowUsers git@(DOMAIN) > > AllowUsers git@(PUBLIC IP) > > Where exactly am I doing wrong here?
Re: Restrict SSH to local network only except for Git users?
On Thu, Jul 27, 2023 at 10:28 AM lain. wrote: > > I have a pretty nifty network setup that allows me to host from home via > WireGuard. > But there's one thing I'm struggling with. > Because for security reasons, I made it impossible for people outside > the network to connect via SSH, but for Git to function properly, I need > to allow SSH only for git@(DOMAIN) or git@(PUBLIC IP), and redirect that > to my home network so they can do stuff like "git pull", "git push", and > all the other fancy stuff. > > My pf.conf rules look like this: > > pass in quick on wg0 proto tcp from 192.168.0.0/24 to any port 22 > > pass in on $externalinterface proto tcp from any to $externalip port 22 > > rdr-to $internalip > > block in quick on egress proto tcp from any to any port 22 > > And my sshd_config: > > AllowUsers lain@192.168.0.0/24 > > AllowUsers git@(DOMAIN) > > AllowUsers git@(PUBLIC IP) > > Where exactly am I doing wrong here? I suspect you're overthinking this. Rather than preventing access altogether, turn off password authentication and use SSH keys for authentication - for the git accounts, change the shell to git-shell if you haven't already. That way, bad faith actors can try all they want, they ain't gettin' in unless they get a hold of someone's key, and even if they do, it's likely a git key and the shell (barring any security vulns in git) will prevent them from doing anything not git related. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Restrict SSH to local network only except for Git users?
I have a pretty nifty network setup that allows me to host from home via WireGuard. But there's one thing I'm struggling with. Because for security reasons, I made it impossible for people outside the network to connect via SSH, but for Git to function properly, I need to allow SSH only for git@(DOMAIN) or git@(PUBLIC IP), and redirect that to my home network so they can do stuff like "git pull", "git push", and all the other fancy stuff. My pf.conf rules look like this: > pass in quick on wg0 proto tcp from 192.168.0.0/24 to any port 22 > pass in on $externalinterface proto tcp from any to $externalip port 22 > rdr-to $internalip > block in quick on egress proto tcp from any to any port 22 And my sshd_config: > AllowUsers lain@192.168.0.0/24 > AllowUsers git@(DOMAIN) > AllowUsers git@(PUBLIC IP) Where exactly am I doing wrong here?
Re: JH7110 - VF2
On 27/7/23 03:26, develo...@robert-palm.de wrote: Saw some commits for the JH7110. I flashed the latest RISCV snapshot miniroot73.img to an SD card and plugged it into the VF 2. Couldn't boot unfortunately. Commits on a master branch don't retrospectively magic their way into a previous release. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
JH7110 - VF2
Saw some commits for the JH7110. I flashed the latest RISCV snapshot miniroot73.img to an SD card and plugged it into the VF 2. Couldn't boot unfortunately. Is that already possible ? Or am I doing it wrong and there anything else to do than flashing the image ?
Re: RISCV mailing list
develo...@robert-palm.de wrote: > Zitat von Theo de Raadt : > > > develo...@robert-palm.de wrote: > > > >> I suggest a mailing list for the RISCV arch. > >> > >> Ok? > > > > > > It will be as popular and useful as the other per-architecture lists, > > meaning -- it is the wrong approach. > > Understand. Thanks. > > In consequence the other arch lists should be dropped as there is not > much traffic anyway? this is more like a who cares
Re: RISCV mailing list
Zitat von Theo de Raadt : develo...@robert-palm.de wrote: I suggest a mailing list for the RISCV arch. Ok? It will be as popular and useful as the other per-architecture lists, meaning -- it is the wrong approach. Understand. Thanks. In consequence the other arch lists should be dropped as there is not much traffic anyway?
Re: RISCV mailing list
develo...@robert-palm.de wrote: > I suggest a mailing list for the RISCV arch. > > Ok? It will be as popular and useful as the other per-architecture lists, meaning -- it is the wrong approach.
RISCV mailing list
I suggest a mailing list for the RISCV arch. Ok?
Re: Routing multiple IPv4 blocks
>> It can be done, but 1) it means that it's possible for hosts on RFC1918 >> addresses to reach the routable addresses directly without going via the >> router and vice-versa (which may or may not be a problem), 2) you'll >> need to think about how you want to arrange things if you use DHCP, and >> 3) it complicates things for firewall and nat rules. > > 1. I do not believe this should be a problem, as far as I am aware this > is routed based on MAC address (Layer 2), but IP addresses are a higher > layer (Layer 3). It means that your directly internet-accessible hosts have a way that they can reach your internal-network hosts without going through the firewall. Many network admins would consider this a problem. > 2. DHCP is simple, it is only for the private block (192.168.2.1/24) > which devices will use by default, global addresses from the /29 block > is assigned manually, this is because most containers are internal, > which the NAT is just so they can still access the internet, but not > expose themself fully (and before you say "why not use a global > address" that's fine, you have thought about how to arrange things for this > IPv4 addresses are expensive and I am lucky to have a /29, fwiw, you're using an expensive ISP which has ample spare addresses, there's a faorly good chance they'll give you more if asked. > 3. I don't think so, because I specify the "from" address as either from > 192.168.2.1/24 or the static block, which clearly distinguishes between > them. Also the "quick" rules are above the NAT, this should pick up and > pass out the traffic respectively before it even gets to NAT, I doubt > this is the issue and I believe it lies within the routing table. it's common to be able to use the network interface on which a packet is received as part of the decision whether to accept that packet. most example rulesets you'll find do that, so be aware if cribbing from other setups. >> 217.169.18.56 is a network address (mask it out against the netmask, >> the remaining "host bits" are all zeroes), you cannot use this (or the >> broadcast address) as a host address >> >> $ ipcalc 217.169.18.56/29 >> address : 217.169.18.56 >> netmask : 255.255.255.248 (0xfff8) >> network : 217.169.18.56 /29 >> broadcast : 217.169.18.63 >> host min : 217.169.18.57 >> host max : 217.169.18.62 >> hosts/net : 6 > > Ah my mistake, I totally forgot about the loopback address which would > be 217.169.18.56, this is from my own stupidity. > t's not a loopback, it's the network address. > But in theory, can I assign IPs from the /29 without having a default > gateway from that block, could I put the gateway as the /32 and keep all > 6 of the usable IPv4s? > > A router does not need 2 IPv4's, only one, so is it possible to keep one > or is it a requirement to have an IPv4 from the block assigned to the > router? hosts within that subnet need to be able to send ethernet paclets that reach the router. this is normally done by ARP which requires that the router has a host address (not a network or broadcast address) within the subnet. there are other ways to do it but they are fiddly, more fragile (requiring changes on every host if the router hardwarw address is changed), and really not recommended to go down that route unless you have a solid grasp of the basics. > > But the fact remains is, I believe all the addresses are bound to by the > router not according to what you've shown in your mail. > nmap'ing all the IPv4s in the block return the ports open by the > router. there's going to be some reason for this but it'll be easier to fix what's obviously a problem first and then go from there. > So it should be: > > inet alias 217.169.18.57 255.255.255.248 217.169.18.63 > > correct? yes, or you can leave off the broadcast address, it's set by default anyway. (remember to renumber the existing .57 host if you're going to use .57 for the router) -- Please keep replies on the mailing list.
