Re: Asymmetric file encryption… use gnupg from ports or is there something else?
On Tue, May 09, 2023 at 09:21:03AM +1000, Stuart Longland wrote: > Hi all, > > Silly question… is there a tool for encrypting files with asymmetric > keys on OpenBSD? I'm aware of GnuPG in ports, and I'm fine with using > that, however I'm curious to know what other options there are out > there, especially options that are part of the base system. You may want to take a look at enchive (http://nullprogram.com/blog/2017/03/12/) It's not in base, but it's self-contained and tiny.
Re: alias issue with snapshot #1175
> On May 8, 2023, at 5:32 PM, Sonic wrote: > > No real difference in the output of ifconfig or netstat before and > after restarting the network after a reboot. > The .45 alias refuses to accept/pass data other than answer a ping > after booting until the network, or at least the interface (em0) that > contains the alias is restarted. > From outside testing the ssh port I get "tcp closed" and after the > network restart "tcp open", the other 3 addresses, .41, .42, .43 all > work properly after booting. > The .44 address being used by another device and not as an alias seems > to be tripping something up, but only after boot, once the interface > is restarted all is well. > Absolutely nothing in the logs indicating any error. > > >> On Mon, May 8, 2023 at 10:48 AM Sonic wrote: >> >>> On Mon, May 8, 2023 at 9:24 AM Stuart Henderson >>> wrote: >>> There's not enough information really. /etc/hostname.* and maybe results >>> of ifconfig -A and netstat -rn might give more clues. >> >> Here's that info - hopefully not munged beyond use. >> Note that this is after the interface has been restarted (so the .45 >> is working) but everything appeared normal before (ifconfig, etc.) >> although I won't be able to verify until late tonight when I can >> reboot the system. > Do you have names that depend on DNS in pf.conf?
Re: Problem with WireGuard on OpenBSD 7.3
On 2023-05-08 23:15, Tor Houghton wrote: > On Sat, May 06, 2023 at 04:40:21PM -, Stuart Henderson wrote: > > > > [snip] > > > > wgport port-number wgkey my-private-key > > inet 10.0.98.1/24 > > > > [snip] > > Here's[*] a super hacky way to convert a pivpn wireguard config file to output > that can be placed in a /etc/hostname.wg0 file, if this helps anyone at all. > > $ cat client.conf | ./wgconv.sh > > Tor > > * https://www.bogus.net/~torh/files/wgconv.sh > Huh, neat. :) It made me smile to see this because I wrote my own pledged + unveiled tool in Perl for this exact same task some time ago. Though mine does some basic validation on the IPs, base64 keys, etc. Tool: https://github.com/3uryd1ce/sysadm/blob/master/translate_wg_conf Man page: https://github.com/3uryd1ce/sysadm/blob/master/man/man1/translate_wg_conf.1 One thing to note is that it depends on p5-Config-Std and p5-Net-IP to handle parsing and validation, so this would be needed first: # pkg_add p5-Config-Std p5-Net-IP Anyway, my self-plug is over. Hope it helps someone.
Asymmetric file encryption… use gnupg from ports or is there something else?
Hi all, Silly question… is there a tool for encrypting files with asymmetric keys on OpenBSD? I'm aware of GnuPG in ports, and I'm fine with using that, however I'm curious to know what other options there are out there, especially options that are part of the base system. I know OpenSSL (and likely LibreSSL) can do RSA for this purpose, although its CLI is more of a debugging tool than an actual encryption tool. I'd also like to use ECC keys (ideally ED25519) for future proofing, since RSA is getting quite long in the tooth now. The use case here is to make an encrypted inbound mail queue: I'll be setting up OpenSMTPD to deliver emails through a script which will encrypt the emails with a public key so they can be collected over SFTP by my home mail server for final delivery. Basically like UUCP of yesteryear, but implemented with OpenSSH. The thinking being that while the emails are "at rest" on the remote server, they're stored encrypted, and apart from maybe destination host details (the destination user is the remote server's problem and can be stored encrypted), there's nothing kept on that remote server in the way of key material that would enable disclosure of the email content -- an attacker would have to catch such emails as they're being received (or compromise host binaries to leak content). This is experimental, done for intellectual curiosity rather than for any real necessity, but you never know… might come in handy. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: alias issue with snapshot #1175
No real difference in the output of ifconfig or netstat before and after restarting the network after a reboot. The .45 alias refuses to accept/pass data other than answer a ping after booting until the network, or at least the interface (em0) that contains the alias is restarted. >From outside testing the ssh port I get "tcp closed" and after the network restart "tcp open", the other 3 addresses, .41, .42, .43 all work properly after booting. The .44 address being used by another device and not as an alias seems to be tripping something up, but only after boot, once the interface is restarted all is well. Absolutely nothing in the logs indicating any error. On Mon, May 8, 2023 at 10:48 AM Sonic wrote: > > On Mon, May 8, 2023 at 9:24 AM Stuart Henderson > wrote: > > There's not enough information really. /etc/hostname.* and maybe results > > of ifconfig -A and netstat -rn might give more clues. > > Here's that info - hopefully not munged beyond use. > Note that this is after the interface has been restarted (so the .45 > is working) but everything appeared normal before (ifconfig, etc.) > although I won't be able to verify until late tonight when I can > reboot the system.
Re: Problem with WireGuard on OpenBSD 7.3
On Sat, May 06, 2023 at 04:40:21PM -, Stuart Henderson wrote: > > [snip] > > wgport port-number wgkey my-private-key > inet 10.0.98.1/24 > > [snip] Here's[*] a super hacky way to convert a pivpn wireguard config file to output that can be placed in a /etc/hostname.wg0 file, if this helps anyone at all. $ cat client.conf | ./wgconv.sh Tor * https://www.bogus.net/~torh/files/wgconv.sh
Re: What is the best way to move a VM to a bigger image?
On 2023-05-06 11:54 am, Hannu Vuolasaho wrote: Hello, I made a silly mistake when I set up my VM and my disk image is too small for my next operation. My plan is to give the new image to the VM, run a minimal install on it so I get the boot loader installed. Also disklabel will be good. ... Is this a good way to skin this cat? Or is there a better way to do it? It's fine, but I took it a different route recently, for a VM that I've been using for a year or two but realized I needed more space. It wasn't that hard to resize. However, it is worth calling out that recreating a VM can be a good way to find out what you need, and don't need, on it. If you go for the resize, you'll need the qemu-img tool from the qemu package in order to make sure the disk image is in qcow2 format (you can convert from a raw image if necessary), and then change its size. From there you can do partition and filesystem manipulation from within the VM. If you need to do something more complicated than add filesystems or grow the last partition, you should probably add more disk images or consider starting from a fresh install. Matthew
Re: alias issue with snapshot #1175
On Mon, May 8, 2023 at 9:24 AM Stuart Henderson wrote: > There's not enough information really. /etc/hostname.* and maybe results > of ifconfig -A and netstat -rn might give more clues. Here's that info - hopefully not munged beyond use. Note that this is after the interface has been restarted (so the .45 is working) but everything appeared normal before (ifconfig, etc.) although I won't be able to verify until late tonight when I can reboot the system. lo0: flags=8049 mtu 32768 index 5 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 em0: flags=8843 mtu 1500 lladdr 68:05:ca:33:9b:46 description: external network index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause) status: active inet 51.67.20.41 netmask 0xfff8 broadcast 51.67.20.47 inet 51.67.20.42 netmask 0x inet 51.67.20.43 netmask 0x inet 51.67.20.45 netmask 0x em1: flags=8802 mtu 1500 lladdr 00:25:90:87:9e:75 index 2 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier em2: flags=8843 mtu 1500 lladdr 00:25:90:87:9e:74 description: internal network index 3 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active inet netmask 0xfe00 broadcast enc0: flags=0<> index 4 priority 0 llprio 3 groups: enc status: active wg0: flags=80c3 mtu 1420 description: VPN index 6 priority 0 llprio 3 wgport wgpubkey wgpeer wgpsk (present) wgendpoint 61722 tx: 109217968, rx: 3820653136 last handshake: 96 seconds ago wgaip /24 wgaip /24 wgaip /24 wgaip /32 wgpeer wgpsk (present) wgendpoint 61723 tx: 3383156, rx: 2595500 last handshake: 30 seconds ago wgaip /24 wgaip /24 wgaip /23 wgaip /23 wgaip /32 wgpeer wgpsk (present) wgendpoint 32925 tx: 4543152, rx: 5454580 last handshake: 69 seconds ago wgaip /24 wgaip /24 wgaip /24 wgaip /24 wgaip /32 wgpeer wgpsk (present) wgendpoint 37666 tx: 21211976, rx: 3509392 last handshake: 77 seconds ago wgaip /24 wgaip /32 groups: wg inet 10.68.73.1 netmask 0xfff8 broadcast 10.68.73.7 pflog0: flags=141 mtu 33136 index 7 priority 0 llprio 3 groups: pflog 116 mbufs in use: 109 mbufs allocated to data 1 mbuf allocated to packet headers 6 mbufs allocated to socket names and addresses 0/40 mbuf 2048 byte clusters in use (current/peak) 107/210 mbuf 2112 byte clusters in use (current/peak) 0/8 mbuf 4096 byte clusters in use (current/peak) 0/8 mbuf 8192 byte clusters in use (current/peak) 0/0 mbuf 9216 byte clusters in use (current/peak) 0/0 mbuf 12288 byte clusters in use (current/peak) 0/0 mbuf 16384 byte clusters in use (current/peak) 0/0 mbuf 65536 byte clusters in use (current/peak) 660/676/524288 Kbytes allocated to network (current/peak/max) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines hostname.em0 Description: Binary data hostname.em2 Description: Binary data hostname.wg0 Description: Binary data
Re: PC Engines APU platform EOL
is anyone aware of such a nice little device with low power consumption and ECC memory? The alternatives mentioned so far just offer normal RAM options...
Re: alias issue with snapshot #1175
On 2023-05-08, Sonic wrote: > This is repeatable every time. After a boot the .45 alias does not > pass any traffic, its ports are closed. It will answer a ping, and > shows up in "ifconfig -A" (or em0) and in netstat. > The other 3 addresses work normally. > Restarting the interface with "sh /etc/netstart em0" brings the .45 > alias back to an active state. There's not enough information really. /etc/hostname.* and maybe results of ifconfig -A and netstat -rn might give more clues. -- Please keep replies on the mailing list.
Re: alias issue with snapshot #1175
This is repeatable every time. After a boot the .45 alias does not pass any traffic, its ports are closed. It will answer a ping, and shows up in "ifconfig -A" (or em0) and in netstat. The other 3 addresses work normally. Restarting the interface with "sh /etc/netstart em0" brings the .45 alias back to an active state. On Sun, May 7, 2023 at 8:43 PM Sonic wrote: > > After doing a "sh /etc/netstart em0" that alias is back up and > working. The problem occurs after boot. > > On Sun, May 7, 2023 at 7:23 PM Sonic wrote: > > > > Hello, > > > > Upgrade a system to the latest snapshot - 1175 - and am seeing a > > problem with an alias address. > > The outside IP is part of a /29 (not actual addresses) : > > inet 51.67.20.41 netmask 0xfff8 broadcast 51.67.20.47 > > inet 51.67.20.42 netmask 0x > > inet 51.67.20.43 netmask 0x > > inet 51.67.20.45 netmask 0x > > The address 51.67.20.44 is used by another device connected to the > > same cable modem. > > All was working well until the upgrade and now the alias 51.67.20.45 > > will answer a ping but shows ports that should be open as closed, and > > traffic does not pass. > > The other 3 addresses (main and aliases) continue to work normally. > > > > Thanks for any assistance. > > Chris
Re: 'bgpctl show rib in neighbor $peer' no longer shows unfiltered received routes
On Mon, May 08, 2023 at 09:14:43AM +0200, Claudio Jeker wrote:
> On Mon, May 08, 2023 at 12:28:58AM +0200, Rogier Krieger wrote:
> > While diagnosing an unrelated matter, I find that 'bgpctl show rib'
> > has difficulty with the 'in' keyword. The 'out' counterpart works as
> > expected. Looking at bgpctl(8), the following should work (but
> > doesn't):
> > $ bgpctl show rib in neighbor $peer
> > ambiguous argument: in
> > valid commands/args:
> >
> > invalid
> > leaked
> > in
> > out
> >
> >
> > Note: tested this on a 7.3 (w/ bgpd erratum) release system.
> > On a 7.2 release system, I don't see this regression (unsurprising, as
> > bgpctl(8) there doesn't list 'invalid' as a valid 'show rib' option).
> >
> > I suspect this involves the logic in match_token() from
> > src/usr.sbin/bgpctl/parser.c. I'll take a stab at providing a patch.
> > Meanwhile, I'd appreciate any hints and/or a workaround for the mean
> > time.
>
> Ugh. This broke with the introduction of "invalid" as keyword.
> The parser is not smart enough to handle keywords with equal prefix.
>
> Using a different word that does not start with "in" would be the simplest
> fix.
Here is a possible solution where a perfect match aborts the detection
loop. Now this only works if the labels are in the right order ("in"
before "invalid").
Since on match the internal state is modified the check needs to include
match == 1 to ensure that the state is correct.
I wonder if chaning "invalid" to "notvalid" or "noteligible" would be a
better fix for now...
--
:wq Claudio
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.132
diff -u -p -r1.132 parser.c
--- parser.c21 Apr 2023 10:49:01 - 1.132
+++ parser.c8 May 2023 10:12:44 -
@@ -525,12 +525,14 @@ match_token(int argc, char *argv[], cons
struct filter_set *fs;
const char *word = argv[0];
size_t wordlen = 0;
+ int recheck;
*argsused = 1;
match = 0;
if (word != NULL)
wordlen = strlen(word);
for (i = 0; table[i].type != ENDTOKEN; i++) {
+ recheck = 0;
switch (table[i].type) {
case NOTOKEN:
if (word == NULL || wordlen == 0) {
@@ -548,6 +550,7 @@ match_token(int argc, char *argv[], cons
case KEYWORD:
if (word != NULL && strncmp(word, table[i].keyword,
wordlen) == 0) {
+ recheck = 1;
match++;
t = [i];
if (t->value)
@@ -557,6 +560,7 @@ match_token(int argc, char *argv[], cons
case FLAG:
if (word != NULL && strncmp(word, table[i].keyword,
wordlen) == 0) {
+ recheck = 1;
match++;
t = [i];
res.flags |= t->value;
@@ -630,6 +634,7 @@ match_token(int argc, char *argv[], cons
case ASTYPE:
if (word != NULL && strncmp(word, table[i].keyword,
wordlen) == 0) {
+ recheck = 1;
match++;
t = [i];
res.as.type = t->value;
@@ -687,6 +692,7 @@ match_token(int argc, char *argv[], cons
fs->action.community = res.community;
TAILQ_INSERT_TAIL(, fs, entry);
+ recheck = 1;
match++;
t = [i];
}
@@ -703,6 +709,7 @@ match_token(int argc, char *argv[], cons
fs->action.community = res.community;
TAILQ_INSERT_TAIL(, fs, entry);
+ recheck = 1;
match++;
t = [i];
}
@@ -720,6 +727,7 @@ match_token(int argc, char *argv[], cons
fs->action.community = res.community;
TAILQ_INSERT_TAIL(, fs, entry);
+ recheck = 1;
match++;
t = [i];
}
@@ -771,6 +779,7 @@ match_token(int argc, char *argv[], cons
wordlen) == 0 && argc > 1 &&
parse_number(argv[1], , table[i].type)) {
*argsused += 1;
+ recheck = 1;
match++;
t = [i];
Re: 'bgpctl show rib in neighbor $peer' no longer shows unfiltered received routes
On Mon, May 08, 2023 at 12:28:58AM +0200, Rogier Krieger wrote: > While diagnosing an unrelated matter, I find that 'bgpctl show rib' > has difficulty with the 'in' keyword. The 'out' counterpart works as > expected. Looking at bgpctl(8), the following should work (but > doesn't): > $ bgpctl show rib in neighbor $peer > ambiguous argument: in > valid commands/args: > > invalid > leaked > in > out > > > Note: tested this on a 7.3 (w/ bgpd erratum) release system. > On a 7.2 release system, I don't see this regression (unsurprising, as > bgpctl(8) there doesn't list 'invalid' as a valid 'show rib' option). > > I suspect this involves the logic in match_token() from > src/usr.sbin/bgpctl/parser.c. I'll take a stab at providing a patch. > Meanwhile, I'd appreciate any hints and/or a workaround for the mean > time. Ugh. This broke with the introduction of "invalid" as keyword. The parser is not smart enough to handle keywords with equal prefix. Using a different word that does not start with "in" would be the simplest fix. -- :wq Claudio
Re: PC Engines APU platform EOL
I will try and summarize the replies succinctly. As Stuart mentioned, by wanting fanless AND rackmount, I was certainly limiting my choices. Thanks - Damian
