ProtectHome ਬਨਾਮ TOTP ਬੀਜ: VPN ਲੌਗਇਨ ਕਿਉਂ ਫੇਲ ਹੁੰਦਾ ਹੈ

ਪ੍ਰਮਾਣਕ ਨਵਾਂ ਛੇ ਅੰਕਾਂ ਵਾਲਾ ਕੋਡ ਦਿਖਾਉਂਦਾ ਹੈ, VPN ਉਸਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਕੋਡ ਤੁਹਾਡੇ ਆਪਣੇ ਸ਼ੈੱਲ ਤੋਂ ਜਾਂਚਣ 'ਤੇ ਠੀਕ ਤਰ੍ਹਾਂ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ। ਇਹੀ ਵਿਰਾਮ ਪੂਰੀ ਕਹਾਣੀ ਹੈ। ਜੋ PAM ਮੌਡਿਊਲ ਨਾਮਾਂਕਣ ਭੇਤ ਖੋਲ੍ਹ ਨਹੀਂ ਸਕਦਾ, ਉਹ ਗਲਤ ਕੋਡ ਵਰਗੀ ਹੀ ਦਿਖਣ ਵਾਲੀ ਅਸਫਲਤਾ ਮੋੜਦਾ ਹੈ, ਅਤੇ ਘਰ ਦੀਆਂ ਡਾਇਰੈਕਟਰੀਆਂ ਲੁਕਾਉਣ ਵਾਲਾ ਸੇਵਾ ਵਾਤਾਵਰਣ ਇਸ ਦਾ ਆਮ ਕਾਰਨ ਹੈ। ਕੋਈ ਵੀ ਇਜਾਜ਼ਤ ਢਿੱਲੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਸ ਸਥਿਤੀ ਵਿੱਚ ਹੋ।

ਇਹ ਤਿੰਨ ਅਸਫਲਤਾਵਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਹੈ?

ਪਹਿਲੀ ਉਹ ਭੇਤ ਹੈ ਜੋ ਮੌਡਿਊਲ ਬਿਲਕੁਲ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ। ਦੂਜੀ ਉਹ ਭੇਤ ਹੈ ਜੋ ਉਹ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਪਰ ਅੱਪਡੇਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਤੀਜੀ ਉਹ ਕੋਡ ਹੈ ਜੋ ਸੱਚਮੁੱਚ ਗਲਤ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਘੜੀ ਦੇ ਵਹਾਅ ਜਾਂ ਦੁਬਾਰਾ ਵਰਤੇ ਮੁੱਲ ਕਾਰਨ।

ਇੱਕ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ ਲਈ ਸੇਵਾ ਜਰਨਲ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰਮਾਣੀਕਰਨ ਲੌਗ ਪੜ੍ਹ ਕੇ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪਲੱਗਇਨ ਕਿਹੜੀ PAM ਸੇਵਾ ਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹ ਸੇਵਾ ਕਿਹੜੀ ਮੌਡਿਊਲ ਲਾਈਨ ਵਰਤਦੀ ਹੈ। ਆਮ ਪ੍ਰਮਾਣੀਕਰਨ ਅਸਫਲਤਾ ਸੁਨੇਹਾ ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਸਫਲ ਹੱਥੀਂ ਟੈਸਟ ਵੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਸ਼ੈੱਲ ਸੇਵਾ ਦਾ ਵਾਤਾਵਰਣ ਨਹੀਂ ਹੈ।

ਜਦੋਂ ਸਿਰਫ਼ ਸੇਵਾ ਫੇਲ ਹੁੰਦੀ ਹੈ ਤਾਂ ਯੂਨਿਟ ਦਾ ਫਾਇਲਸਿਸਟਮ ਦ੍ਰਿਸ਼ ਆਮ ਦੋਸ਼ੀ ਹੁੰਦਾ ਹੈ।

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

ਵਿਕਲਪ A: ਭੇਤ ਨੂੰ ਘਰ ਤੋਂ ਬਾਹਰ ਲੈ ਜਾਓ

ਜਦੋਂ ਸੇਵਾ /home ਲੁਕਾਉਂਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਉਹ ਸੁਰੱਖਿਆ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਭੇਤ ਨੂੰ ਉੱਥੇ ਸੰਭਾਲੋ ਜਿੱਥੇ ਉਹ ਉਸਨੂੰ ਦੇਖ ਸਕੇ। ਮੌਡਿਊਲ secret= ਪਾਥ ਅਤੇ ਫਾਇਲ ਕਾਰਵਾਈਆਂ ਕਰਨ ਵਾਲਾ user= ਖਾਤਾ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜੋ ਕੇਂਦਰੀ ਭੰਡਾਰ ਨੂੰ ਕਈ ਪਛਾਣਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਦਿੰਦਾ ਹੈ।

ਇਹ ਸਾਫ਼-ਸੁਥਰਾ ਵਿਕਲਪ ਹੈ, ਅਤੇ ਇਸੇ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਧਿਆਨ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਾਂਝਾ ਭੰਡਾਰ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਹਰ ਖਾਤੇ ਦੀ ਸੁਰੱਖਿਆ ਸੀਮਾ ਬਣਾ ਦਿੰਦਾ ਹੈ।

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਗੱਲਾਂ ਜਾਂਚੋ: ਖਾਤਾ ਮੌਜੂਦ ਹੈ, ਮੌਡਿਊਲ ਦੀ ਕਾਰਜ ਪ੍ਰਕਿਰਿਆ ਉਸ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ, ਅਤੇ ਫਾਇਲਾਂ ਪਾਬੰਦੀਸ਼ੁਦਾ ਮੋਡਾਂ ਨਾਲ ਉਸ ਦੀ ਮਾਲਕੀ ਵਿੱਚ ਹਨ। user= ਨਾਲ ~ ਜਾਂ ਘਰ-ਚਰ ਪਾਥ ਨਾ ਵਰਤੋ, ਅਤੇ ਪਾਥ ਕੰਮ ਕਰਾਉਣ ਲਈ ਮੌਡਿਊਲ ਦੀਆਂ ਮਾਲਕੀ ਜਾਂਚਾਂ ਬੰਦ ਨਾ ਕਰੋ। ਪਾਸਵਰਡ ਪੜਾਅ ਅਤੇ ਬਾਕੀ ਸਟੈਕ ਅਭੇਦ ਰੱਖੋ।

ਵਿਕਲਪ B: ਫਾਇਲ ਰਹਿਣ ਦਿਓ ਅਤੇ ਪਾਥ ਖੋਲ੍ਹੋ

ਜੇ ਭੇਤ ਵਰਤੋਂਕਾਰ ਦੇ ਘਰ ਵਿੱਚ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਯੂਨਿਟ ਨੂੰ ਅਜਿਹਾ ਦ੍ਰਿਸ਼ ਚਾਹੀਦਾ ਹੈ ਜੋ ਹੋਸਟ ਦੇ ਹਰ ਘਰ ਨੂੰ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਉਸ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਸ਼ਾਮਲ ਕਰੇ। drop-in ਸੈਂਡਬਾਕਸ ਕੀਤੇ ਘਰ ਹੇਠ ਸੰਕਰੇ ਘੇਰੇ ਦਾ ਬਾਈਂਡ ਮਾਊਂਟ ਜੋੜ ਸਕਦਾ ਹੈ।

ਇਹ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਮਾਲਕੀ ਨੂੰ ਮਾਡਲ ਵਜੋਂ ਰੱਖਦਾ ਹੈ, ਪਰ ਸੈਂਡਬਾਕਸ ਬਦਲਣ 'ਤੇ ਸਮੀਖਿਆ ਕਰਨੀ ਪੈਣ ਵਾਲੀ ਯੂਨਿਟ ਤਬਦੀਲੀ ਦੀ ਕੀਮਤ 'ਤੇ।

ਦੋ ਸੀਮਾਵਾਂ ਸੌਖਿਆਂ ਖੁੰਝ ਜਾਂਦੀਆਂ ਹਨ। ਸੈਂਡਬਾਕਸ ਵੱਲੋਂ ਲੁਕਾਈ ਡਾਇਰੈਕਟਰੀ ਹੇਠ ਜੋੜਿਆ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲਾ ਪਾਥ ਉਸਨੂੰ ਖੋਲ੍ਹਦਾ ਨਹੀਂ, ਕਿਉਂਕਿ ਮਾਪੇ ਡਾਇਰੈਕਟਰੀ ਉੱਥੇ ਹੀ ਨਹੀਂ ਹੈ। ਅਤੇ ਜੇ ਮੌਡਿਊਲ ਨੂੰ ਸਥਿਤੀ ਅੱਪਡੇਟ ਕਰਨੀ ਹੈ ਤਾਂ ਮਾਊਂਟ ਲਿਖਣਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਅਗਲਾ ਵਿਕਲਪ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ। drop-in ਨੂੰ /usr/lib ਹੇਠਲੇ ਪੈਕੇਜ ਕੀਤੇ ਯੂਨਿਟ ਨੂੰ ਸੋਧਣ ਦੀ ਥਾਂ ਵੱਖਰੀ ਫਾਇਲ ਵਜੋਂ ਲਿਖੋ, ਤਾਂ ਜੋ ਪੈਕੇਜ ਅੱਪਗ੍ਰੇਡ ਉਸਨੂੰ ਚੁੱਪਚਾਪ ਰੱਦ ਨਾ ਕਰੇ।

ਵਿਕਲਪ C: ਸੈਂਡਬਾਕਸ ਰੱਖੋ ਅਤੇ ਸਥਿਤੀ ਲਿਖਤਾਂ ਸੁਧਾਰੋ

ਭੇਤ ਪੜ੍ਹਨਾ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਸਿਰਫ਼ ਅੱਧਾ ਹੈ। ਮੌਡਿਊਲ ਸਮਾਂ-ਵਿਚਲਨ ਜਾਣਕਾਰੀ, ਮੁੜ-ਚਲਾਉਣ ਸੁਰੱਖਿਆ ਜਾਂ ਕਾਊਂਟਰ ਮੁੜ ਲਿਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਪੜ੍ਹਨ ਜਾਂਚ ਪਾਸ ਕਰਨ ਵਾਲੀ ਫਾਇਲ ਲਿਖਣ ਵਿੱਚ ਫਿਰ ਵੀ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।

ਉਹ ਅਸਫਲਤਾ ਇਸ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਨਹੀਂ, ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਮਾੜੇ ਕੋਡ ਵਾਂਗ ਦਿਖਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਘੜੀ ਦੇ ਵਹਾਅ ਨਾਲ ਗਲਤ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ।

ਪੂਰੇ ਘਰ ਨੂੰ ਲਿਖਣਯੋਗ ਬਣਾਉਣ ਦੀ ਥਾਂ ਇਸਨੂੰ ਆਪਣੀ ਲਿਖਣਯੋਗ ਡਾਇਰੈਕਟਰੀ ਦਿਓ ਅਤੇ ਭੇਤ ਦਾ ਪਾਥ ਉੱਥੇ ਨਿਰਦੇਸ਼ਿਤ ਕਰੋ। ਡਾਇਰੈਕਟਰੀ ਦਾ ਮਾਲਕ, ਫਾਇਲਸਿਸਟਮ ਦੀ ਖਾਲੀ ਜਗ੍ਹਾ ਅਤੇ ਯੂਨਿਟ ਕਿਤੇ ਹੋਰ ਲਿਖਤਾਂ ਸੀਮਿਤ ਕਰਦੀ ਹੈ ਕਿ ਨਹੀਂ, ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਫਿਰ ਲਗਾਤਾਰ ਦੋ ਲੌਗਇਨ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਦੂਜਾ ਲਿਖਣ ਪਾਥ ਸਿੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਪਹਿਲਾ ਸਿਰਫ਼ ਪੜ੍ਹਨਾ।

ਆਪਣੇ ਆਪ ਵਜੋਂ ਨਹੀਂ, ਸੇਵਾ ਵਜੋਂ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਹਰ ਮਹੱਤਵਪੂਰਨ ਜਾਂਚ ਯੂਨਿਟ ਦੇ ਸੈਂਡਬਾਕਸ ਅੰਦਰ ਯੂਨਿਟ ਦੀ ਪਛਾਣ ਨਾਲ ਚੱਲਣੀ ਚਾਹੀਦੀ ਹੈ।

root ਵਜੋਂ ਸਫਲ ਹੋਣ ਵਾਲਾ ਆਦੇਸ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਫਾਇਲ ਮੌਜੂਦ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਅਸਲ ਸੇਵਾ ਰਾਹੀਂ ਲੌਗਇਨ ਦੱਸਦਾ ਹੈ ਕਿ ਮੌਡਿਊਲ ਭੇਤ ਪੜ੍ਹ, ਵਰਤ ਅਤੇ ਲੋੜੀਂਦਾ ਵਾਪਸ ਲਿਖ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਅੰਤ ਵਿੱਚ, ਲੋੜ ਨੂੰ ਅਭੇਦ ਰੱਖੋ। ਜ਼ੀਰੋ-ਪਾਸਵਰਡ ਵਿਕਲਪ ਜੋੜਨਾ, ਸਿਰਫ਼-ਪੜ੍ਹਨ ਅਸਫਲਤਾਵਾਂ ਸਵੀਕਾਰ ਕਰਨਾ ਜਾਂ ਸੈਂਡਬਾਕਸ ਹਟਾਉਣਾ—ਇਹ ਸਾਰੇ ਨੀਤੀ ਬਦਲ ਕੇ ਲੱਛਣ ਮਿਟਾ ਦੇਣਗੇ। ਜਿਸਨੂੰ ਕੋਡ ਪੇਸ਼ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਉਸਨੂੰ ਭੇਤ ਅਪ੍ਰਾਪਤ ਹੋਣ 'ਤੇ ਵੀ ਰੱਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।