SSH ਕੁੰਜੀ ਦਾ ਪਾਸਫ਼ਰੇਜ਼ ਫ਼ਾਈਲ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਰਸਤੇ ਦੀ ਨਹੀਂ

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

ਪਾਸਫ਼ਰੇਜ਼ ਫ਼ਾਈਲ ਦਾ ਹੈ

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

OpenSSH ਦਾ ssh-keygen ਦਸਤਾਵੇਜ਼ ਪਾਸਫ਼ਰੇਜ਼ਾਂ ਨਾਲ ਨਜਿੱਠਣ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ -p ਸਵਿੱਚ ਵੀ ਹੈ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਕੁੰਜੀ ਉੱਤੇ ਨਵਾਂ ਪਾਸਫ਼ਰੇਜ਼ ਸੈੱਟ ਕਰਦਾ ਹੈ।

ਮੌਜੂਦ ਕੁੰਜੀ ਲਈ ਹੁਕਮ ਦਾ ਰੂਪ ਸਧਾਰਨ ਹੈ, ਅਤੇ ਇਹ ਫ਼ਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ:

ssh-keygen -p -f ~/.ssh/id_ed25519

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

ਨਕਲ ਲੈਪਟਾਪ ਅਤੇ ਟਨਲ ਨਾਲੋਂ ਵੱਧ ਚਿਰ ਰਹਿੰਦੀ ਹੈ

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

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

ਇਸ ਲਈ ਲੀਕ ਹੋਈ ਨਿੱਜੀ ਕੁੰਜੀ ਨੂੰ ਨੈੱਟਵਰਕ ਘਟਨਾ ਨਾ ਮੰਨੋ, ਪਛਾਣ ਦੀ ਘਟਨਾ ਮੰਨੋ। ਸਵੀਕਾਰ ਕੀਤੀ ਕੁੰਜੀ ਨੂੰ ਉਹਨਾਂ ਸਰਵਰਾਂ ਅਤੇ ਦਾਖਲਾ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਹਟਾਓ ਜਾਂ ਬਦਲੋ ਜਿਹਨਾਂ ਦੀ ਇਹ ਹੈ। VPN ਰੋਕਣਾ ਇੱਕ ਪਲ ਵਿੱਚ ਇੱਕ ਰਸਤਾ ਸੀਮਤ ਕਰਦਾ ਹੈ; ਇਹ ਰੱਦ ਕਰਨਾ ਨਹੀਂ।

ਅਨਲਾਕ ਕਰਨਾ ਭੇਦ ਨੂੰ ਏਜੰਟ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ

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

ssh-agent ਆਪਣੇ -t ਵਿਕਲਪ ਰਾਹੀਂ ਸੀਮਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੋਈ ਪਛਾਣ ਕਿੰਨੀ ਦੇਰ ਲੋਡ ਰਹੇ, ਅਤੇ ਪ੍ਰਤੀ-ਪਛਾਣ ਸੈਟਿੰਗ ਉਸ ਸੀਮਾ ਨੂੰ ਲੰਘ ਸਕਦੀ ਹੈ। VPN ਡਿਸਕਨੈਕਟ ਹੋਣ ਉੱਤੇ ਹਰ ਲੋਡ ਕੀਤੀ ਕੁੰਜੀ ਭੁੱਲ ਜਾਂਦੀ ਹੈ ਮੰਨਣ ਦੀ ਥਾਂ ਉਸ ਏਜੰਟ ਲਈ ਨੀਤੀ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ।

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

ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸੂਚੀ ਬਣਾਓ ਕਿ ਏਜੰਟ ਕੋਲ ਹੁਣ ਕੀ ਹੈ:

ssh-add -l

ਨਿਗਰਾਨੀ ਤੋਂ ਬਿਨਾਂ ਕੰਮਾਂ ਨੂੰ ਆਪਣੀ ਯੋਜਨਾ ਚਾਹੀਦੀ ਹੈ

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

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

ਸਰਵਰ ਦੀ ਹੋਸਟ-ਪਛਾਣ ਜਾਂਚ ਅਤੇ ਇਸ ਦੀਆਂ ਖਾਤਾ ਪਾਬੰਦੀਆਂ ਵੀ ਰੱਖੋ। VPN ਰਸਤਾ ਤੁਹਾਨੂੰ ਨਿੱਜੀ ਰਾਹ ਦਿੰਦਾ ਹੈ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਤੁਸੀਂ ਜਿਸ ਵੀ SSH ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹੋ ਉਹੀ ਲੋੜੀਂਦਾ ਹੋਸਟ ਹੈ। ਸਰੋਤੇ ਅਤੇ ਹੋਸਟ ਕੁੰਜੀ ਦੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਨੂੰ ਕੁੰਜੀ ਵਾਂਗ ਹੀ ਉਸੇ ਸੂਚੀ ਵਿੱਚ ਦਰਜ ਕਰੋ।

ਸੀਮਾਵਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਹਰ ਸੀਮਾ ਨੂੰ ਉਸਦੇ ਆਪਣੇ ਸਵਾਲ ਨਾਲ ਪਰਖੋ। ਪਾਸਫ਼ਰੇਜ਼ ਤੋਂ ਬਿਨਾਂ ਫ਼ਾਈਲ ਖੁੱਲ੍ਹਦੀ ਹੈ? ਡਿਸਕਨੈਕਟ ਤੋਂ ਬਾਅਦ ਵੀ ਏਜੰਟ ਪਛਾਣ ਰੱਖਦਾ ਹੈ? ਸਰਵਰ ਅਜੇ ਵੀ ਜਨਤਕ ਕੁੰਜੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ?

ਦੋ ਹੁਕਮ ਪਹਿਲੇ ਅਤੇ ਤੀਜੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

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