Ed Greshko writes:
On 2020-07-23 10:15, Ed Greshko wrote:
On 2020-07-23 09:20, Sam Varshavchik wrote:
Some searching around found some hits suggesting that my
/etc/NetworkManager/system-connections/CONNECTIONNAME should have a [vpn- secrets] section, but mine does not. If I add it, run "nmcli connection reload", "nmcli connection modify", that just removes the [vpn-secrets] section.
Oooopps, sorry.
I did not read far enough.
If your connection is type "Password with Certificatees (TLS)" then
vpn.secrets is not used as the password
is stored per-user.
Having a bad morning..... Coffee ineffective.
I meant to say the "default" is password is stored per-user.
You have to inspect vpn.data.....
If "password-flags = 0" then the password is stored unencrypted and will be in vpn.secrets.
If "password-flags = 1" then the password will be stored in the user's keyring and vpn.secrets will not be used.
That was the missing link.
Of course, "modify vpn.data password_flags=0" just blew away all of my vpn.data. Need to use +vpn.data to reset password_flags.
So, I zapped the connection and reloaded it from scratch, from the VPN provider's config file.
That did the trick, but there might still be a bug in here, somewhere. The first time I configured a VPN connection I had to deal with some SELinux alerts becase /root/.cert's context was unconfined_u:object_r:admin_home_t:s0, and I fixed it by restorecon-ing it to unconfined_u:object_r:home_cert_t:s0
That problem came back, after I recreated the connection. I think I fixed the context on /root/.cert and /root/.cert/nm-openvpn/* files, but not on /root/.cert/nm-openvpn, but at the very least whatever created /root/.cert didn't give it the right context.
I feel like the persistent password stuff needs to be documented somewhere.
Thanks.