- 修改 server.conf 設定檔，在最後加上「plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login」。openvpn-auth-pam.so 路徑可能會因為不同發行版而不同。
- 重新啟動 Openvpn Server : /etc/init.d/openvpn restart
- 修改 client.conf 設定檔，在最後面加上「auth-user-pass」。
- 在連線 vpn 時就會出現登打帳號密碼的視窗，使用 Server 上的本機帳號做為驗証的動作。
Using alternative authentication methods
OpenVPN 2.0 includes a feature that allows the OpenVPN server to securely obtain a username and password from a connecting client, and to use that information as a basis for authenticating the client.
To use this authentication method, first add the auth-user-pass directive to the client configuration. It will direct the OpenVPN client to query the user for a username/password, passing it on to the server over the secure TLS channel.
Next, configure the server to use an authentication plugin, which may be a script, shared object, or DLL. The OpenVPN server will call the plugin every time a VPN client tries to connect, passing it the username/password entered on the client. The authentication plugin can control whether or not the OpenVPN server allows the client to connect by returning a failure (1) or success (0) value.
Using Script Plugins
Script plugins can be used by adding the auth-user-pass-verify directive to the server-side configuration file. For example:
auth-user-pass-verify auth-pam.pl via-file
will use the auth-pam.pl perl script to authenticate the username/password of connecting clients. See the description of auth-user-pass-verify in the manual page for more information.
The auth-pam.pl script is included in the OpenVPN source file distribution in the sample-scripts subdirectory. It will authenticate users on a Linux server using a PAM authentication module, which could in turn implement shadow password, RADIUS, or LDAP authentication. auth-pam.pl is primarily intended for demonstration purposes. For real-world PAM authentication, use the openvpn-auth-pam shared object plugin described below.
Using Shared Object or DLL Plugins
Shared object or DLL plugins are usually compiled C modules which are loaded by the OpenVPN server at run time. For example if you are using an RPM-based OpenVPN package on Linux, the openvpn-auth-pam plugin should be already built. To use it, add this to the server-side config file:
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
This will tell the OpenVPN server to validate the username/password entered by clients using the login PAM module.
For real-world production use, it’s better to use the openvpn-auth-pam plugin, because it has several advantages over the auth-pam.pl script:
The shared object openvpn-auth-pam plugin uses a split-privilege execution model for better security. This means that the OpenVPN server can run with reduced privileges by using the directives user nobody, group nobody, and chroot, and will still be able to authenticate against the root-readable-only shadow password file.
OpenVPN can pass the username/password to a plugin via virtual memory, rather than via a file or the environment, which is better for local security on the server machine.
C-compiled plugin modules generally run faster than scripts.
If you would like more information on developing your own plugins for use with OpenVPN, see the README files in the plugin subdirectory of the OpenVPN source distribution.
To build the openvpn-auth-pam plugin on Linux, cd to the plugin/auth-pam directory in the OpenVPN source distribution and run make.
Using username/password authentication as the only form of client authentication
By default, using auth-user-pass-verify or a username/password-checking plugin on the server will enable dual authentication, requiring that both client-certificate and username/password authentication succeed in order for the client to be authenticated.
While it is discouraged from a security perspective, it is also possible to disable the use of client certificates, and force username/password authentication only. On the server:
Such configurations should usually also set:
which will tell the server to use the username for indexing purposes as it would use the Common Name of a client which was authenticating via a client certificate.
Note that client-cert-not-required will not obviate the need for a server certificate, so a client connecting to a server which uses client-cert-not-required may remove the cert and key directives from the client configuration file, but not the ca directive, because it is necessary for the client to verify the server certificate.