Re: Request for recommendation - encryption and signature for file backup
Aham Brahmasmi wrote: >If I am not wrong, the verification should fail. If you have a system that uses private / public signing keys then, yes, you're correct. But: 1) In my opinion it's probably overkill for just doing backups. As I said in my previous email, just using symmetric encryption and encrypting in advance the few files you really care about is probably good enough and simpler. 2) You'll have to remember to encrypt your private signing key (using some symmetric encryption like aes256) before you make a backup of it. >Let us assume I get access to the download server and I replace the >perl based installer with a rust based installer in the bsd.rd. I also >change the SHA256.sig file. I do not think I will fool anybody who uses >signify to verify the all-new-improved-rust-based-installer bsd.rd with >the base.pub. That's right, because the public keys are already in /etc/signify and the signature verification would fail. The use of public / private keys here is necessary because files are distributed to other people and these other people must not have access to the private key. In your case there is no "other people" so using public / private keys is probably more than you need. A simple symmetric encryption with just a password would be good enough in my opinion (but it's only my opinion, it's up to you to decide what's best for you). You have to ask yourself: what are the problems that I am trying to defend against? Then use the simplest solution that solves those problems. Be practical, and don't waste time trying to defend against threats which are only theoretical. >For files like compressed database backups, I am not sure I can >determine whether a file has been correctly decrypted or not by looking >at whether the result looks like random garbage. Well, then, you have a good reason to use signatures. Note that it still does not require a public / private key system. You could just compute a hash of your DB (before encryption) and then store the hash on your backup system (no need to encrypt the hash) together with the encrypted DB (encrypted using symmetric encryption and a password). Then later you would: 1) decrypt the DB 2) compute the hash of the decrypted DB and check that it matches the hash from the backup system. Note that in that case the hash must be created *before* you encrypt the DB, not after, otherwise you will not be able to detect a change done to both the file and the hash on the backup system (as I said in my previous email). Anyway, it's up to you to decide what you want to do and whether you need a hash and / or public / private keys, but my advice is to keep your system as simple as possible. Philippe
Slow performance when using mu(4e)
Hi, Recently I tried to use mu4e on OpenBSD. However the indexing performance is dreadly slow compared to my Linux box. There was also an issue report on mu upstream[1] where someone reported mu can only process ~7msg/s on OpenBSD. I suspect it's because of the slow write performance on FFS, which in my case can only process ~2msg/s when the index file grows large (over 1GB) (BTW my box is mips64el/Loongson running 6.6-stable so it's even slower). The read part is probably OK as when re-indexing it can quickly skip already indexed items but when adding new contents to the index it becomes slow again. Would like to ask for some suggestions on how to improve this situation. Thanks in advance. [1] https://github.com/djcb/mu/issues/1335 signature.asc Description: PGP signature
Re: Automated OS builds?
On Sun, Jan 05, 2020 at 06:08:55PM +, Paul Suh wrote: > On Jan 5, 2020, at 12:43 PM, Morten Gade Liebach wrote: > > > > Read release(8), then write a script runs through the described process. > > I can do that, and will if I have to, but if someone has already done it or > has a base to start from that would be better. (I’ve been building OpenBSD > releases that way since 3.2? 3.3? Something like that.) There are so many specifics to how each person configures his system and curates his local changes, it's hard to give a "one size fits all". (the complementary page for ports is bulk(8) btw which goes to great length explaining the problems you might encounter due to the size of the ports tree)
Re: Boot fail using internal SATA port, success using USB port.
HyperThread must be off! Danger! Probably shouldn't enable virtualization unless using it. Secure boot is off, that is correct. Do you have the latest BIOS? Will the disk boot if you skip UEFI completely and run in legacy mode? Are you dual-booting with Windows? It hates everything and can mess up BIOS settings to make you love Windows even more. Do you get to the boot> prompt? Then try booting the different hard drives listed above it manually. Good Luck, Chris Bennett
Boot fail using internal SATA port, success using USB port.
summary: OpenBSD installs to internal HDD from external USB but fails to load after the first reboot. If the HDD is removed from the internal port and is connected via a "SATA to USB" cable it boots succesfully. I am a new and inexperienced user, excuse my ignorance. All the details and things I have tried so far: -All relevant UEFI options configured to legacy mode. -minirootXX.fs copied to USB using rufus. -USB boot using legacy mode. -In install: whole disk mbr-auto config. -After reboot DELL logo is displayed 3 times. On the 3rd time it stays static. --Using gpt format instead results in an infinite boot loop. -Starting UEFI-menu(f2) or diagnostics(f5) or boot-menu(f12) appear to initiate but then stay static. The UEFI appears to be completely "bricked". There is no way to proceed. --Resetting UEFI using CMOS and booting with the HDD in internal port still renders UEFI "bricked" although it gives a PXE option because it is enabled by default in the now reset UEFI. --Merely performing a "clean" on diskpart(win7) to the HDD and plugging it back "unbricks" the UEFI. --Merely removing the HDD "unbricks" the UEFI. -Connecting HDD using "SATA to USB" cable(even without CMOS reset) works and OpenBSD boots. -Installing Windows 7(in the same manner OpenBSD was) works and boots from the internal SATA port. Deduction: There seems to be something not allowing OpenBSD to boot from the internal SATA port, in addition to it rendering the laptop unusable until the HDD is removed, cleaned or connected via USB port. I have taken the time to write all the UEFI configuration I use. Please check it if you think the problem stems from there. hardware: DELL Latitude e5440 platform: amd64 UEFI version:A24 [X]checked [ ]not checked -General --System information --Battery Information --Boot Sequence Sequence: [X]Internal HDD [X]Diskette Drive [X]USB Storage [X]CD/DVD/CD-RW Drive [X]Onboard NIC Boot List Option: [X]Legacy [ ]UEFI --Advanced Boot Options [X]Enable Legacy Option ROMs --Date/Time -System Configuration --Integrated NIC [ ]Enable UEFI Network Stack [ ]Disabled [X]Enabled [ ]Enabled w/PXE --Parallel Port [ ]Disabled [X]AT [ ]PS2 [ ]ECP --Serial Port [ ]Disabled [X]COM1 [ ]COM2 [ ]COM3 [ ]Com4 --SATA Operation [ ]Disabled [X]AHCI [ ]RAID On --Drives [X]SATA-0 [X]SATA-1 [X]SATA-2 [X]SATA-3 --SMART Reporting [X]Enable SMART Reporting --USB Configuration [X]Enable Boot Support [X]Enable External USB Port [X]Enable USB3.0 Controller --Audio [X]Enable Audio --Unobtrusive Mode [ ]Enable Unobtrusive Mode --Miscellaneous Devices [X]Enable Microphone [X]Enable Camera [X]Enable ExpressCard [X]Enable Hard Drive Free Fall Protection [X]Enable Media Card [ ]Disable Media Card -Video --LCD Brightness -Security --Admin Password Not Set --System Password Not Set --Strong Password [ ]Enable Strong Password --Password Configuration --Password Bypass [X]Diabled [ ]Reboot Bypass --Password Change [X]Allow Non-Admin Password Changes --Non-Admin Setup Changes [ ]Allow Wireless Switch Changes --TPM Security [ ]TPM Security --Computrace(R) [X]Deactivate [ ]Disable [ ]Activate --CPU XD Support [X]Enable CPU XD Support --OROM Keyboard Access [X]Enable [ ]One Time Enable [ ]Disable --Admin Setup Lockout [ ]Enable Admin Setup Lockout --Master Password Lockout [ ]Enable Master Password Lockout -Secure Boot --Secure Boot Enable [X]Disabled [ ]Enabled --Export Key Management [ ]Enable Custom Mode -Performance --Multi Core Support [X]All [ ]1 [ ]2 --Intel SpeedStep [X]Enable Intel SpeedStep --C-States Control [X]C states --Intel TurboBoost [X]Enable Intel TurboBoost --HyperThread control [ ]Disabled [X]Enabled --Rapid Start Technology disabled -Power Management --AC Behavior [ ]Wake On AC --Auto On Time [X]Disabled [ ]Every Day [ ]Weekdays [ ]Select Days --USB Wake Support [ ]Enable USB Wake Support --Wireless Radio Control [ ]Control WLAN radio [ ]Control WWAN radio --Wake on LAN/WLAN [X]Disabled [ ]LAN Only [ ]WLAN Only [ ]LAN or WLAN --Block Sleep [ ]Block Sleep(S3 State) --Peak Shift [ ]Enable Peak Shift --Advanced Battery Charge Configuration [ ]Enable Advanced Battery Charge Mode --Primary Battery Charge Configuration [ ]Adaptive [ ]Standard [ ]ExpressCharge [X]Primarily AC Use [ ]Custom --Battery Slice Charge Configuration [X]Standard [ ]ExpressCharge --Intel(R) Smart Connect Technology disabled -POST Behavior --Adapter Warnings [X]Enable Adapter Warnings --Keypad(Embedded) [x]Fn Key Only [ ]By Numlock --Mouse/Touchpad [ ]Serial Mouse [ ]PS2 Mouse [X]Touchpad/PS-2 Mouse --Numlock Enable [X]Enable Numlock --Fn Key Emulation [X]Enable Fn Key Emulation --MEBx Hotkey [X]Enable MEBx Hotkey --Fastboot [ ]Minimal [X]Thorough [ ]Auto --Extend BIOS POST Time [X]0seconds [ ]5seconds [ ]10seconds -Virtualization Supoort --Virtualization [X]Enable Intel Virtualization Technology --VT for Direct I/O [X]Enable VT for Direct I/O --Trusted Execution disabled -Wireless --Wireless Switch [X]WWAN [X]WLAN [X]WiGig [X]Bluetooth --Wireless Device Enable [X
Re: sshd_config#PermitRootLogin typo
On Sun, 5 Jan 2020 15:22:46 +0100
"lu hu" wrote:
> fuck I did a typo, sorry, I wanted to write:
>
> 66# sshd -T|grep -i permitr
> permitrootlogin without-password
> 66#
>
> really sorry.
>
> But the issue is still there. man page says there should be
> prohibit-password and not without-password
>
> > Sent: Sunday, January 05, 2020 at 3:07 PM
> > From: "lu hu"
> > To: misc@openbsd.org
> > Subject: Re: sshd_config#PermitRootLogin typo
> >
> > yes!
> >
> > > Sent: Sunday, January 05, 2020 at 3:00 PM
> > > From: "Robert Klein"
> > > To: misc@openbsd.org
> > > Subject: Re: sshd_config#PermitRootLogin typo
> > >
> > > On Sun, 5 Jan 2020 14:47:15 +0100
> > > "lu hu" wrote:
> > >
> > > > Hello,
> > > >
> > > > http://man.openbsd.org/sshd_config#PermitRootLogin
> > > > says
> > > > ...The default is prohibit-password.
> > > > If this option is set to prohibit-password (or its deprecated
> > > > alias, without-password), password and keyboard-interactive
> > > > authentication are disabled for root.
> > > >
> > > > SO:
> > > >
> > > > if I remove the PermitRootLogin line from sshd_config, then
> > > > rcctl restart sshd, then why can I see
> > > >
> > > > 66# sshd -T|grep -i permitr
> > > > permitrootlogin yes
> > > > 66#
> > > >
> > > > instead of prohibit-password ?
> > > >
> > > > Thanks!
> > > >
> > >
> > > Was the deleted one the only “PermitRootLogin” line in your
> > > /etc/ssh/sshd_config?
> > >
> > >
>
PermitRootLogin option second paragraph:
If this option is set to prohibit-password (or its
deprecated alias, without-password), password and
keyboard-interactive authentication are disabled for root.
The output probably results from “without-password” being before
“prohibit-password” in the list. Cf. /usr/src/usr.bin/ssh/servconf.c:
static const struct multistate multistate_permitrootlogin[] = {
{ "without-password", PERMIT_NO_PASSWD },
{ "prohibit-password", PERMIT_NO_PASSWD },
{ "forced-commands-only", PERMIT_FORCED_ONLY },
{ "yes",PERMIT_YES },
{ "no", PERMIT_NO },
{ NULL, -1 }
};
Best regards
Robert
Re: Automated OS builds?
On Jan 5, 2020, at 12:43 PM, Morten Gade Liebach wrote: > > Read release(8), then write a script runs through the described process. I can do that, and will if I have to, but if someone has already done it or has a base to start from that would be better. (I’ve been building OpenBSD releases that way since 3.2? 3.3? Something like that.) —Paul
Re: LCP keepalive timeout for PPPOE
On 2020-01-03, jrmu wrote: > inet 0.0.0.0 255.255.255.255 NONE \ > pppoedev cpsw0 authproto pap \ > authname '12345...@isp.net' authkey 'abcd1234' up > dest 0.0.0.1 > #inet6 eui64 > !/sbin/route add default -ifp pppoe0 0.0.0.1 > #!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 I had major problems with using 'dest' in hostname.pppoe0. I ended up having to do something like: inet 0.0.0.0 255.255.255.255 0.0.0.1 \ pppoedev re0 authproto chap authname '' authkey '' etc.. For whatever reason, using 'inet 0.0.0.0 255.255.255.255 NONE \ dest 0.0.0.1' would use this ifconfig command: ifconfig pppoe0 inet 0.0.0.0 netmask 255.255.255.255 pppoedev re0 authproto chap Where as if you replaced the NONE with 0.0.0.1 and removed the 'dest 0.0.0.1' line, it would run: ifconfig pppoe0 inet 0.0.0.0 netmask 255.255.255.255 broadcast 0.0.0.1 pppoedev re0 authproto chap And that seemed to make my connection work. I'm not sure why, but it had to do something with my side not accepting the peer's IP. -Tom
Re: Automated OS builds?
Read release(8), then write a script runs through the described process. -- Morten Gade Liebach ★ https://m.lieba.ch/ ‐‐‐ Original Message ‐‐‐ On Sunday, January 5, 2020 5:29 PM, Paul Suh wrote: > Folks, > > My DuckDuckGo-fu seems to be weak right now. > > Is there a set of automated scripts somewhere that: > > 1. Checks anoncvs*.*.openbsd.org:/cvs for updates to the patch branch source > tree > 2. Checks them out > 3. Builds them > 4. Builds a release > > Then notifies me when this has happened? > > I’m looking to follow the patch branch but since I’m using flashrd I > can’t use syspatch on my production systems. (Yes I know I’m not asking for > help with flashrd, but with an automated build system for the base system.) > > I can hack something like this together but I’m kinda surprised that I > can’t find something that someone else has already done. Or maybe I’m just > bad with search engines. > > —Paul >
Automated OS builds?
Folks, My DuckDuckGo-fu seems to be weak right now. Is there a set of automated scripts somewhere that: 1) Checks anoncvs*.*.openbsd.org:/cvs for updates to the patch branch source tree 2) Checks them out 3) Builds them 4) Builds a release Then notifies me when this has happened? I’m looking to follow the patch branch but since I’m using flashrd I can’t use syspatch on my production systems. (Yes I know I’m not asking for help with flashrd, but with an automated build system for the base system.) I can hack something like this together but I’m kinda surprised that I can’t find something that someone else has already done. Or maybe I’m just bad with search engines. —Paul
Re: But there is Fossil...
On Sat, Jan 4, 2020 at 8:48 PM Theo de Raadt wrote: > SNIP > wow this is going downhill. random solo-repo people telling us what to do > when Chuck Cranor and I started this whole export-the-repo model. > > get some perspective dude, hopefully in the jungle. It seems like a lot of people in this thread don't understand, a good read is http://chuck.cranor.org/p/anoncvs.pdf It took me 10 seconds reading Chuck Cranor's web page to find it. Not certain why there has been so much noise on misc@ lately.
Re: OpenBSD VM on ESXi: uvn_flush: obj=0xfffffd813ee78298, offset=0x33f000. error during pageout.
On Thu, Oct 31, 2019 at 08:01:25AM -, Stuart Henderson wrote: > On 2019-10-30, Jurjen Oskam wrote: > > > > All snapshots I tried up to and including this point did not show the > > problem: > > OpenBSD 6.6-beta (GENERIC.MP) #202: Mon Aug 12 11:01:21 MDT 2019 > > > > All snapshots I tried starting from this point show the problem: > > OpenBSD 6.6-beta (GENERIC.MP) #207: Tue Aug 13 11:32:34 MDT 2019 > > > > > > Would it be helpful to start a binary search for the exact commit that > > introduced the problem? > > Yes, definitely! We usually do this with date-based cvs updates. > > > I've been looking at the commit history around > > that time but haven't been able to spot an obvious candidate; but that's > > probably because I'm not a programmer. > > Sometimes diffs are tested in snapshots before they're committed, > so you might need to look beyond the snapshot dates to find the > commit. This took a while. I was not able to isolate a commit, but I did find the variable that can reliably trigger the problem. It's a bit embarrasing to say that the trigger is a f*ckup at my end: in my template configuration for short-lived VMs, I accidentally configured /usr to be 1G. I'm aware this is too small, but I never noticed because it didn't seem to cause any problem for quite a few releases. I guess at some point the kernel grew a bit and then the problem started to occur during reorder_kernel. After configuring /usr to be created at 4G (and leaving everything else the same), the problem never occurred again. This does lead me to a question though. Is it expected that a (nearly) full filesystem can result in dmesg error messages such as these? (None of the filesystems on the system are mounted softdep) uvn_flush: obj=0xfd813ee78298, offset=0x33f. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x33f. error during pageout. uvn_flush: WARNING: changes to page may be lost! [ repeat last two lines many times ] uvn_flush: obj=0xfd813ee78298, offset=0x340. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x340. error during pageout. uvn_flush: WARNING: changes to page may be lost! [ repeat last two lines many times ] /dev/sd0a on / type ffs (local) /dev/sd0i on /home type ffs (local, nodev, nosuid) /dev/sd0d on /tmp type ffs (local, nodev, nosuid) /dev/sd0f on /usr type ffs (local, nodev) /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev, wxallowed) /dev/sd0e on /var type ffs (local, nodev, nosuid) Regards, Jurjen Oskam
Fw: Re: sshd_config#PermitRootLogin typo
fuck I did a typo, sorry, I wanted to write: 66# sshd -T|grep -i permitr permitrootlogin without-password 66# really sorry. But the issue is still there. man page says there should be prohibit-password and not without-password > Sent: Sunday, January 05, 2020 at 3:07 PM > From: "lu hu" > To: misc@openbsd.org > Subject: Re: sshd_config#PermitRootLogin typo > > yes! > > > Sent: Sunday, January 05, 2020 at 3:00 PM > > From: "Robert Klein" > > To: misc@openbsd.org > > Subject: Re: sshd_config#PermitRootLogin typo > > > > On Sun, 5 Jan 2020 14:47:15 +0100 > > "lu hu" wrote: > > > > > Hello, > > > > > > http://man.openbsd.org/sshd_config#PermitRootLogin > > > says > > > ...The default is prohibit-password. > > > If this option is set to prohibit-password (or its deprecated alias, > > > without-password), password and keyboard-interactive authentication > > > are disabled for root. > > > > > > SO: > > > > > > if I remove the PermitRootLogin line from sshd_config, then rcctl > > > restart sshd, then why can I see > > > > > > 66# sshd -T|grep -i permitr > > > permitrootlogin yes > > > 66# > > > > > > instead of prohibit-password ? > > > > > > Thanks! > > > > > > > Was the deleted one the only “PermitRootLogin” line in your > > /etc/ssh/sshd_config? > > > >
Re: openiked.org down?
who can bring up openiked.org to life? > Sent: Tuesday, December 31, 2019 at 4:14 PM > From: "Umgeher Torgersen" > To: misc@openbsd.org > Subject: Re: openiked.org down? > > yeah, it's down... > > ; <<>> DiG 9.4.2-P2 <<>> openiked.org > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58691 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;openiked.org. IN A > > ;; AUTHORITY SECTION: > openiked.org. 2496IN SOA > a.ns.bsws.de. noc.bsws.de. 1577745128 1 3600 604800 86400 > > ;; Query time: 0 msec > ;; SERVER: 10.0.5.5#53(10.0.5.5) > ;; WHEN: Tue Dec 31 15:14:22 2019 > ;; MSG SIZE rcvd: 82 > > On Tue, Dec 31, 2019 at 03:08:47PM +0100, lu hu wrote: > > Hello, > > > > did anyone noticed that the https://openiked.org/ is down? > > > > NO "A" record is associated with the domain? > > > > Thanks for any infos. > > > >
Fw: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
Hello, any thoughts anyone? > Sent: Sunday, December 29, 2019 at 6:07 PM > From: "lu hu" > To: misc@openbsd.org > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > Hello: > > 66# grep -i challenge /etc/ssh/sshd_config > #ChallengeResponseAuthentication yes > 66# sshd -T|grep -i challenge > challengeresponseauthentication yes > 66# > > it doesn't counts if it is commented out, since it is by default YES as I > started the thread with: > > > > > > > # what am I talking about? > > > > > > https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication > > > > > > ChallengeResponseAuthentication > > > Specifies whether challenge-response authentication is allowed. All > > > authentication styles from login.conf(5) are supported. The default is > > > yes. > > > > anyone in this world that understands what am I trying to point out? :) > > with all the infos so far I have, the "ChallengeResponseAuthentication" > should be by default NO. but it isn't currently. > > maybe someone from the devs? or sorry, am I posting to the wrong list? > > Really Many Thanks. > > Happy New Year! > > > > > Sent: Monday, December 23, 2019 at 1:58 PM > > From: "Jan Betlach" > > To: "lu hu" > > Cc: misc@openbsd.org > > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > > > > > Isn’t it commented out by default? > > > > Jan > > > > > > > Hello, > > > > > > nobody about the $subject? :) > > > > > > Why isn't ChallengeResponseAuthentication NO in sshd_config by > > > default? > > > > > > It would be more secure, afaik. > > > > > > Many thanks. > > > > > > > > >> Sent: Thursday, December 19, 2019 at 7:58 PM > > >> From: "lu hu" > > >> To: misc@openbsd.org > > >> Subject: Re: Why isn't ChallengeResponseAuthentication NO in > > >> sshd_config? > > >> > > >>> Sent: Wednesday, December 18, 2019 at 9:49 PM > > >>> From: "Bodie" > > >>> To: misc@openbsd.org, owner-m...@openbsd.org > > >>> Subject: Re: Why isn't ChallengeResponseAuthentication NO in > > >>> sshd_config? > > >>> > > >>> > > >>> > > >>> On 18.12.2019 18:48, lu hu wrote: > > Hello, > > > > > > # what am I talking about? > > > > https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication > > > > ChallengeResponseAuthentication > > Specifies whether challenge-response authentication is allowed. > > All > > authentication styles from login.conf(5) are supported. The default > > is > > yes. > > > > > > # what does linux distros use: > > > > If I ex.: read: > > > > https://access.redhat.com/solutions/336773 > > > > then I can see ChallengeResponseAuthentication is NO for security > > reasons. Ubuntu too. > > > > > > # what else says ChallengeResponseAuthentication should be NO? > > > > https://www.openwall.com/lists/oss-security/2019/12/04/5 > > -> > > >>> > > >>> These issues were quickly fixed in OpenBSD as you can see in > > >>> Security > > >>> > > >> > > >> This isn't related to the subject. > > >> > > >>> > > 1. CVE-2019-19521: Authentication bypass > > > > this attack should be more mitigated if > > ChallengeResponseAuthentication would be by default set to NO. > > > > > > # FIX: > > > > from this: > > cat /etc/ssh/sshd_config > > ... > > # Change to no to disable s/key passwords > > #ChallengeResponseAuthentication yes > > ... > > > > to this: > > vi /etc/ssh/sshd_config > > cat /etc/ssh/sshd_config > > ... > > # Change to no to disable s/key passwords > > ChallengeResponseAuthentication no > > ... > > > > But of course by default, without fixing sshd_config it should be > > NO. > > > > Who the hell uses s/key with sshd nowadays? > > > > >>> > > >>> And you are aware that this option is not there just for S/Key, > > >>> right? > > >>> It's for example PAM Google authenticator too on Linux and > > >>> others > > >>> > > >>> I think you missed couple of points. Eg.: > > >>> > > >>> https://www.openbsd.org/faq/faq10.html#SKey > > >>> > > >>> and the fact that login.conf(5) on OpenBSD by default enables S/Key. > > >>> > > >> > > >> I checked the https://www.openbsd.org/faq/faq10.html#SKey > > >> > > >> first step is to have a /etc/skey dir. So checked it: > > >> > > >> 66# ls /etc/skey > > >> ls: /etc/skey: No such file or directory > > >> 66# > > >> > > >> There is no /etc/skey by default. So you have to do the "skeyinit -E" > > >> as root, etc. Same for Google authenticator, etc. So > > >> ChallengeResponseAuthentication should be only enabled then.. when > > >> you set up extra auth methods. > > >> >
Re: sshd_config#PermitRootLogin typo
yes! > Sent: Sunday, January 05, 2020 at 3:00 PM > From: "Robert Klein" > To: misc@openbsd.org > Subject: Re: sshd_config#PermitRootLogin typo > > On Sun, 5 Jan 2020 14:47:15 +0100 > "lu hu" wrote: > > > Hello, > > > > http://man.openbsd.org/sshd_config#PermitRootLogin > > says > > ...The default is prohibit-password. > > If this option is set to prohibit-password (or its deprecated alias, > > without-password), password and keyboard-interactive authentication > > are disabled for root. > > > > SO: > > > > if I remove the PermitRootLogin line from sshd_config, then rcctl > > restart sshd, then why can I see > > > > 66# sshd -T|grep -i permitr > > permitrootlogin yes > > 66# > > > > instead of prohibit-password ? > > > > Thanks! > > > > Was the deleted one the only “PermitRootLogin” line in your > /etc/ssh/sshd_config? > >
Re: sshd_config#PermitRootLogin typo
On Sun, 5 Jan 2020 14:47:15 +0100 "lu hu" wrote: > Hello, > > http://man.openbsd.org/sshd_config#PermitRootLogin > says > ...The default is prohibit-password. > If this option is set to prohibit-password (or its deprecated alias, > without-password), password and keyboard-interactive authentication > are disabled for root. > > SO: > > if I remove the PermitRootLogin line from sshd_config, then rcctl > restart sshd, then why can I see > > 66# sshd -T|grep -i permitr > permitrootlogin yes > 66# > > instead of prohibit-password ? > > Thanks! > Was the deleted one the only “PermitRootLogin” line in your /etc/ssh/sshd_config?
sshd_config#PermitRootLogin typo
Hello, http://man.openbsd.org/sshd_config#PermitRootLogin says ...The default is prohibit-password. If this option is set to prohibit-password (or its deprecated alias, without-password), password and keyboard-interactive authentication are disabled for root. SO: if I remove the PermitRootLogin line from sshd_config, then rcctl restart sshd, then why can I see 66# sshd -T|grep -i permitr permitrootlogin yes 66# instead of prohibit-password ? Thanks!
Re: httpd with multiple php-fpm pools in separate chroots
On 2020/01/05 07:43, Nazar Zhuk wrote: > On 2020-01-04 09:21, Stuart Henderson wrote: > > On 2020-01-04, Nazar Zhuk wrote: > > > I get SCRIPT_FILENAME passed from httpd relative to httpd chroot > > > (/site1/htdocs/... ) and PHP being chrooted into /var/www/site1 needs > > > that to be relative to it's own chroot (/htdocs/...). > > > > httpd is a bit inflexible (intentionally, I think). Can you work around > > it with ln -s . /var/www/site1/site1 ? > > Yes, this works, thanks. > > Is this intentional though, or is it that this use case hasn't been fully > considered yet? Unsure. > Separate chroots for different FastCGI processes seems like a good idea to > isolate those processes from each other. > > This could be configured with something like: > > fastcgi strip > > similar to how "request strip" works. > > I can write a patch if this is something the maintainers would be interested > in adding. It does sound like it might be useful and should be fairly straightforward - I thinik it would make sense to write a patch and send to tech@ and see what httpd users/devs think.
Re: Advices on AD implementation with OpenBSD
Thanks all for the answers. jca pointed out: "OpenBSD doesn't support "POSIX" ACLs or extended attributes so DC support is a pain (eg sysvol shares, etc)." Code wasn't stripped from source, but need work to be enabled at least with trivial database (tdb) to support ACLs/xattr. After that, see what the core dump is about. If I found out, future discussion @ports Thanks. -- Fabio Martins http://www.nabundapode.com.br/ > Hello! > > fm+obsd+misc+l...@phosphorusnetworks.com (Fabio Martins), 2019.12.26 (Thu) > 20:26 (CET): >> I am drawing a scenario to replace the Windows 2003 Server with OpenBSD, >> acting as AD/DC and firewall. There is a need to share folders and > > AFAIK this is the current status of samba AD/DC on OpenBSD: > > "This update doesn't include lmdb support (now the default upstream); >and doesn't fix the AD DC support in the samba daemon either." > > https://marc.info/?l=openbsd-ports&m=157019016817459 > > There have been updates (and downgrades) since then, but nothing > indicates that AD/DC works. Have not tried myself in a lng time. > > Marcus >
Re: sysupgrade fails
On Sun, Jan 5, 2020 at 1:11 PM Anders Andersson wrote: > > > Not sure if it's in any way related when it comes to doing a > sysupgrade compared to a clean install, but did you see this thread > and the corresponding BIOS upgrade? > > http://openbsd-archive.7691.n7.nabble.com/APU2-fails-to-boot-on-OpenBSD-6-6-current-521-td379219.html > > https://github.com/pcengines/coreboot/issues/356 Yes-ish. I was running apu2_v4.10.0.3, but upgraded to apu2_v4.11.0.2 today. Because of the problems reported I didn't run apu2_v4.11.0.1. Not sure if the bios has anything to do with it. I do run the same bios version on my apu1, and that does not have this problem.
Re: sysupgrade fails
On Sun, Jan 5, 2020 at 1:05 PM Christer Solskogen
wrote:
>
> Sorry, I forgot to telll you that I run current. I was upgrading a snapshot
> from 1st of january to the latest one. But this has happened before (It
> looks like the last time sysupgrade did successfully work was 4th of
> December)
>
> On Sun, Jan 5, 2020 at 12:58 PM Christer Solskogen <
> christer.solsko...@gmail.com> wrote:
>
> > Hi!
> >
> > On one(out of two!) of my APUs sysupgrade fails, and I'm having trouble
> > understanding why.
> > This is what happens:
> >
> > Available disks are: sd0.
> > Which disk is the root disk? ('?' for details) [sd0] sd0
> > Checking root filesystem (fsck -fp /dev/sd0a)... OK.
> > Mounting root filesystem (mount -o ro /dev/sd0a /mnt)... OK.
> > Force checking of clean non-root filesystems? [no] no
> > umount: /mnt: Device busy
> > Can't umount sd0a!
> >
> > This does not happen if I run the upgrade manually by downloading a newer
> > bsd.rd and boot that.
> > This is a APU2c4 - My APU1 does not have this problem.
> >
Not sure if it's in any way related when it comes to doing a
sysupgrade compared to a clean install, but did you see this thread
and the corresponding BIOS upgrade?
http://openbsd-archive.7691.n7.nabble.com/APU2-fails-to-boot-on-OpenBSD-6-6-current-521-td379219.html
https://github.com/pcengines/coreboot/issues/356
Re: sysupgrade fails
Sorry, I forgot to telll you that I run current. I was upgrading a snapshot
from 1st of january to the latest one. But this has happened before (It
looks like the last time sysupgrade did successfully work was 4th of
December)
On Sun, Jan 5, 2020 at 12:58 PM Christer Solskogen <
christer.solsko...@gmail.com> wrote:
> Hi!
>
> On one(out of two!) of my APUs sysupgrade fails, and I'm having trouble
> understanding why.
> This is what happens:
>
> Available disks are: sd0.
> Which disk is the root disk? ('?' for details) [sd0] sd0
> Checking root filesystem (fsck -fp /dev/sd0a)... OK.
> Mounting root filesystem (mount -o ro /dev/sd0a /mnt)... OK.
> Force checking of clean non-root filesystems? [no] no
> umount: /mnt: Device busy
> Can't umount sd0a!
>
> This does not happen if I run the upgrade manually by downloading a newer
> bsd.rd and boot that.
> This is a APU2c4 - My APU1 does not have this problem.
>
sysupgrade fails
Hi!
On one(out of two!) of my APUs sysupgrade fails, and I'm having trouble
understanding why.
This is what happens:
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0] sd0
Checking root filesystem (fsck -fp /dev/sd0a)... OK.
Mounting root filesystem (mount -o ro /dev/sd0a /mnt)... OK.
Force checking of clean non-root filesystems? [no] no
umount: /mnt: Device busy
Can't umount sd0a!
This does not happen if I run the upgrade manually by downloading a newer
bsd.rd and boot that.
This is a APU2c4 - My APU1 does not have this problem.
Keep up the good work (was: Re: But there is Fossil...)
Stuart Henderson writes: > On 2020/01/05 00:33, go...@disroot.org wrote: > > January 5, 2020 2:24 AM, "Roderick" wrote: > > > > > On Sun, 5 Jan 2020, go...@disroot.org wrote: > > > > > >> so I don't understand what's wrong with FreeBSD and OpenBSD. > > > > > > I do not see a problem in CVS. > > > > Sure, but I started this thread because of OpenBSD's plan > > to migrate to Git. > > > > What plan? The plan which the OP would be aware doesn't exist were he to have bothered reading the FAQ he decided had too many words. Throwing away 30 years of work is A-OK, even expected, in this brave new CADT world so the alternative -- foundation technology should not be ripped out willy-nilly -- is an idea they simply cannot have. At this point it's clear he's either trolling or wilfully retarded. Either way not worth continuing with. To end positively I will add that a simpler git front-end, for want of a better term, will be a useful addition to the space of revision control tools. It's looking good so far. Keep it up. Matthew
