Re: Vultr hosting of OpenBSD
On 8 September 2018 19:55:16 BST, Ken M > My questions are: > >1. Is it still current information that it would be better to use my >own >image/install/iso for openbsd on Vultr? I just like to manage the disk my own way, so I don't use their install process. But they provide iPXE and that works decently. Have autoinstall on the top, and you're just as efficient as with using their iso. >2. Is vultr a good place to host an openbsd box? If not interested in >hearing >alternatives. I use them. >Also a side note question, is it possible to use VMD/VMM in an openbsd >guest on vultr. Just try, it's cheap.
SSH VerifyHostKeyDNS fails
Hello list, From a freshly installed OpenBSD 6.4, whos resolv.conf points to a validating resolver, unbound-host confirms that the SSHFP records of the remote server have been validated, "ssh -v" shows that it found a match between the host key of the remote server and one of these records, but it seems that it did not validate them: $ ssh bombay [...] debug1: Server host key: ssh-ed25519 SHA256:ume9IzcMIHGfcwJi9PGIKE2owEosrbUS0dkLQ5aNufk debug1: found 2 insecure fingerprints in DNS debug1: matching host key fingerprint found in DNS No ED25519 host key is known for bombay.magickarpet.org and you have requested strict checking. Host key verification failed. On a different OS, with the same SSH client configuration (running OpenSSH 7.4p1, though, instead of 7.9), using the same resolvers, I don't see the same issue, and the connection succeeds. My ~/.ssh/config contains nothing extraordinary: Host bombay Hostname bombay.magickarpet.org VerifyHostKeyDNS yes StrictHostKeyChecking yes The output of unbound-host: $ unbound-host -D -v -t SSHFP bombay.magickarpet.org bombay.magickarpet.org has SSHFP record 1 2 E4A9DE946DFA35304C1C65F2FF0379E9792B247BF69F16161CF441E095DB5008 (secure) bombay.magickarpet.org has SSHFP record 4 2 BA67BD23370C20719F730262F4F188284DA8C04A2CADB512D1D90B43968DB9F9 (secure) Does anyone know what's wrong? Cheers, -- Étienne
Re: vultr
On 06/01/2019 16:38, Juan Francisco Cantero Hurtado wrote: Use their default OpenBSD install. They have a special config on the host for OpenBSD and the clock drifting problem. Can you tell us more? Do you mean they change a setting on the host machine just for the OpenBSD guest, that they wouldn't otherwise? Then download bsd.rd from an official OpenBSD mirror, check the file with signify, copy the file to /, reboot the system, run "boot bsd.rd" in the boot prompt and reinstall everything cleaning the whole disk. Thanks for the tip, been wondering for a while how to fix this. -- Étienne
Re: Unexpected pf behavior for DHCP traffic?
On 30/07/2021 04:37, Theo de Raadt wrote: dhcpleased (and a few other daemons) use bpf, thus see raw packets from the wire before pf can block them. Most daemons of this type also use bpf to send packets, and pf doesn't see these either Does that prevent dhcpd from listening on any virtual interface? I'm trying to have it listen for requests on a vether in a bridge, and that fails (or I'm making a mistake). -- Étienne
Re: Unexpected pf behavior for DHCP traffic?
On 31/07/2021 19:27, Stefan Sperling wrote:
On Sat, Jul 31, 2021 at 07:02:35PM +0100, Étienne wrote:
On 30/07/2021 04:37, Theo de Raadt wrote:
dhcpleased (and a few other daemons) use bpf, thus see raw packets
from the wire before pf can block them. Most daemons of this type
also use bpf to send packets, and pf doesn't see these either
Does that prevent dhcpd from listening on any virtual interface? I'm trying
to have it listen for requests on a vether in a bridge, and that fails (or
I'm making a mistake).
It should work, unless are running dhclient/dhcpleased on the same machine,
because the bpf filter will eat DHCP-related packets. You'll know whether
this affects you by checking whether dhcpd starts working when you kill the
DHCP client.
Thanks for your help, Stefan, and sorry for coming back so late on that.
Despite the tip, I'm afraid it doesn't work.
I have two Ubiquiti EdgerouterLite running 6.9, these boxes have 3
interfaces cnmac0, cnmac1 and cnmac2. I bridge cnmac0 and cnmac1, and I
connect cnmac0 on both boxes to one switch, and cnmac1 on both boxes to
another switch. I turn RSTP on all these interfaces and on the switches,
add a vether0 with an IP address (in 172.16.0.0/16) in bridge0 on either
box, and I have connectivity.
I also configure an IP address on cnmac2 (in 192.168.1.0/24). Then I
configure dhcpd to listen on cnmac2 and on vether0:
dhcpd_flags=-y vether0 -Y vether0 vether0 cnmac2
With this setup, I see DHCP leases added in the 192.168.1.0 range, but
none in the 172.16.0.0 range. Moreover, I see DHCP requests when running
tcpdump on bridge0, but not on vether0. So I'm not sure what's
preventing it to work.
My configuration files content:
% cat /etc/hostname.cnmac0
up
% cat /etc/hostname.cnmac1
up
% cat /etc/hostname.cnmac2
inet 192.168.1.4 255.255.255.0 NONE
!route add 0.0.0.0/0 192.168.1.254
inet6 autoconf
up
% cat /etc/hostname.vether0
lladdr fe:e1:ba:d0:be:d3
inet 172.16.0.4 255.255.255.0
up
% cat /etc/hostname.bridge0
add cnmac0
stp cnmac0
add cnmac1
stp cnmac1
add vether0
maxaddr 1000
timeout 40
up
% cat /etc/dhcpd.conf
option domain-name-servers 192.168.1.254;
default-lease-time 14400;
max-lease-time 86400;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
range 192.168.1.16 192.168.1.126;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
option routers 172.16.0.1;
range 172.16.0.16 172.16.0.126;
}
Running tcpdump shows this:
% doas tcpdump -ve -i bridge0 "port 67 or port 68"
tcpdump: listening on bridge0, link-type EN10MB
19:16:57.596572 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1120 [|bootp] (ttl 64, id
0, len 328)
19:17:00.597025 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1123 [|bootp] (ttl 64, id
0, len 328)
19:17:03.600246 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1126 [|bootp] (ttl 64, id
0, len 328)
[…]
19:17:42.630441 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1165 [|bootp] (ttl 64, id
0, len 328)
^C
74 packets received by filter
0 packets dropped by kernel
% doas tcpdump -ve -i vether0 "port 67 or port 68"
tcpdump: listening on vether0, link-type EN10MB
^C
1320 packets received by filter
0 packets dropped by kernel
Any idea?
--
Étienne
Re: Unexpected pf behavior for DHCP traffic?
On 19/08/2021 19:01, Stefan Sperling wrote:
Any idea?
I suspect the packets towards vether0 are being dropped by pf.
What does your pf.conf look like?
I have been looking in that direction, and reduced my pf.conf to this:
default_tcp_ports="{ 22 }"
set block-policy return
set skip on lo0
set skip on bridge0
set skip on vether0
anchor tables
block drop # block stateless traffic
pass out# establish keep-state
anchor letsencrypt_traffic
pass in on cnmac2 inet proto icmp from 192.168.1.0/24 to \
( cnmac2 ) keep state
pass in on cnmac2 inet proto tcp from any to \
( cnmac2) port $default_tcp_ports flags S/SA keep state
Do you see anything related in tcpdump -n -i pflog0, provided you've
using 'log' statements on your block rules in pf.conf?
I wasn't, so I switched "block drop" for "block drop log", and I saw the
DHCP requests in the output of "tcpdump -n -i pflog0". First, it puzzled
me that PF was the culprit, when I had specified "set skip" on bridge0
and vether0. Then, I realised I didn't "set skip" on the physical
interfaces of the bridge, cnmac0 and cnmac1.
I still need to adjust things a bit, but thanks already for putting me
on the right track!
--
Étienne
Convert a Linux VPS to OpenBSD
Hello there, This is a bit of a long shot, but I'm trying my luck: There used to be a community thread on Scaleway's documentation website that explained how to convert a Linux instance to an OpenBSD instance, because no OpenBSD ISO image was available in their console. It seems that this doc disappeared as their documentation section has changed format, and I can't find it on archive.org either. I would like to try and apply the same process at another VPS provider. Does anyone remember or know how this was done, and would they be kind enough to summarise it here, please? Thanks! -- Étienne
Re: Convert a Linux VPS to OpenBSD
On 20/06/2022 18:11, Łukasz Moskała wrote: $ wget -O /bsd.rd https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/bsd.rd Reboot and enter grub shell grub> kopenbsd /bsd.rd grub> boot Paths will differ if /boot is on seperate partition. Thanks! Or using VPS provider that actually supports openbsd could also be a good solution. Thanks all for the suggestions. I'll take the opportunity to mention I use Vultr, they support OpenBSD very well, and I'm really happy with them. Sometimes though, you need an alternative. ;-) Cheers, -- Étienne
Re: Convert a Linux VPS to OpenBSD
On 23/06/2022 09:19, David Demelier wrote: I think I've done it using https://themimitoof.fr/installer-openbsd-7-0-sur-gandicloud-vps/ Great pointer! Thanks for that. -- Étienne
