|Summary:||OpenVPN (client) auth-user-pass works when in config file, but not on command line|
|Product:||[Fedora] Fedora||Reporter:||Tarquin <tarquin.qualcox>|
|Component:||openvpn||Assignee:||Gwyn Ciesla <gwync>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||21||CC:||davids, gwync, huzaifas, steve|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-12-02 14:10:26 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Tarquin 2015-07-02 13:41:47 UTC
Description of problem: OpenVPN client supports automated password entry from a file. The specific option is "auth-user-pass". When I specify this option inside a config file, it works, and VPN connects. When I specify this option on the command line, it ignores it, and doesn't prompt for it. I have run an strace on it, and the command-line version _never_ checks for the file on-disk, so I'm guessing the command line parsing is wrong somehow. This is a headless RPi2, so I need this to work! And I'm trying to not edit the supplied ovpn config file (as they are third-party supplied), and I can set every other option _except_ this one. Version-Release number of selected component (if applicable): Fedora 21 Version : 2.3.7 Release : 1.fc21 Architecture: armv7hl Source RPM : openvpn-2.3.7-1.fc21.src.rpm How reproducible: Always, I think. I've only got one username & password, and it does it every time for me! Steps to Reproduce: 1. Create a file on-disk, 2 lines, username on 1st line & password on 2nd (bare config lines, just the two words on two lines) 2. Start Openvpn client with a config file containing the line "auth-user-pass /path/to/file.conf" - watch it succeed! 3. Start Openvpn client with "openvpn --auth-user-pass /path/to/file.conf" as one of the command-line options - watch it ignore the option and ask you for a password (and blast systemD ask-pass Wall messages!). Actual results: Password requested interactively from user on command line. Expected results: Password read from on-disk file and auto-connect. Additional info: No X, GUI, or NetworkManager-controlled hilarity, this is just a headless command-line system.
Comment 1 David Sommerseth 2015-07-03 17:32:16 UTC
This isn't really the proper place to report this kind of bug, as this bugzilla primarily focuses on Fedora packaging issues in the package. Please consider to report this issue in the upstream bug tracker: https://community.openvpn.net/openvpn/report (You need to log in to report new issues) Having that said, as a workaround can you try to add your "auth-user-pass" settings in a separate config file and read the file using an additional --config on the command line? The --config option can be used as a kind of include statement, so adding more --config options on the command line should work. openvpn --config thirdparty.conf --config authpass.conf
Comment 2 Tarquin 2015-07-05 12:10:38 UTC
Thanks for the info about bugzilla; I'll report this upstream. And thanks for the tip about a second config file: adding a second file worked a treat. I'm really glad this daemon accepts multiple config files - many don't. In case it's of assistance to anyone else later, I've actually now split my config into 3 config files: 1. Common options (options such as mss-fix, keepalive, etc) - file is applied to multiple different connections. 2. Third-Party Vendor-shipped opvn config file (PIA as provider in this case, but I've looked into other vendors and they are largely identical for config) 3. Connection-specific options to go hand-in-hand with vendor - sets variables such as log file location, PID file location, etc Weirdly, the auth-user-pass option needs to go into config file 2 or 3 - putting in file 1 didn't work for me. Other settings from file 1 applied just fine, just not aks-user-pass. (In case you're wondering why I need a per-connection setting file #3, it's because I'm concurrently running multiple daemons with differing log files and PIDs. As an aside, this is obviously an uncommon case requiring some rather interesting source-route policy-based routing. Anyway, it works really nicely now. :)
Comment 3 Tarquin 2015-07-05 12:35:43 UTC
Comment 4 Fedora End Of Life 2015-11-04 11:16:01 UTC
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 5 Fedora End Of Life 2015-12-02 14:10:36 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.