ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੇ VPN ਉੱਤੇ ਤੁਹਾਡਾ SSH ਪਾਸਵਰਡ ਅਸਲ ਵਿੱਚ ਕੌਣ ਵੇਖਦਾ ਹੈ?

ਜਿਸ VPN ਨੂੰ ਤੁਸੀਂ ਆਪ ਨਹੀਂ ਚਲਾਉਂਦੇ, ਉਸ ਰਾਹੀਂ SSH ਸੈਸ਼ਨ ਭੇਜੋ, ਅਤੇ ਪਾਸਵਰਡ ਫਿਰ ਵੀ SSH ਸਰਵਰ ਦਾ ਹੀ ਰਹਿੰਦਾ ਹੈ, ਵਿਚਕਾਰਲੇ ਨੈੱਟਵਰਕ ਦਾ ਨਹੀਂ। ਜੇ ਪ੍ਰਮਾਣਿਤ ਹੋਸਟ ਤੱਕ ਦੀ ਆਵਾਜਾਈ ਠੀਕ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਹੈ, ਤਾਂ ਉਸ ਰਾਹ ਉੱਤੇ ਨਿਸ਼ਕਿਰਿਆ ਨਿਰੀਖਕ ਪਾਸਵਰਡ ਪੜ੍ਹਨ ਯੋਗ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਪਾਉਂਦਾ। ਪਰ ਇੱਕ ਸ਼ਰਤ ਬਦਲੋ, ਅਤੇ ਜਵਾਬ ਬਦਲ ਜਾਂਦਾ ਹੈ: ਅਪ੍ਰਮਾਣਿਤ ਹੋਸਟ, ਕਮਜ਼ੋਰ ਕੀਤੀ ਸਾਈਫ਼ਰ ਸੂਚੀ, ਜਾਂ ਭੰਗ ਹੋਇਆ ਵਰਕਸਟੇਸ਼ਨ—ਸਾਰੇ ਵੱਖਰੇ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ। ਹੇਠਲੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ, ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਰੁਕਣ ਦੀ ਸ਼ਰਤ ਮੰਨੋ।

ਕੁਝ ਵੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਨਾਂ ਲਵੋ

ਪਾਸਵਰਡ ਖੇਤਰ ਪ੍ਰਮਾਣਿਕਤਾ ਸੁਨੇਹੇ ਦੇ ਅੰਦਰ ਸਫ਼ਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਸੁਨੇਹਾ ਐਨਕ੍ਰਿਪਟ ਕੀਤੀ ਆਵਾਜਾਈ ਦੇ ਅੰਦਰ ਸਫ਼ਰ ਕਰਦਾ ਹੈ। ਗੋਪਨੀਯਤਾ ਆਵਾਜਾਈ ਦਾ ਗੁਣ ਹੈ, ਭਾਵ ਇਹ ਇਸ ਗੱਲ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਦੀ ਗੱਲਬਾਤ ਹੋਈ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਉਹ ਤੁਹਾਡੇ ਇਰਾਦੇ ਵਾਲੇ ਹੋਸਟ ਨਾਲ ਹੀ ਹੋਈ ਹੈ ਜਾਂ ਨਹੀਂ। ਲੋਕ ਠੀਕ ਉਹੀ ਦੂਜਾ ਅੱਧ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਧੋਖੇਬਾਜ਼ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਇੱਕੋ ਸਮੇਂ ਗੋਪਨੀ ਅਤੇ ਬੇਕਾਰ ਹੁੰਦਾ ਹੈ। VPN ਲੌਗਇਨ SSH ਹੋਸਟ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਪ੍ਰਦਾਤਾ ਦੀ ਪ੍ਰਤਿਸ਼ਠਾ ਕੁੰਜੀ-ਜਾਂਚ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ।

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਮਨ ਵਿੱਚ ਵੱਖਰੀਆਂ ਰੱਖੋ। ਹੋਸਟ ਕੁੰਜੀ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚੇ। ਪਾਸਵਰਡ ਜਾਂ ਕੁੰਜੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦੱਸਦੀ ਹੈ ਕਿ ਸਰਵਰ ਕਿਹੜੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਦੂਜੇ ਨੂੰ ਸੁਧਾਰਨ ਨਾਲ ਪਹਿਲਾ ਕਦੇ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ।

ਹੋਸਟ ਦੀ ਪਛਾਣ, ਰਿਕਾਰਡ ਅਤੇ ਗੱਲਬਾਤ ਜਾਂਚੋ

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

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

ਸਰਵਰ ਵਾਲੇ ਪਾਸੇ, ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵਾਲੀਆਂ ਫਿੰਗਰਪ੍ਰਿੰਟਾਂ ਯਾਦ ਤੋਂ ਕਾਪੀ ਕਰਨ ਦੀ ਬਜਾਏ ਛਾਪੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਚੈਨਲ ਤੋਂ ਬਾਹਰ ਵੰਡਣਾ ਹੀ ਮੁੱਖ ਗੱਲ ਹੈ; ਹੋਸਟਨਾਮ ਵਾਲੇ ਹੀ ਚੈਟ ਚੈਨਲ ਤੋਂ ਪੇਸਟ ਕੀਤੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਦੋਵੇਂ ਇੱਕੋ ਥਾਂ ਤੋਂ ਆਏ ਹਨ।

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

ਗੱਲਬਾਤ ਵਾਲੇ ਐਲਗੋਰਿਦਮ ਦੋਵੇਂ ਧਿਰਾਂ ਦੇ ਕਟਾਵੇ ਤੋਂ ਆਉਂਦੇ ਹਨ। ਜੇ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਪੁਰਾਣੇ ਯੰਤਰ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਬੇਕਾਰ ਹੋ ਚੁੱਕੀ ਕੁੰਜੀ-ਅਦਲਾ-ਬਦਲੀ ਪਿੰਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਚੋਣ ਹਰ ਉਸ ਹੋਸਟ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਇਹ ਗੱਲ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਵਿਸ਼ਵਵਿਆਪੀ ਨਾ ਬਣਾ ਕੇ ਉਸ ਹੋਸਟ ਤੱਕ ਸੀਮਤ ਕਰੋ।

ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਤਰੀਕੇ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਪੜ੍ਹੋ

ਸਰਵਰ ਕਿਹੜੇ ਪ੍ਰਮਾਣਿਕਤਾ ਤਰੀਕਿਆਂ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਇਹ ਜਾਣਨਾ ਦੱਸਦਾ ਹੈ ਕਿ ਪਾਸਵਰਡ ਅਸਲ ਵਿੱਚ ਕਿਸ ਲਈ ਹੈ। ਜੋ ਹੋਸਟ ਸਿਰਫ਼ ਜਨਤਕ ਕੁੰਜੀਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਉਸ ਕੋਲ ਬਚਾਉਣ ਵਾਲੀ ਪਾਸਵਰਡ ਅਦਲਾ-ਬਦਲੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਜੋ ਹੋਸਟ ਅਜੇ ਵੀ ਪਾਸਵਰਡ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਉਹ ਵਿਰਾਸਤੀ ਡਿਫ਼ਾਲਟ ਦੀ ਬਜਾਏ ਸੁਚੇਤ ਫੈਸਲੇ ਦਾ ਹੱਕਦਾਰ ਹੈ।

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

ਹੋਸਟ-ਕੁੰਜੀ ਚੇਤਾਵਨੀ ਨੂੰ ਘਟਨਾ ਦੇ ਕਦਮ ਵਜੋਂ ਸੰਭਾਲੋ

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

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

ਇਹ ਗਾਈਡ ਕੀ ਕਵਰ ਨਹੀਂ ਕਰਦੀ

ਟ੍ਰੈਫ਼ਿਕ ਵੇਖ ਰਿਹਾ VPN ਆਪਰੇਟਰ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਉੱਤੇ ਸਥਾਨਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਸੌਫ਼ਟਵੇਅਰ ਵਰਗਾ ਨਹੀਂ ਹੈ। ਐਂਡਪੁਆਇੰਟ ਦਾ ਭੰਗ, ਵਿਰੋਧੀ ਬ੍ਰਾਊਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨ ਜਾਂ ਕੀਬੋਰਡ ਲੌਗਰ SSH ਦੀ ਗੱਲਬਾਤ ਤੋਂ ਹੇਠਾਂ ਬੈਠਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਸੁਰੰਗ ਇਹ ਨਹੀਂ ਬਦਲਦੀ। ਜੇ ਵਰਕਸਟੇਸ਼ਨ ਸ਼ੱਕੀ ਹੈ, ਤਾਂ ਕਿਸੇ ਹੋਰ ਬਾਹਰ ਨਿਕਲਣ ਰਾਹੀਂ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਕੇ ਗੋਪਨੀਯਤਾ ਪਰਖਣ ਦੀ ਬਜਾਏ ਘਟਨਾ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਾਲਣਾ ਕਰੋ। ਦੁਬਾਰਾ ਕਨੈਕਟ ਹੋਣਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਰਾਹ ਬਦਲਿਆ ਹੈ, ਅਤੇ ਐਂਡਪੁਆਇੰਟ ਬਾਰੇ ਕੁਝ ਨਹੀਂ।

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