Re: Wg-quick warns that unwind may leak DNS queries
>From the unwind manpage: > unwind sends DNS queries to nameservers to answer queries and switches to > resolvers learned from dhclient(8), dhcpleased(8) or slaacd(8) if it > detects that DNS queries are blocked by the local network. Perhaps the warning us to let you know that using unwind _may_ still result in your queries going to a local network's DHCP-provided domain-name-servers? -Dayid
Re: Select ssh key from ssh-agent?
I can't relate; doing this from OpenBSD6.7 to OpenBSD6.7 the ecdsa forward through and show up via ssh-add without any issues (and allow using the intermediary host without having the keys present (and being able to choose keys as per the initial question). I was also able to do this over to a MacOS system which also handled the scenario excellently as described above and handled ECDSA just as well.
Re: Select ssh key from ssh-agent?
Consider: workstation$ eval $(ssh-agent) workstation$ ssh-add ~/.ssh/my_primary_key workstation$ ssh-add ~/.ssh/my_secondary_key workstation$ ssh-add -l hash /home/user/.ssh/my_primary_key hash /home/user/.ssh/my_secondary_key workstation$ ssh -A intermediaryhost intermediaryhost$ ssh-add -l hash /home/user/.ssh/my_primary_key hash /home/user/.ssh/my_secondary_key intermediaryhost$ ls ~/.ssh/ # So, even though these keys *are not on "intermediaryhost": intermediaryhost$ ssh -i /home/user/.ssh/my_primary_key targethostA intermediaryhost$ ssh -i /home/user/.ssh/my_secondary_key targethostB If you do the above ssh's with -vv you will see like: debug1: Will attempt key: /home/user/.ssh/my_primary_key RSA hash explicit agent debug1: Will attempt key: /home/user/.ssh/my_secondary_key RSA hash agent debug1: Will attempt key: /home/user/.ssh/id_rsa RSA hash explicit You can go one step further and configure these using Host/IdentityFile in your ~/.ssh/config *even if the files do not exist on your intermediary machine*.
sudoreplay in sudo 1.8.21 on 6.2-snapshot
Using sudoreplay with log_input and log_output on OpenBSD I recently encountered: After updating to sudo-1.8.21 today when I do "sudoreplay " the session begins but does not proceed to the next screens. Last worked in sudo-1.8.20p2 still works fine. I've tried this with sudoreplay -R also. The symptom persists. Sessions created in 1.8.21 or 1.8.20 I cannot play back using 1.8.21. Sessions created in 1.8.21 or 1.8.20 I canplay back using 1.8.20. Tested on: OpenBSD maleah.dayid.org 6.2 GENERIC.MP#101 i386 $ sudo -V Sudo version 1.8.21 I've been able to consistently recreate by attempting to sudoreplay any session. Is there any further useful information I may provide to investigate such behavior? -David A. Pocock
Re: booting OpenBSD with grub
I've not done this since 2009, but found in my notes: # The OpenBSD section of the menu.lst config file, for GRUB. # ## You would like to use: # root (hd1,1,a) # kernel --type=openbsd /bsd # # But OpenBSD passes bios kernel parameters with its own bootloader, # the first stage of which is installed in the partition boot record, # and in turn calls /boot, which in turn loads kernel /bsd. So just # use the GRUB chainloader instead: # ## OpenBSD title OpenBSD root (hd1,1) makeactive chainloader +1 Naturally, your root device may vary. -David On Wed, 27 May 2015, cobalt wrote: any idea on the the proper way to get grub to boot openbsd: set root=(hd1,4) is what i have, but i am missing something and i do not know what. any thoughts would help. regards. gilles
