Viimatised otsingud
Otsimisvalikud
#openssh
Also: #Slackware 15 has a security update for Python3:
http://www.slackware.com/security/viewer.php?l=slackware-security&y=2025&m=slackware-security.326755
Slackware-current just adopted #OpenSSH 10.0.p1 & #OpenSSL 3.5
n/openssh-10.0p1-x86_64-1.txz: Upgraded. Potentially-incompatible changes include the removal of the weak DSA signature algorithm, completing the deprecation process that began in 2015 (when DSA was disabled by default) and repeatedly warned over the last 12 months.
n/openssl-3.5.0-x86_64-1.txz: Upgraded. New LTS release, supported until 08 Apr 2030.
I updated the Trac issue with as far as I got here:
https://trac.macports.org/ticket/72317
But I need to step AFK for a while and won't be able to look at this again for several hours.
If others want to take a crack at it and fix whatever I failed to get correct, contributions are more than welcome!
Thanks!
(and here I was thinking the legacy_dsa variant removal would be my potential stumbling block. Nope! sigh I should have tested the snapshot more thoroughly I guess, but I still don't have a functional mpbb locally and I don't even want to get into my "methodology" for diffing this stuff locally, it's basically line by line with not such great tools.)
Near as I can discern sshd-session.c got reworked a bit since 9.9p2 and my shoot from the hip attempt is insufficient.
#OpenSSH #MacPorts
OpenSSH 10.0 released with hybrid post-quantum algorithm mlkem768x25519-sha256 as default key agreement, new cipher preference list, new options, bug fixes
#OpenSSH 10.0 release notes: https://www.openssh.com/txt/release-10.0
In addition to removing DSA, this splits the user authentication code from the sshd-session binary into a separate sshd-auth binary. Also only #OpenBSD, this new sshd-authd is relinked on boot, just like sshd-session & sshd.
@JessTheUnstill @Pibble
And yes, I treat all devices as insecure and would rather invest the time and effort needed get #TechIlliterates up to speed on the #OfflinePGP method!
- Sounds cumbersome, but when your threat model literally goes against the #1 #Hacking #Regime (#USA) with more #Exploits stockpiled than any hacking forum (cuz #NOBUS doctrine), you gotta have to upgrade.
Given the cheapness of storage (legitimate 1TB microSD cards exist and they ain't 4-digit items!) I'd legitimately look into #OTP #encryption and (IF I had the €€€€€€ to do so!) would even sponsor implementing it in #OpenVPN, #WireGuard and #OpenSSH (for #SSH-Tunmeling).
- The #US is a #RogueNation with a Rogue Government! The sooner we accept this reality the sooner we can not only adjust to it but act accordingly…
I sincerely wish y'all could legitimately call me a tinfoilhat but so far I've been proven right all the time...
Suppose you have `AllowUsers foo` set in sshd_config. Normally, this will result in logs like:
[date] [host] sshd-session[pid]: Invalid user ubuntu from 195.178.110.18 port 44128
But sometimes, you see this instead:
[date] [host] sshd-session[pid]: error: PAM: Authentication error for illegal user centos from 82.193.122.91
What are the circumstances in which the attacker is able to get through sshd to interact with the PAM stack despite having given a non-permitted login? #infosec #openssh