Hello!
We are implementing changes to the Heroes OpenVPN.
There are three changes - two are already implemented, and you likely
did not notice - the other is breaking and requires changes in your
client configuration after the 12th of April (one week from now)!
SHORT version:
On April 12th, please visit the Admin Wiki and update your OpenVPN
client configuration with the latest examples:
Native OpenVPN:
https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/VPN#OpenVPN…
NetworkManager:
https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/VPN#Network…
Afterwards, delete any files containing Heroes credentials in plain text.
VERBOSE version:
1. BREAKING: Removal of compression
On April 5th, LZO compression will be disabled on the OpenVPN server.
If you want to connect on or after this day, you will have to remove the
respective option from your OpenVPN client configuration:
With native OpenVPN:
```
comp-lzo
```
With NetworkManager:
```
compress=lzo
```
If you do not remove this option after it has been disabled on the
server, you will receive error messages like "Bad LZO decompression
header byte: xxx" blocking you from working in the Heroes network!
This change is implemented due to inherent security issues with
compression in OpenVPN:
https://community.openvpn.net/openvpn/wiki/Compression.
2. Non-breaking: Removal of user/password authentication and change of
ciphers
Previously we used two layers of authentication for OpenVPN:
- LDAP username/password
- client certificates
The LDAP layer is removed as it often encourages users to store
sensitive data (i.e. the same passphrase also used for sudo elevation to
root on our systems!) in plain text and does not yield a security
benefit given the existing use of client certificates.
Additionally, we adjust the ciphers to make use of hardware acceleration
and to decrease CPU load as well as latency for users in remote
locations far away from our data center.
These changes have already been implemented and are compatible with
existing clients - however we still ask you to remove the following
lines from your client configuration:
With native OpenVPN:
```
auth-user-pass.*
cipher AES-256-CBC
data-ciphers AES-256-CBC
```
With NetworkManager:
```
username=.*
password-flags=.*
cipher=AES-256-CBC
[vpn-secrets]
password=.*
```
Make sure to also delete any files containing the plain text
credentials, such as the file previously passed as an argument to
"auth-user-pass".
You can already implement the changes mentioned in point 2 now, or you
do it together with the mandatory change mentioned in point 1 on April 12th.
All these changes are tracked and explained in
https://progress.opensuse.org/issues/151492.
Thanks for collaborating!
If you have any questions, please let me know.
Georg
Hi everyone,
for additional security, we disable DSA and RSA host keys on all
infra.opensuse.org machines in favor of Ed25519 and ECDSA. If you use a
modern operating system, you likely do not notice this change, and you
likely already trust either one of the more modern keys for the machines
you work with.
To ensure the authenticity of your SSH connections, I recommend only
connecting to hosts the keys of which you verified. I started a
repository containing an automatically generated known_hosts file with
trusted entries for all of our Salt managed machines - you can
incorporate this into your own known_hosts file.
It is now also possible to use DNS based verification using SSHFP
records, which are automatically generated for all machines - whilst
this is preferred over maintaining known_hosts entries, it requires
additional considerations in your client side setup.
The generated known_hosts file as well as instructions for utilizing the
SSHFP records can be found in this repository (from within the Heroes VPN):
https://gitlab.infra.opensuse.org/infra/ssh_known_hosts
Note the thor.infra.opensuse.org jump servers are already configured for
strict host key checking and DNS verification.
Best,
Georg
Hi!
I found about 760G worth of log file backups from back when Pontifex
still connected to backup.i.o.o.
I assume you don't need it, but since it's a lot of data I rather ask -
can I delete it? :-)
Cheers,
Georg
Hi,
as we are slowly fading out FreeIPA I renamed the
"ca-certificates-freeipa-opensuse" package to "ca-certificates-opensuse".
The new package obsoletes the old one, meaning if you have the
openSUSE:infrastructure repository installed on a machine, you will see
the replacement happen automatically during your next up/dup.
Whilst at it, I also pushed the package to a new dedicated project,
openSUSE:infrastructure:CA [1], in addition to openSUSE:infrastructure.
This might be useful if you want to keep the root certificate up to date
without keeping our big repository on your workstation.
Note that no source/certificate files were changed.
Cheers,
Georg
[1] https://build.opensuse.org/project/show/openSUSE:infrastructure:CA
Hello,
minutes of today's meeting (from
https://etherpad.opensuse.org/p/heroes202404):
2024-04-04 Heroes meeting
Participants: Doug, Georg, Jim, Knurpht, cboltz, Bill, Neal
- discussion about GDPR, Doug requesting clarification on process from SUSE
- example explanation for users about OneTrust (see Etherpad)
post-meeting additions by Georg:
- FreeIPA -> Kanidm migration, all clients moved over (GitLab +
Grafana switched from LDAP to oauth2, shell clients switched from sssd
to kanidm-unixd), account management for now still possible through the
FreeIPA GUI
- Database backups repaired (DC-migration leftover; PostgreSQL
backups to backup.i.o.o, MySQL to mybackup.i.o.o)
Best,
Georg
Hello,
the next Heroes meeting will be on Thursday (2024-04-04) at 18:00 UTC /
20:00 CEST in https://meet.opensuse.org/heroes
Note: Europe switched to summer time, which means the UTC time is now
18:00.
Besides our usual topics, Doug wants to discuss GDPR topics.
Feel free to add more topics to
https://progress.opensuse.org/issues/156874
Note: I have another event that evening, and will probably have to leave
early.
Regards,
Christian Boltz
--
He was the same guy formatting his linux two year ago because his
soundcard didn't work. After a while of consolehacking, google-ing and
investigating he setup windows again (it would be the better solution
... lmao). After windows was setup the soundcard didn't work again and
he plugged in the cable. [Philippe Vogel in suse-security]
