OpenVPN ਸੇਵਾ ਨਿੱਜੀ ਕੁੰਜੀ ਦਾ ਪਾਸਵਰਡ ਮੰਗਣ ਵੇਲੇ ਰੁਕ ਜਾਂਦੀ ਹੈ: ਕਿਵੇਂ ਠੀਕ ਕਰੀਏ
ਸੇਵਾ ਕੋਲ ਟਰਮੀਨਲ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਐਨਕ੍ਰਿਪਟ ਕੀਤੀ ਕੁੰਜੀ ਨੂੰ askpass ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ। ਕੁੰਜੀ ਦਾ ਪਾਸਫ੍ਰੇਜ਼ ਸਰਵਰ ਲੌਗਇਨ ਤੋਂ ਵੱਖ ਰੱਖੋ ਅਤੇ unit ਜਾਂਚੋ।
OpenVPN ਸਥਾਨਕ ਮਸ਼ੀਨ ਉੱਤੇ ਨਿੱਜੀ ਕੁੰਜੀ ਦਾ ਪਾਸਫ੍ਰੇਜ਼ ਮੰਗਦਾ ਹੈ, ਇਸ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲੀ ਲੌਗਇਨ ਫਾਈਲ ਉਸ ਦਾ ਜਵਾਬ ਕਦੇ ਨਹੀਂ ਦਿੰਦੀ। ਸੇਵਾ ਵਿੱਚ ਟਾਈਪ ਕਰਨ ਲਈ ਟਰਮੀਨਲ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਸ਼ੁਰੂਆਤ ਜਾਂ ਤਾਂ ਅਟਕ ਜਾਂਦੀ ਹੈ ਜਾਂ ਕਾਰਨ ਨਹੀਂ ਸਗੋਂ ਇਨਪੁਟ ਦਾ ਨਾਂ ਲੈਣ ਵਾਲੀ ਜਰਨਲ ਐਂਟਰੀ ਨਾਲ ਅਸਫਲ ਹੁੰਦੀ ਹੈ। ਇੱਥੇ ਦੋ ਭੇਤ ਹਨ, ਅਤੇ unit ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਪੜ੍ਹਨਯੋਗ ਸਰੋਤ ਚਾਹੀਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਕ੍ਰਮ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ, ਫਿਰ ਉਹ ਪਛਾਣ ਜਾਂਚਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਹਰ ਫਾਈਲ ਖੋਲ੍ਹਦੀ ਹੈ।
ਦੋਵੇਂ ਬੇਨਤੀਆਂ ਵੱਖਰੀਆਂ ਪਛਾਣੋ
ਕੁੰਜੀ ਦਾ ਪਾਸਫ੍ਰੇਜ਼ ਸਥਾਨਕ ਨਿੱਜੀ ਕੁੰਜੀ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ; ਖਾਤੇ ਦੇ ਪ੍ਰਮਾਣ ਸਰਵਰ ਨਾਲ ਸੈਸ਼ਨ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੇ ਹਨ। ਇਹ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਵੱਖਰੇ ਪਲਾਂ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਸੁਨੇਹੇ ਦਿੰਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣ ਨਾਲ ਲੋਕ ਪਾਸਵਰਡ ਰੀਸੈਟ ਲੱਭਣ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕਿ ਖਾਤਾ ਸ਼ਾਮਲ ਹੀ ਨਹੀਂ ਸੀ। ਕੋਈ ਵੀ ਵਿਕਲਪ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀ ਦਾ ਪਾਠ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਕਿਹੜਾ ਭੇਤ ਗੁੰਮ ਹੈ ਇਸ ਦਾ ਇੱਕੋ ਭਰੋਸੇਯੋਗ ਸੰਕੇਤ ਸ਼ਬਦਾਵਲੀ ਹੈ।
Community OpenVPN 2.x ਵਿੱਚ askpass ਪਹਿਲੀ ਲਾਈਨ ਵਿੱਚ ਕੁੰਜੀ ਦਾ ਪਾਸਫ੍ਰੇਜ਼ ਰੱਖਣ ਵਾਲੀ ਫਾਈਲ ਦੱਸਦਾ ਹੈ, ਅਤੇ auth-user-pass ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਅਗਲੀ ਵਿੱਚ ਪਾਸਵਰਡ ਵਾਲੀ ਫਾਈਲ ਦੱਸਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਫਾਈਲ ਦੂਜੇ ਵਿਕਲਪ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਡੈਸਕਟਾਪ ਐਪ ਜਾਂ NetworkManager ਪ੍ਰੋਫਾਈਲ ਦੋਵੇਂ ਨੂੰ ਆਪਣੇ ਭੇਤ ਭੰਡਾਰ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹਨ, ਜਿਸ ਨੂੰ ਕਮਾਂਡ-ਲਾਈਨ ਕਲਾਇੰਟ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹਦਾ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਪਾਥ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਨੋਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਕਲਾਇੰਟ ਸੰਰਚਿਤ ਕਰ ਰਹੇ ਹੋ।
ਦੋਵੇਂ ਵਿਕਲਪ ਪੜ੍ਹਨਯੋਗ ਫਾਈਲਾਂ ਵੱਲ ਮੋੜੋ
ਦੋਵੇਂ ਇਨਪੁਟ ਚਾਹੁਣ ਵਾਲੇ ਪ੍ਰੋਫਾਈਲ ਕੋਲ ਅੰਤ ਵਿੱਚ ਤਿੰਨ ਫਾਈਲ ਹਵਾਲੇ ਹੁੰਦੇ ਹਨ: ਐਨਕ੍ਰਿਪਟ ਕੀਤੀ ਕੁੰਜੀ, ਉਸ ਨੂੰ ਖੋਲ੍ਹਣ ਵਾਲਾ ਪਾਸਫ੍ਰੇਜ਼ ਅਤੇ ਲੌਗਇਨ ਜੋੜੀ। CA ਅਤੇ ਪਛਾਣ ਜਾਂਚਾਂ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਸਰਵਰ ਕੌਣ ਹੈ ਅਤੇ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹਨ। ਜੇ ਤੈਨਾਤੀ ਖਾਤਾ ਪ੍ਰਮਾਣ ਬਿਲਕੁਲ ਨਹੀਂ ਵਰਤਦੀ, ਤਾਂ auth-user-pass ਜੋੜਨ ਨਾਲ ਇੱਕ ਇਨਪੁਟ ਬਣਦਾ ਹੈ ਜੋ ਕੋਈ ਨਹੀਂ ਦੇ ਸਕਦਾ।
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authਬਿਨਾਂ ਦਲੀਲ ਵਾਲੇ ਵਿਕਲਪ ਪਾਥ ਵਾਲੇ ਵਿਕਲਪਾਂ ਤੋਂ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਸੇਵਾ ਵਿੱਚ ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਬਿਨਾਂ ਦਲੀਲ ਦਾ askpass ਅਜੇ ਵੀ ਕੰਸੋਲ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਵਰਤੋਂਕਾਰ ਨਾਮ ਵਾਲੀ auth-user-pass ਫਾਈਲ ਅਜੇ ਵੀ ਪਾਸਵਰਡ ਬੇਨਤੀ ਉਡੀਕ ਵਿੱਚ ਛੱਡਦੀ ਹੈ। ਕਲਾਇੰਟ ਦੇ ਡੈਮਨ ਬਣਨ ਤੋਂ ਬਾਅਦ ਉਹ ਟਰਮੀਨਲ ਤੋਂ ਇਨਪੁਟ ਮੰਗ ਹੀ ਨਹੀਂ ਸਕਦਾ, ਇਸ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਸੇਵਾ ਉੱਠਦੀ ਨਹੀਂ।
ਪੂਰਨ ਪਾਥ ਕਾਰਜਸ਼ੀਲ ਡਾਇਰੈਕਟਰੀ ਦਾ ਸਵਾਲ ਹਟਾ ਦਿੰਦੇ ਹਨ ਪਰ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦੇ। ਫਿਰ ਮਾਲਕੀ, ਮੋਡ ਅਤੇ ਲੰਘਣਾ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਤਿੰਨੇ ਉਸ ਖਾਤੇ ਦੇ ਆਧਾਰ ਉੱਤੇ ਜਾਂਚੇ ਜਾਂਦੇ ਹਨ ਜਿਸ ਹੇਠ ਪ੍ਰਕਿਰਿਆ ਚੱਲਦੀ ਹੈ।
ਪ੍ਰੋਫਾਈਲ ਤੋਂ ਪਹਿਲਾਂ unit ਦੀ ਸੰਰਚਨਾ ਪੜ੍ਹੋ
ਇੰਸਟੈਂਸ ਕਿਹੜੀ ਸੰਰਚਨਾ ਲੋਡ ਕਰੇਗਾ ਇਹ unit ਤੈਅ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਸੋਧ ਰਹੀ ਫਾਈਲ ਨਹੀਂ। ਉਸ ਦੀ ਕਮਾਂਡ ਲਾਈਨ ਅਤੇ ਸਾਰੇ drop-in ਪੜ੍ਹੋ, ਫਿਰ ਕਾਰਜਸ਼ੀਲ ਡਾਇਰੈਕਟਰੀ ਰਾਹੀਂ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਪ੍ਰੋਫਾਈਲ ਤੱਕ ਜਾਓ। ਕਿਸੇ ਹੋਰ .ovpn ਫਾਈਲ ਵਿੱਚ ਜੋੜਿਆ ਪਾਸਫ੍ਰੇਜ਼ ਹਵਾਲਾ ਇਸ ਇੰਸਟੈਂਸ ਲਈ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਤਿੰਨ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੇ ਕਮਾਂਡ ਇਸ ਦਾ ਬਹੁਤਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਪਹਿਲਾ unit ਅਤੇ ਸਾਰੇ drop-in ਛਾਪਦਾ ਹੈ, ਦੂਜਾ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬੰਨ੍ਹਣ ਵਾਲੀ ਪਛਾਣ ਅਤੇ ਸੈਂਡਬਾਕਸ ਸੈਟਿੰਗਾਂ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ ਇਹ ਕਿ ਪਿਛਲੀ ਸ਼ੁਰੂਆਤ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਸ ਗੱਲ ਦੀ ਸ਼ਿਕਾਇਤ ਕੀਤੀ। ਹੋਸਟ ਉੱਤੇ ਮੌਜੂਦ ਇੰਸਟੈਂਸ ਨਾਮ ਵਰਤੋ:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਦੇ ਆਪਣੇ user, group ਅਤੇ chroot ਵਿਕਲਪਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ। ਘਰ ਡਾਇਰੈਕਟਰੀ ਹੇਠਲੀ ਫਾਈਲ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਵਿੱਚ ਪੜ੍ਹਨਯੋਗ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਘਰ ਡਾਇਰੈਕਟਰੀਆਂ ਲੁਕਾਉਣ ਤੋਂ ਬਾਅਦ ਸੇਵਾ ਦੇ ਅੰਦਰ ਅਦਿੱਖ ਹੋ ਜਾਂਦੀ ਹੈ। systemd ਜਿਸ ਖਾਤੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਉਹ ਹਮੇਸ਼ਾ ਉਹੀ ਖਾਤਾ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਅੰਤ ਵਿੱਚ ਕੁੰਜੀ ਖੋਲ੍ਹਦਾ ਹੈ।
ਸਾਬਤ ਕਰੋ ਕਿ ਰਨਟਾਈਮ ਪਛਾਣ ਦੋਵੇਂ ਫਾਈਲਾਂ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ
ਸਿਰਫ਼ ਮੋਡ ਪੜ੍ਹਨਾ ਕਾਫ਼ੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਪਾਥ ਦੀ ਹਰ ਡਾਇਰੈਕਟਰੀ ਉਸੇ ਪਛਾਣ ਲਈ ਲੰਘਣਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਪਾਥ ਨੂੰ ਹਿੱਸਾ-ਦਰ-ਹਿੱਸਾ ਤੁਰੋ, ਫਿਰ ਪ੍ਰਕਿਰਿਆ ਦੇ ਵਰਤੇ ਖਾਤੇ ਵਜੋਂ ਖੋਲ੍ਹਣ ਦੀ ਜਾਂਚ ਕਰੋ। root ਦੀ ਮਾਲਕੀ ਵਾਲੀ ਅਤੇ ਮੋਡ 600 ਵਾਲੀ ਫਾਈਲ ਸਿਰਫ਼ ਉਦੋਂ ਤੱਕ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਪ੍ਰਕਿਰਿਆ root ਹੈ, ਅਤੇ ਕਈ ਪ੍ਰੋਫਾਈਲਾਂ ਦੀ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਕਟੌਤੀ ਤੋਂ ਬਾਅਦ ਇਹ ਸੱਚ ਨਹੀਂ ਰਹਿੰਦਾ। ਦੋ ਕਮਾਂਡ ਲੰਘਣਾ ਅਤੇ ਖੋਲ੍ਹਣਾ ਦੋਵੇਂ ਢਕਦੇ ਹਨ:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableਪਹਿਲਾ ਕਮਾਂਡ ਹਰ ਹਿੱਸੇ ਦਾ ਮੋਡ ਛਾਪਦਾ ਹੈ ਅਤੇ ਜਿੱਥੇ ਖਾਤਾ ਲੰਘ ਨਹੀਂ ਸਕਦਾ ਉੱਥੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ; ਦੂਜਾ ਇੱਕੋ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਭਾਵ ਕੀ ਰਨਟਾਈਮ ਪਛਾਣ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ। ਦੋਵੇਂ ਫਾਈਲ ਦੀ ਸਮੱਗਰੀ ਨਹੀਂ ਛਾਪਦੇ, ਅਤੇ ਫਾਈਲ ਵਿੱਚ ਪਾਸਫ੍ਰੇਜ਼ ਹੋਣ ਵੇਲੇ ਇਹੀ ਮੁੱਖ ਗੱਲ ਹੈ। ਲੌਗਇਨ ਫਾਈਲ ਲਈ ਵੀ ਜਾਂਚ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਅਕਸਰ ਵੱਖਰੀ ਮਾਲਕੀ ਨਾਲ ਸੰਭਾਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਜੇ ਪ੍ਰਕਿਰਿਆ chroot ਜਾਂ ਸੀਮਤ namespace ਵਰਤਦੀ ਹੈ, ਤਾਂ ਉਹੀ ਜਾਂਚ ਉਸ ਦ੍ਰਿਸ਼ ਦੇ ਅੰਦਰੋਂ ਚਲਾਓ, ਨਹੀਂ ਤਾਂ ਜਵਾਬ ਗਲਤ ਫਾਈਲਸਿਸਟਮ ਦੱਸਦਾ ਹੈ। ਲੁਕਾਈ ਘਰ ਡਾਇਰੈਕਟਰੀ ਹੇਠ ਰੱਖਿਆ ਪਾਸਫ੍ਰੇਜ਼ ਉਸ ਜਾਂਚ ਦੀ ਆਮ ਉਦਾਹਰਨ ਹੈ ਜੋ unit ਤੋਂ ਬਾਹਰ ਪਾਸ ਹੁੰਦੀ ਹੈ ਅਤੇ ਅੰਦਰ ਅਸਫਲ ਹੁੰਦੀ ਹੈ।
ਪਹਿਲੀ ਸ਼ੁਰੂਆਤ ਜਾਂਚੋ, ਫਿਰ ਮੁੜ-ਕਨੈਕਸ਼ਨ
ਇੰਸਟੈਂਸ ਇੱਕ ਵਾਰ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਆਖਰੀ ਨਹੀਂ ਸਗੋਂ ਪਹਿਲੀ ਅਸਫਲਤਾ ਪੜ੍ਹੋ। ਗੁੰਮ ਇਨਪੁਟ ਫਾਈਲ, ਅਸਫਲ ਕੁੰਜੀ ਡੀਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ AUTH_FAILED ਤਿੰਨ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਹਨ, ਤਿੰਨ ਵੱਖਰੀਆਂ ਮੁਰੰਮਤਾਂ ਨਾਲ। ਇਜਾਜ਼ਤ ਦੀ ਚੇਤਾਵਨੀ ਠੀਕ ਕਰਨਾ ਇਸ ਗੱਲ ਦਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕੁੰਜੀ ਖੁੱਲ੍ਹੀ ਸੀ।
ਜਰਨਲ ਦੀ ਲਾਈਨ ਦੱਸਦੀ ਹੈ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਸਥਿਤੀ ਹੈ। ਮੁਰੰਮਤ ਇਸ ਤੋਂ ਨਿਕਲਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਇਨਪੁਟ ਅਸਫਲ ਹੋਇਆ:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
ਫਿਰ ਉਹ ਜੀਵਨ-ਚੱਕਰ ਜੋ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਚਾਹੀਦਾ ਹੈ ਜਾਂਚੋ: ਬੂਟ ਉੱਤੇ ਸ਼ੁਰੂਆਤ ਅਤੇ ਕੋਈ ਵੀ ਸਮਰਥਿਤ ਮੁੜ-ਕਨੈਕਸ਼ਨ, ਸਿਰਫ਼ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਤੋਂ ਹੱਥੀਂ ਸ਼ੁਰੂ ਕਰਨਾ ਨਹੀਂ। auth-nocache ਨਾਲ ਇਨਪੁਟ ਪਹਿਲੀ ਵਰਤੋਂ ਤੋਂ ਬਾਅਦ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਬਾਅਦ ਵਾਲੇ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਨੂੰ ਅਜੇ ਵੀ ਪੜ੍ਹਨਯੋਗ ਸਰੋਤ ਚਾਹੀਦਾ ਹੈ। ਡੈਸਕਟਾਪ ਲੌਗਇਨ ਉੱਤੇ ਖੁੱਲ੍ਹਣ ਵਾਲਾ keyring ਉਸ ਸੇਵਾ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਕਿਸੇ ਦੇ ਲੌਗਇਨ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਹੋਈ ਸੀ, ਅਤੇ ਹੱਥ ਦੀ ਜਾਂਚ ਪਾਸ ਹੋ ਕੇ ਰੀਬੂਟ ਅਸਫਲ ਹੋਣ ਦਾ ਇਹੀ ਆਮ ਕਾਰਨ ਹੈ। ਜੇ ਪਹਿਲੀ ਸ਼ੁਰੂਆਤ ਸਫਲ ਹੋਵੇ ਅਤੇ ਬਾਅਦ ਵਾਲਾ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਅਸਫਲ, ਤਾਂ ਇਜਾਜ਼ਤਾਂ ਦੁਬਾਰਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਘਟਨਾ ਲਈ ਜਰਨਲ ਪੜ੍ਹੋ।
ਕੁੰਜੀ ਦੇ ਕੋਲ ਪਾਸਫ੍ਰੇਜ਼ ਰੱਖਣਾ ਐਨਕ੍ਰਿਪਸ਼ਨ ਜੋ ਦਿੰਦਾ ਹੈ ਉਸ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਫਾਈਲ ਅਤੇ ਉਸ ਦੇ ਬੈਕਅਪ ਸੀਮਿਤ ਰੱਖੋ। ਕੁੰਜੀ ਦਾ ਪਾਸਫ੍ਰੇਜ਼ ਹਟਾਉਣਾ ਗੁੰਮ ਇਨਪੁਟ ਦੀ ਮੁਰੰਮਤ ਨਹੀਂ ਸਗੋਂ ਵੱਖਰਾ ਪ੍ਰਮਾਣ-ਫ਼ੈਸਲਾ ਮੰਨੋ। ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਜਾਂ ਇੰਟਰਐਕਟਿਵ MFA ਉੱਤੇ ਨਿਰਭਰ ਤੈਨਾਤੀ ਨੂੰ ਇਸ ਦਾ ਸਮਰਥਿਤ ਏਜੰਟ ਜਾਂ ਪ੍ਰਬੰਧਨ ਏਕੀਕਰਨ ਚਾਹੀਦਾ ਹੈ; ਸਥਾਈ ਤੌਰ ਉੱਤੇ ਸੰਭਾਲਿਆ ਇੱਕ-ਵਾਰੀ ਕੋਡ ਬਰਾਬਰ ਵਿਕਲਪ ਨਹੀਂ ਹੈ।