I'm trying to save an OpenVPN password via nmcli, in Fedora 32. I believe I should be executing:
nmcli connection modify CONNECTIONNAME vpn.secrets "password=[PASSWORD]"
So I execute this as root, and this initially produces very promising noises in /var/log/messages:
Jul 22 20:41:35 jack NetworkManager[1525]: <info> [1595464895.3350] audit: op="connection-update" uuid="UUID" name="CONNECTIONNAME" args="vpn.secrets" pid=67812 uid=0 result="success"
However, the password appears to disappear into a black hole:
nmcli --show-secrets connection CONNECTIONNAME | grep secrets vpn.secrets: --
And nmcli connection up fails because there's no password.
The VPN connection's configuration was imported from the VPN provider's supplied ovpn file, via "nmcli connection import".
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.
What would be the right way to do this?
On 2020-07-23 09:20, Sam Varshavchik wrote:
I'm trying to save an OpenVPN password via nmcli, in Fedora 32. I believe I should be executing:
nmcli connection modify CONNECTIONNAME vpn.secrets "password=[PASSWORD]"
So I execute this as root, and this initially produces very promising noises in /var/log/messages:
Jul 22 20:41:35 jack NetworkManager[1525]: <info> [1595464895.3350] audit: op="connection-update" uuid="UUID" name="CONNECTIONNAME" args="vpn.secrets" pid=67812 uid=0 result="success"
However, the password appears to disappear into a black hole:
nmcli --show-secrets connection CONNECTIONNAME | grep secrets vpn.secrets: --
And nmcli connection up fails because there's no password.
The VPN connection's configuration was imported from the VPN provider's supplied ovpn file, via "nmcli connection import".
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.
What would be the right way to do this?
When you do....
nmcli connection show CONNECTNAME
What is the value of
802-11-wireless-security.psk-flags?
On 2020-07-23 09:45, Ed Greshko wrote:
On 2020-07-23 09:20, Sam Varshavchik wrote:
I'm trying to save an OpenVPN password via nmcli, in Fedora 32. I believe I should be executing:
nmcli connection modify CONNECTIONNAME vpn.secrets "password=[PASSWORD]"
So I execute this as root, and this initially produces very promising noises in /var/log/messages:
Jul 22 20:41:35 jack NetworkManager[1525]: <info> [1595464895.3350] audit: op="connection-update" uuid="UUID" name="CONNECTIONNAME" args="vpn.secrets" pid=67812 uid=0 result="success"
However, the password appears to disappear into a black hole:
nmcli --show-secrets connection CONNECTIONNAME | grep secrets vpn.secrets: --
And nmcli connection up fails because there's no password.
The VPN connection's configuration was imported from the VPN provider's supplied ovpn file, via "nmcli connection import".
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.
What would be the right way to do this?
When you do....
nmcli connection show CONNECTNAME
What is the value of
802-11-wireless-security.psk-flags?
Also, what is the value of...
802-11-wireless-security.key-mgmt
Ed Greshko writes:
On 2020-07-23 09:45, Ed Greshko wrote:
On 2020-07-23 09:20, Sam Varshavchik wrote:
I'm trying to save an OpenVPN password via nmcli, in Fedora 32. I believe
I should be executing:
nmcli connection modify CONNECTIONNAME vpn.secrets "password=[PASSWORD]"
So I execute this as root, and this initially produces very promising
noises in /var/log/messages:
Jul 22 20:41:35 jack NetworkManager[1525]: <info> [1595464895.3350]
audit: op="connection-update" uuid="UUID" name="CONNECTIONNAME" args="vpn.secrets" pid=67812 uid=0 result="success"
However, the password appears to disappear into a black hole:
nmcli --show-secrets connection CONNECTIONNAME | grep secrets vpn.secrets: --
And nmcli connection up fails because there's no password.
The VPN connection's configuration was imported from the VPN provider's
supplied ovpn file, via "nmcli connection import".
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.
What would be the right way to do this?
When you do....
nmcli connection show CONNECTNAME
What is the value of
802-11-wireless-security.psk-flags?
Also, what is the value of...
802-11-wireless-security.key-mgmt
None of them are set.
This is on an edge server with two Ethernet connections. A default route to the Internet, and a /24 route to the LAN. No wireless here.
The password in question is the VPN provider's password.
Here are all the properties. I masked a few bits in the vpn.data setting. With --show-secrets, vpn-secrets is always just a --. I can
nmcli connection modify CONNECTIONNAME vpn.secrets anything=whatever
And this gets parroted back to me by --show-secrets. But password=whatever is stubbornly ignored, not saved, and not used. If I manually hack it into the /etc/NetworkManager/system-connections/CONNECTIONNAME.nmconnection, and nmcli connection reload it, it gets stubbornly ignored. I cannot find any way to start the VPN other than with the --ask option, and prompt for the password, every time.
connection.id: CONNECTIONNAME connection.uuid: d5a4c828-ba14-46bb-866b-9d1b66a50668 connection.stable-id: -- connection.type: vpn connection.interface-name: -- connection.autoconnect: yes connection.autoconnect-priority: 0 connection.autoconnect-retries: -1 (default) connection.multi-connect: 0 (default) connection.auth-retries: -1 connection.timestamp: 1595467636 connection.read-only: no connection.permissions: -- connection.zone: -- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: -- connection.gateway-ping-timeout: 0 connection.metered: unknown connection.lldp: default connection.mdns: -1 (default) connection.llmnr: -1 (default) connection.wait-device-timeout: -1 ipv4.method: auto ipv4.dns: -- ipv4.dns-search: -- ipv4.dns-options: -- ipv4.dns-priority: 0 ipv4.addresses: -- ipv4.gateway: -- ipv4.routes: -- ipv4.route-metric: -1 ipv4.route-table: 0 (unspec) ipv4.routing-rules: -- ipv4.ignore-auto-routes: no ipv4.ignore-auto-dns: yes ipv4.dhcp-client-id: -- ipv4.dhcp-iaid: -- ipv4.dhcp-timeout: 0 (default) ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.dhcp-fqdn: -- ipv4.dhcp-hostname-flags: 0x0 (none) ipv4.never-default: no ipv4.may-fail: yes ipv4.dad-timeout: -1 (default) ipv6.method: auto ipv6.dns: -- ipv6.dns-search: -- ipv6.dns-options: -- ipv6.dns-priority: 0 ipv6.addresses: -- ipv6.gateway: -- ipv6.routes: -- ipv6.route-metric: -1 ipv6.route-table: 0 (unspec) ipv6.routing-rules: -- ipv6.ignore-auto-routes: no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy ipv6.ra-timeout: 0 (default) ipv6.dhcp-duid: -- ipv6.dhcp-iaid: -- ipv6.dhcp-timeout: 0 (default) ipv6.dhcp-send-hostname: yes ipv6.dhcp-hostname: -- ipv6.dhcp-hostname-flags: 0x0 (none) ipv6.token: -- vpn.service-type: org.freedesktop.NetworkManager.openvpn vpn.user-name: MYUSERNAME vpn.data: auth = SHA512, ca = PEMFILEPATH, cipher = AES-256-CBC, comp-lzo = no-by-default, connection-type = password, dev = tun, mssfix = 1450, password-flags = 1, ping = 15, ping-restart = 0, remote = OP_ADDRESS, remote-cert-tls = server, remote-random = yes, reneg-seconds = 0, ta = /root/.cert/PEMFILE, ta-dir = 1, tunnel-mtu = 1500 vpn.secrets: <hidden> vpn.persistent: no vpn.timeout: 0 proxy.method: none proxy.browser-only: no proxy.pac-url: -- proxy.pac-script: --
On 2020-07-23 10:25, Sam Varshavchik wrote:
vpn.data: auth = SHA512, ca = PEMFILEPATH, cipher = AES-256-CBC, comp-lzo = no-by-default, connection-type = password, dev = tun, mssfix = 1450, password-flags = 1, ping = 15, ping-restart = 0, remote = OP_ADDRESS, remote-cert-tls = server, remote-random = yes, reneg-seconds = 0, ta = /root/.cert/PEMFILE, ta-dir = 1, tunnel-mtu = 1500 vpn.secrets: <hidden>
OK.... You've probably seen my other responses by now. Fragmented as they are.
You have "password-flags = 1"
This means the password is stored in the user's key ring on a per-user basis.
I haven't tried changing this via nmcli. But, will investigate.
Ed Greshko writes:
On 2020-07-23 10:25, Sam Varshavchik wrote:
vpn.data: auth = SHA512, ca = PEMFILEPATH, cipher = AES-256- CBC, comp-lzv = no-by-default, connection- type = password, dev = tun, mssfix = 1450, password- flags = 1, ping = 15, ping-restart = 0, remote = OP_ADDRESS, remote-cert- tls = server, remote-random = yes, reneg- seconds = 0, ta = /root/.cert/PEMFILE, ta-dir = 1, tunnel-mtu = 1500
vpn.secrets: <hidden>
OK.... You've probably seen my other responses by now. Fragmented as they are.
You have "password-flags = 1"
This means the password is stored in the user's key ring on a per-user basis.
I haven't tried changing this via nmcli. But, will investigate.
Yup, thanks. This is doable. The magic incantation is:
nmcli connection modify "$conn" +vpn.data password-flags=0 \ vpn.user-name "$USERNAME" vpn.secrets password="$PASSWORD"
This needs to be documented somewhere, I would guess in the NetworkManager- openvpn package, which installs absolutely no documentation whatsoever.
nm-settings(5) doesn't really go into what vpn.data and vpn.secrets have. This is bog standard OpenVPN, so it's reasonable to have something scribbled in the NetworkManager-openvpn package, even something that gets tossed next to the README that's already in there.
On 2020-07-23 10:49, Sam Varshavchik wrote:
Ed Greshko writes:
On 2020-07-23 10:25, Sam Varshavchik wrote:
vpn.data: auth = SHA512, ca = PEMFILEPATH, cipher = AES-256-CBC, comp-lzv = no-by-default, connection-type = password, dev = tun, mssfix = 1450, password-flags = 1, ping = 15, ping-restart = 0, remote = OP_ADDRESS, remote-cert-tls = server, remote-random = yes, reneg-seconds = 0, ta = /root/.cert/PEMFILE, ta-dir = 1, tunnel-mtu = 1500 vpn.secrets: <hidden>
OK.... You've probably seen my other responses by now. Fragmented as they are.
You have "password-flags = 1"
This means the password is stored in the user's key ring on a per-user basis.
I haven't tried changing this via nmcli. But, will investigate.
Yup, thanks. This is doable. The magic incantation is:
nmcli connection modify "$conn" +vpn.data password-flags=0 \ vpn.user-name "$USERNAME" vpn.secrets password="$PASSWORD"
This needs to be documented somewhere, I would guess in the NetworkManager-openvpn package, which installs absolutely no documentation whatsoever. nm-settings(5) doesn't really go into what vpn.data and vpn.secrets have. This is bog standard OpenVPN, so it's reasonable to have something scribbled in the NetworkManager-openvpn package, even something that gets tossed next to the README that's already in there.
What also needs to be documented, or I need to get better at searching, is what are the possible values for "option" when doing a modify of vpn.secrets and flags=1.
"help" was of no "help".
Error: failed to modify vpn.secrets: 'help' is not valid; use <option>=<value>.
Ed Greshko writes:
What also needs to be documented, or I need to get better at searching, is what are the possible values for "option" when doing a modify of vpn.secrets and flags=1.
"help" was of no "help".
Error: failed to modify vpn.secrets: 'help' is not valid; use
<option>=<value>.
I was able to figure out that part. Searching for "nmcli save vpn password" gives https://unix.stackexchange.com/questions/335999/use-nmcli-to-modify- vpn-password as the second result, that shows this incantation, but without password-flags set correctly, this does nothing, and, most importantly, without providing any kind of feedback to the user. The command just exits quietly, without any diagnostic.
There were a bunch of hits that said to manually add [vpn-secrets], like https://serverfault.com/questions/816714/how-do-i-supply-a-password-to- networkmanager-openconnect-automatically and looking at mine's, that's where the password is. But unless
password-flags=0
also exists in the [vpn] section, this does nothing. Either one of two things would've made things smoother: either better documentation, or better feedback from "nmcli connection modify", something other than quietly returning without any messages, but doing nothing.
On 2020-07-23 20:45, Sam Varshavchik wrote:
Ed Greshko writes:
What also needs to be documented, or I need to get better at searching, is what are the possible values for "option" when doing a modify of vpn.secrets and flags=1.
"help" was of no "help".
Error: failed to modify vpn.secrets: 'help' is not valid; use <option>=<value>.
I was able to figure out that part. Searching for "nmcli save vpn password" gives https://unix.stackexchange.com/questions/335999/use-nmcli-to-modify-vpn-pass... as the second result, that shows this incantation, but without password-flags set correctly, this does nothing, and, most importantly, without providing any kind of feedback to the user. The command just exits quietly, without any diagnostic.
There were a bunch of hits that said to manually add [vpn-secrets], like https://serverfault.com/questions/816714/how-do-i-supply-a-password-to-netwo... and looking at mine's, that's where the password is. But unless
password-flags=0
also exists in the [vpn] section, this does nothing. Either one of two things would've made things smoother: either better documentation, or better feedback from "nmcli connection modify", something other than quietly returning without any messages, but doing nothing.
Right.
My only point/thought was that <option>=<value> could me more option than just password. And, even if there wasn't, "option" should be documented.
In any event all is good and the BZ for the selinux context is getting rapid attention. :-)
On 2020-07-23 10:49, Sam Varshavchik wrote:
This means the password is stored in the user's key ring on a per-user basis.
I haven't tried changing this via nmcli. But, will investigate.
FWIW....
nmcli connection modify US-East-NJ vpn.secrets "password=something"
Works just fine for a logged-in user.
Ed Greshko writes:
On 2020-07-23 10:49, Sam Varshavchik wrote:
This means the password is stored in the user's key ring on a per-
user basis.
I haven't tried changing this via nmcli. But, will investigate.
FWIW....
nmcli connection modify US-East-NJ vpn.secrets "password=something"
Works just fine for a logged-in user.
Well, I ssh-ed in as root, using an ssh cert. I guess that doesn't count.
This is in a server context. The server wants a VPN tunnel of its own, rather than any particular user.
It's not clear to me if it's NetworkManager itself that defaults to a user- set password. Maybe there's something in the openvpn configuration file that chooses whether to set up a user-centric or server-centric VPN, and this VPN provider is supplying user-centric configuration files.
And I was able to reproduce the broken SELinux context, starting from scratch. "nmcli import" creates /root/.cert, if it does not exist, with a broken SELinux context. Bug 1859974.
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.
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.
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.