Score:0

more secure way to store username and password for openvpn

cn flag

I've set up an OpenVPN service on my server with username and password authentication and no clients' certificates needed.

I've set the username and password in /etc/passwd and /etc/shadow. now, it's OK to connect with a specific user for OpenVPN (which is client1), but I've tried root (a linux user), it's also OK to be connected.

The question is, is there anyway to store those users for OpenVPN instead of passwd? It's too dangerous I think, or other any group (create a group in /etc/gourp for OpenVPN) to limit them?

server.conf

port 20487
proto udp
dev tun
;dev-node MyTap
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"
duplicate-cn
keepalive 10 120
tls-crypt ta.key 0 # This file is secret
data-ciphers AES-256-GCM
data-ciphers-fallback AES-256-GCM
max-clients 24
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log         /var/log/openvpn/openvpn.log
verb 5


explicit-exit-notify 1

plugin openvpn-plugin-auth-pam.so login
verify-client-cert none
username-as-common-name
script-security 2

client.ovpn

client
dev tun
proto udp
remote [destnation] 20487
auth-user-pass
#verify-client-cert none
#username-as-common-name
data-ciphers-fallback AES-256-GCM
data-ciphers AES-256-GCM
<ca>
-----BEGIN CERTIFICATE-----
ca.crt
-----END CERTIFICATE-----
</ca>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
ta.key
-----END OpenVPN Static key V1-----
</tls-crypt>

/etc/passwd

root:x:0:0:root:/root:/bin/bash
***
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
***
client1:x:1001:65534::/nonexistent:/usr/sbin/nologin

/etc/shadow

root:$y$*:19532:0:99999:7:::
***
nobody:*:19172:0:99999:7:::
***
client1:$y$j9T$K0ubESGFtXD2Imra5pMVJ/$ZUM2HNYn.0X9smrtKEAdgjIclQIdcURbI4xxlTU6tHB:19532:0:99999:7:::
Score:2
fr flag

Don't use the login PAM stack; copy it and create your own. For example, /etc/pam.d/openvpn. Once you have a PAM stack separate from the system login configuration, you can customize it in various ways:

  • e.g. you can insert a pam_succeed_if.so to avoid even trying authentication attempts if the user isn't in a specified group;

  • you can replace pam_unix.so (the /etc/shadow check module) with pam_pwdfile.so which can in fact read a separate password-hash file; (note that pam_pwdfile is a separately installed module)

  • you can keep the authentication part as-is but modify the authorization part, i.e. the account group, so that it rejects users who aren't in a specified group.

    (The auth stack verifies correctness of the supplied credentials, the account stack verifies validity of the account and permissions to access the service.)

For example:

auth requisite pam_succeed_if.so user ingroup vpnusers
auth requisite pam_unix.so
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.