SSH क्या है और यह कैसे काम करता है?

SSH क्या है?

SSH (secure shell) एक प्रोटोकॉल है जिसका उपयोग किसी अन्य स्थान पर स्थित कंप्यूटर में लॉग इन करने और एक एन्क्रिप्टेड कनेक्शन के माध्यम से उस पर कमांड चलाने के लिए किया जाता है। आप जो टाइप करते हैं वह रिमोट मशीन पर जाता है, उसका आउटपुट वापस आता है, और बीच में नेटवर्क पर नजर रखने वाला कोई भी व्यक्ति इनमें से किसी को भी नहीं पढ़ सकता है। किराए पर लिए गए Linux सर्वर के साथ कोई स्क्रीन या कीबोर्ड नहीं जुड़ा होता है, इसलिए SSH ही वह माध्यम है जिससे उस मशीन का उपयोग किया जाता है।

यह नाम दो चीजों को कवर करता है। SSH वह प्रोटोकॉल है, जिसका वर्णन RFC 4251 से RFC 4254 तक किया गया है। OpenSSH वह प्रोग्राम है जो इसे लागू करता है, और लगभग हर Linux सर्वर और लगभग हर लैपटॉप वास्तव में इसी को चलाता है। जब कोई कहता है कि "सर्वर में SSH करें", तो उनका मतलब होता है कि उनकी मशीन पर मौजूद क्लाइंट प्रोग्राम ssh दूसरे छोर पर मौजूद सर्वर प्रोग्राम sshd से बात कर रहा है।

SSH को जिस समस्या को बदलने के लिए बनाया गया था

Remote login, SSH से काफी पुराना है। Telnet, port 23 पर एक plain TCP connection खोलता था और हर byte को बिल्कुल वैसे ही भेजता था जैसे उसे टाइप किया गया हो। इसमें कुछ भी encrypted नहीं होता था, और इसमें आपका password भी शामिल था। जो कोई भी उस traffic को देख सकता था, वह उसे पढ़ भी सकता था: चाहे वह उसी office network पर मौजूद कोई व्यक्ति हो, या रास्ते में आने वाला किसी भी router का operator। Rlogin परिवार में भी यही कमजोरी थी, और यह client machine पर उसके नाम के आधार पर भरोसा करता था, जिसका अर्थ है कि network जिस नाम का दावा करे, उस पर भरोसा कर लेना।

Tatu Ylönen ने 1995 में Helsinki University of Technology में पहला SSH लिखा, जो विश्वविद्यालय के network पर हुए एक password sniffing attack के बाद आया था। इसका design telnet के उपयोगी हिस्से को बरकरार रखता है, यानी आपके terminal और remote shell के बीच एक byte stream, और इसमें वे दो चीजें जोड़ता है जिनका telnet के पास कोई समाधान नहीं था: stream का encryption, और इस बात का प्रमाण कि दूसरी तरफ मौजूद server वही है जिससे आप जुड़ना चाहते थे।

उस दूसरे हिस्से को नजरअंदाज करना आसान है, और यह SSH का आधा हिस्सा है। केवल encryption आपको नहीं बचा सकता। बीच में मौजूद कोई machine आपके connection को स्वीकार कर सकती है, उसे पूरी तरह से encrypt कर सकती है, आपके द्वारा भेजी गई हर चीज को पढ़ सकती है, और उसे असली server तक आगे बढ़ा सकती है। SSH इसे रोकता है क्योंकि यह हर server को एक स्थायी पहचान देता है, जिसे host key कहा जाता है, और हर connection पर इसकी जाँच करता है।

Client और server मॉडल कैसे काम करता है

यहाँ दो प्रोग्राम होते हैं। सर्वर पर, sshd हर समय चलता रहता है और connections की प्रतीक्षा करता है। आपकी मशीन पर, ssh उन्हें बनाता है। ये अलग-अलग प्रोग्राम हैं जिनकी configuration files भी अलग होती हैं, और इन दोनों के बीच भ्रमित होना सबसे आम कारण है कि किसी बदलाव का कोई प्रभाव क्यों नहीं पड़ता।

• सर्वर /etc/ssh/sshd_config को पढ़ता है। यहीं पर password login को बंद किया जाता है और listening port सेट किया जाता है।
• client सिस्टम defaults के लिए /etc/ssh/ssh_config को पढ़ता है, और फिर आपके स्वयं के per-host सेटिंग्स के लिए ~/.ssh/config को पढ़ता है।

Debian और Ubuntu पर service unit को ssh कहा जाता है। RHEL, Rocky और Fedora पर इसे sshd कहा जाता है। हालिया Ubuntu releases इसे socket activated के रूप में install करती हैं, इसलिए systemctl status ssh कभी-कभी inactive (dead) रिपोर्ट कर सकता है जबकि मशीन पूरी तरह से reachable होती है, क्योंकि ssh.socket वह unit है जो listening का काम करती है और यह मांग (demand) होने पर service को start करती है।

client का OpenSSH होना अनिवार्य नहीं है। Windows पर PuTTY, फोन पर Termius, और editors में बनी remote support सुविधाएँ, सभी एक ही protocol का उपयोग करके उसी sshd से बात करते हैं। Windows 10 और 11 में OpenSSH client भी शामिल है, इसलिए ssh you@server बिना कुछ install किए PowerShell में काम करता है।

SSH पोर्ट 22 का उपयोग क्यों करता है?

पोर्ट एक नंबर है जो kernel को यह बताता है कि आने वाला connection किस listening program का है, और Linux पर पोर्ट्स हर service के लिए एक ही तरह से काम करते हैं। SSH 22 का उपयोग इसलिए करता है क्योंकि IANA ने 1995 में इसे असाइन किया था। Ylönen ने उन protocols के बगल में एक खाली नंबर मांगा था जिन्हें SSH को बदलना था: 21 FTP था, 23 telnet था, और 22 खाली था।

चूंकि 22 default है, इसलिए सब कुछ इसी को मानकर चलता है। आपका Git remote, आपकी backup script और आपके provider का control panel, सभी सबसे पहले 22 पर प्रयास करते हैं। इंटरनेट पर मौजूद हर automated scanner भी यही करता है। password login enabled वाला एक नया सर्वर बूट होने के कुछ ही मिनटों के भीतर /var/log/auth.log में इस तरह की लाइनें जमा करना शुरू कर देता है:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

वह traffic निरंतर होता है, और यह व्यक्तिगत रूप से आप पर लक्षित नहीं है। sshd को पोर्ट 2222 पर ले जाने से उन लाइनों में से अधिकांश हट जाती हैं, क्योंकि scanners आपके सर्वर का अध्ययन करने के बजाय 22 पर पूरे इंटरनेट को स्कैन कर रहे होते हैं। यह उस व्यक्ति के लिए मशीन को तोड़ना कठिन नहीं बनाता जो वास्तव में इसे देख रहा है। पोर्ट बदलने को केवल शोर (noise) कम करने का एक तरीका मानें, इससे अधिक कुछ नहीं।

आप लॉग इन करने से पहले ही सर्वर को जवाब देते हुए देख सकते हैं:

nc 203.0.113.10 22

Ubuntu 24.04 पर यह SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13 के करीब कुछ प्रिंट करता है। banner cleartext में भेजा जाता है, इससे पहले कि कोई encryption मौजूद हो, क्योंकि दोनों पक्षों को protocol version पर सहमत होने के लिए इसकी आवश्यकता होती है। connection बंद करने के लिए Ctrl+C दबाएं।

कनेक्ट करते समय नेटवर्क पर क्या होता है

नीचे दी गई प्रक्रिया वह है जो प्रॉम्प्ट दिखने से पहले एक ssh you@server करता है।

1. क्लाइंट होस्टनेम को IP एड्रेस में रिजॉल्व करता है, फिर पोर्ट 22 पर एक TCP कनेक्शन खोलता है।
2. दोनों पक्ष अपना वर्शन बैनर क्लियरटेक्स्ट में भेजते हैं।
3. दोनों पक्ष उन एल्गोरिदम की सूची भेजते हैं जिनका वे समर्थन करते हैं: की एक्सचेंज, साइफर, मैसेज ऑथेंटिकेशन, और कम्प्रेशन। यह अभी भी क्लियरटेक्स्ट में होता है। दोनों पक्षों द्वारा ज्ञात सबसे मजबूत विकल्प को चुना जाता है।
4. की एक्सचेंज (Key exchange) प्रक्रिया चलती है। वर्तमान OpenSSH curve25519-sha256 को प्राथमिकता देता है। दोनों छोर एक समान साझा सीक्रेट (shared secret) प्राप्त कर लेते हैं, बिना उस सीक्रेट के नेटवर्क पर कभी भी यात्रा किए। इसलिए, यदि कोई पूरी बातचीत को रिकॉर्ड भी कर ले, तो भी वह बाद में इसे डिकोड नहीं कर सकता।
5. सर्वर उस एक्सचेंज के परिणाम को अपनी होस्ट प्राइवेट की (private key) से साइन करता है। आपका क्लाइंट उस सिग्नेचर की जांच अपनी फाइल में मौजूद होस्ट पब्लिक की (public key) से करता है। यही वह चरण है जो बीच में बैठे किसी मशीन को आपके सर्वर का रूप धारण करने से रोकता है।
6. एन्क्रिप्शन शुरू होता है। वर्तमान OpenSSH में chacha20-poly1305@openssh.com डिफ़ॉल्ट साइफर है।
7. अब जाकर क्लाइंट आपको पासवर्ड या की (key) के माध्यम से ऑथेंटिकेट करता है। आपका यूजरनेम और पासवर्ड एन्क्रिप्टेड चैनल के अंदर यात्रा करते हैं।
8. क्लाइंट एक चैनल खोलता है और शेल (shell) की मांग करता है।

इस सूची का क्रम ही telnet से इसका पूरा अंतर है। ऑथेंटिकेशन तब होता है जब चैनल एन्क्रिप्ट हो चुका होता है और सर्वर अपनी पहचान साबित कर चुका होता है। इसलिए ऐसा कोई क्षण नहीं होता जब आपका पासवर्ड नेटवर्क पर खुले में मौजूद हो।

नेटवर्क पर निगरानी रखने वाला व्यक्ति अभी भी कुछ जानकारी प्राप्त कर सकता है। वे आपका IP एड्रेस, सर्वर का IP एड्रेस, पोर्ट 22, दोनों क्लियरटेक्स्ट वर्शन बैनर, और हर पैकेट का समय और अनुमानित आकार देख सकते हैं। वे आपका यूजरनेम, पासवर्ड, आपके कमांड या उनका आउटपुट नहीं देख सकते। चरण 1 में होस्टनेम लुकअप SSH का हिस्सा नहीं है और आमतौर पर यह निजी नहीं होता है, इसलिए आपके सर्वर नाम को रिजॉल्व करने वाली DNS क्वेरी यह उजागर कर सकती है कि आप किस मशीन से जुड़ने वाले हैं, भले ही सेशन पूरी तरह सुरक्षित रहे।

होस्ट की (host key) और पहला कनेक्शन फिंगरप्रिंट प्रॉम्प्ट

जब openssh-server इंस्टॉल किया जाता है, तो यह मशीन के लिए होस्ट की पेयर (host key pairs) जेनरेट करता है और उन्हें /etc/ssh/ में लिख देता है, उदाहरण के लिए ssh_host_ed25519_key और ssh_host_ed25519_key.pub। प्राइवेट हिस्सा कभी भी सर्वर से बाहर नहीं जाता है। पब्लिक हिस्सा सर्वर की पहचान है, और इसी के विरुद्ध स्टेप 5 में सिग्नेचर की जाँच की जाती है।

जब आप पहली बार किसी नए सर्वर से कनेक्ट करते हैं, तो आपके क्लाइंट के पास तुलना करने के लिए कुछ नहीं होता है, इसलिए वह आपसे पूछता है:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

फिंगरप्रिंट होस्ट पब्लिक की का SHA256 हैश होता है, जिसे base64 में प्रिंट किया जाता है, ताकि इसे आँखों से देखकर तुलना करना आसान हो। yes टाइप करने से वह की आपकी अपनी मशीन पर ~/.ssh/known_hosts में लिख जाती है। उसी पते पर बाद में होने वाला हर कनेक्शन सर्वर द्वारा दी गई की की तुलना स्टोर की गई की से करता है। जब वे मेल खाते हैं, तो कुछ भी प्रिंट नहीं होता है और आप सीधे अपने प्रॉम्प्ट पर पहुँच जाते हैं।

इस मॉडल को 'ट्रस्ट ऑन फर्स्ट यूज़' (trust on first use) कहा जाता है, और यह स्पष्ट होना जरूरी है कि इसकी क्या कीमत है। पहला कनेक्शन वह क्षण है जब आप असुरक्षित होते हैं, क्योंकि आप एक ऐसी की स्वीकार कर रहे होते हैं जिसे आपने पहले कभी नहीं देखा है। इस अंतर को खत्म करने के लिए, किसी अन्य माध्यम से फिंगरप्रिंट प्राप्त करें और तुलना करें। अधिकांश प्रदाता इसे अपने वेब कंसोल में दिखाए गए बूट आउटपुट में प्रिंट करते हैं, और आप इसे स्वयं सर्वर पर भी प्रिंट कर सकते हैं:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

यह वही SHA256: स्ट्रिंग प्रिंट करता है जो प्रॉम्प्ट ने आपको दिखाई थी। प्रॉम्प्ट में [fingerprint] विकल्प ठीक इसी के लिए मौजूद है: जिस फिंगरप्रिंट की आप अपेक्षा करते हैं उसे पेस्ट करें, और क्लाइंट केवल तभी आगे बढ़ेगा यदि वह सर्वर द्वारा प्रस्तुत की गई की से मेल खाता है।

Debian और Ubuntu पर, known_hosts डिफ़ॉल्ट रूप से हैश किया जाता है, इसलिए फ़ाइल में ऐसी लाइनें होती हैं जो पठनीय होस्टनाम के बजाय |1| से शुरू होती हैं। किसी एक होस्ट की एंट्री खोजने के लिए ssh-keygen -F 203.0.113.10 चलाएँ।

SSH यह क्यों कहता है कि host key बदल गई है?

देर-सवेर आपको टेक्स्ट की यह दीवार दिखाई देगी:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

यह Host key verification failed. पर समाप्त होता है और client connect करने से मना कर देता है। यह Password authentication is disabled to avoid man-in-the-middle attacks. भी प्रिंट करता है, क्योंकि किसी अज्ञात मशीन में अपना password टाइप करना ठीक वही नुकसान है जिसे रोकने के लिए यह जांच मौजूद है।

यह संदेश किसी आपात स्थिति जैसा लगता है, लेकिन ज्यादातर समय ऐसा नहीं होता है। इसके सामान्य कारण ये हैं:

• आपने सर्वर को rebuild या reinstall किया है, इसलिए sshd ने पहली बार boot होने पर नई host keys generate की हैं। यह अब तक का सबसे सामान्य कारण है।
• आपने एक VPS को नष्ट कर दिया और दूसरा बना लिया, और provider ने नई मशीन को वही पुराना IP address दे दिया।
• आप किसी forward या load balancer के माध्यम से connect कर रहे हैं जो अब एक अलग backend मशीन तक पहुँचता है।
• वास्तव में कोई कनेक्शन को intercept कर रहा है।

कुछ भी हटाने से पहले तय करें कि कारण क्या है। यदि आपने दस मिनट पहले ही मशीन reinstall की है, तो कारण स्पष्ट है। यदि आपकी तरफ से कुछ भी नहीं बदला है, तो रुकें और जांच करें, क्योंकि यह चेतावनी अपना काम कर रही है। एक बार जब आप सुनिश्चित हो जाएं, तो पुरानी entry को हटा दें और फिर से connect करें:

ssh-keygen -R 203.0.113.10

अगला कनेक्शन फिर से fingerprint prompt दिखाता है, जो आपको provider console के साथ इसकी तुलना करने का एक नया मौका देता है।

Password login बनाम key login

Password authentication आपके पासवर्ड को पहले से ही encrypted channel के भीतर भेजती है, और sshd इसे account database के विरुद्ध जाँचता है, जो आमतौर पर PAM (pluggable authentication modules) के माध्यम से होता है। इसके लिए किसी तैयारी की आवश्यकता नहीं होती है, यही कारण है कि एक provider आपको केवल root पासवर्ड के साथ एक नया सर्वर दे सकता है।

इसकी कमजोरी encryption में नहीं है। समस्या यह है कि पासवर्ड एक छोटा secret होता है, आप इसे हर login पर सर्वर को भेजते हैं, और port 22 पर ऐसी मशीनों द्वारा चौबीसों घंटे अनुमान लगाया जाता है जो कभी थकती नहीं हैं।

Public key authentication अलग तरह से काम करती है। आप अपनी मशीन पर एक key pair बनाते हैं। public हिस्सा सर्वर पर आपके account के भीतर ~/.ssh/authorized_keys में जाता है। private हिस्सा आपके laptop पर रहता है और कभी transmit नहीं होता है। login करने के लिए, client डेटा के एक टुकड़े पर हस्ताक्षर (sign) करता है जिसमें key exchange से session identifier शामिल होता है, और सर्वर उस public key का उपयोग करके उस signature को verify करता है जो उसके पास पहले से मौजूद है। चूंकि हस्ताक्षरित डेटा इस एक session से जुड़ा होता है, इसलिए पकड़ा गया signature किसी अन्य चीज़ के लिए बेकार होता है।

दिशा पर ध्यान दें, क्योंकि इसे उल्टा करना आम है और यह हानिकारक है: public key सर्वर पर जाती है, private key आपके पास रहती है। सर्वर पर copy की गई private key ऐसी key है जिस पर आप अब भरोसा नहीं कर सकते।

Key login के अपने failure modes होते हैं। जब file permissions बहुत ढीली होती हैं तो sshd keys को ignore कर देता है, और यह सर्वर log में दिखाई देता है:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Client आपको केवल Permission denied (publickey) बताता है, जो एक दर्जन अलग-अलग कारणों के लिए एक ही संदेश है, इसलिए publickey error को सही ढंग से पढ़ना सीखने लायक है, इससे पहले कि आप खुद को lock out कर लें। keys बनाने, उन्हें passphrase के साथ सुरक्षित करने और उन्हें agent में load करने का व्यावहारिक काम SSH key management के अंतर्गत आता है, और खुद को फंसाए बिना password login को बंद करना VPS पर SSH को सुरक्षित करना के अंतर्गत आता है।

SFTP, scp और port forwarding एक ही connection का उपयोग करते हैं

यह वह मुख्य विचार है जिससे SSH की बाकी दुनिया को समझना आसान हो जाता है। Authentication एक encrypted connection खोलता है, और वह connection एक ही समय में कई स्वतंत्र channels को ले जा सकता है। Shell उन कई channels में से एक प्रकार है।

• एक remote shell। ssh you@server एक session channel खोलता है और एक interactive shell के लिए अनुरोध करता है।
• एक single command। ssh you@server uptime एक channel खोलता है, एक command चलाता है, output print करता है और exit हो जाता है।
• SFTP। Client, sshd से उसके sftp subsystem को शुरू करने के लिए कहता है, और file transfer उसी connection के भीतर चलता है। SFTP एक file transfer protocol है जो SSH पर चलता है, और इसका FTP के साथ कोई डिज़ाइन साझा नहीं है। वह protocol जो encryption के साथ FTP है, उसे FTPS कहा जाता है, और वह इससे संबंधित नहीं है।
• scp। उसी login का उपयोग करके files copy करता है। OpenSSH 9.0 के बाद से, जिसे 2022 में release किया गया था, scp डिफ़ॉल्ट रूप से अंदरूनी तौर पर SFTP protocol का उपयोग करता है।
• Port forwarding। ssh -L 8080:localhost:80 you@server आपके laptop पर port 8080 को server पर port 80 के लिए एक द्वार में बदल देता है, जो encrypted connection के अंदर ले जाया जाता है। -R दूसरी दिशा में forward करता है, और -D 1080 session को SOCKS proxy में बदल देता है।
• Git। git@github.com:user/repo.git जैसा एक remote एक SSH login है जिसका remote side shell के बजाय एक command handler चलाता है।
• rsync और Ansible भी SSH clients हैं। वे एक channel खोलते हैं, कुछ चलाते हैं, और output को वापस पढ़ते हैं।

उस सूची की प्रत्येक वस्तु एक ही port, एक ही host key check और एक ही credentials का उपयोग करती है। यही कारण है कि एक बार key authentication सेट करने से मेहनत का फल तुरंत मिलता है: इनमें से प्रत्येक tool इसे inherit कर लेता है। यही कारण है कि वही ~/.ssh/config file जो आपके logins को छोटा करती है, वही file तब भी काम आती है जब आप एक laptop से कई Linux servers को manage कर रहे होते हैं।

SSH क्या नहीं करता है

• यह आपके सर्वर को सुरक्षित नहीं बनाता है। SSH केवल दरवाजे तक के रास्ते की सुरक्षा करता है। दरवाजा अभी भी वहीं है और लोग उसका हैंडल आजमाने की कोशिश करते रहेंगे। fail2ban के साथ बार-बार होने वाले लॉगिन प्रयासों को ब्लॉक करना इस समस्या को संभालता है, और केवल key-based authentication का उपयोग करने से वे चीजें हट जाती हैं जिनका वे अनुमान लगा रहे होते हैं।
• यह आपको आपकी अपनी मशीन से सुरक्षित नहीं रखता है। आपके लैपटॉप तक पहुँच रखने वाला कोई भी व्यक्ति आपकी private key और loaded agent का उपयोग कर सकता है।
• यह इस बात को नहीं छिपाता कि आप SSH का उपयोग कर रहे हैं। port number और cleartext version banner इसकी जानकारी दे देते हैं।
• यह उस प्रक्रिया को कवर नहीं करता जो connection बनने से पहले होती है। name lookup और किस address पर भरोसा करना है, यह निर्णय दोनों ही पहले लिए जाते हैं।

आगे क्या करें

यदि आपके पास अभी किसी provider console में एक नया सर्वर खुला है, तो उपयोगी क्रम निश्चित है। लॉग इन करें, एक सामान्य user बनाएँ, अपनी key install करें, और फिर अपने पीछे आसान रास्तों को बंद कर दें। एक नए VPS पर पहले दस मिनट उस क्रम को शुरू से अंत तक बताता है, और यदि शब्द अभी भी नए हैं तो VPS वास्तव में क्या है उसके नीचे की मशीन के बारे में जानकारी देता है। उसके बाद, keys और hardening वे दो पोस्ट हैं जिन्हें इसी क्रम में पढ़ना चाहिए।

FAQ

SSH का क्या अर्थ है?

SSH का अर्थ है secure shell। यह एक remote computer पर login करने और encrypted connection के माध्यम से उस पर commands चलाने का एक protocol है, जिसे RFC 4251 से RFC 4254 तक परिभाषित किया गया है। OpenSSH वह implementation है जिसे लगभग हर कोई उपयोग करता है: आपकी machine पर ssh client, और remote machine पर sshd server। इसने telnet की जगह ली, जो passwords सहित सब कुछ plain text में network पर भेजता था।

SSH port 22 का उपयोग क्यों करता है?

IANA ने 1995 में SSH को port 22 आवंटित किया था, जो 21 पर FTP और 23 पर telnet के बगल में है, जिन्हें बदलने के लिए ही इसे लिखा गया था। कोई भी चीज़ इस संख्या को बाध्य नहीं करती है: /etc/ssh/sshd_config में Port इसे server पर बदल देता है, और ssh -p client पर एक अलग port चुनता है। चूंकि 22 default है, automated scanners लगातार इस पर दस्तक देते रहते हैं, यही कारण है कि एक नए server का /var/log/auth.log, Failed password for invalid user lines से भर जाता है। port बदलने से वह शोर कम हो जाता है, लेकिन इससे कोई वास्तविक सुरक्षा नहीं मिलती है।

जब SSH चेतावनी दे कि host key बदल गई है, तो मुझे क्या करना चाहिए?

किसी भी चीज़ को हटाने से पहले कारण का पता लगाएँ। सामान्य कारण हानिरहित होता है: server को फिर से बनाया गया था, इसलिए sshd ने नई host keys generate कीं, या किसी नई machine को पुराना IP address दिया गया। यदि आप जानते हैं कि machine को फिर से बनाया गया था, तो संग्रहीत key को हटाने के लिए ssh-keygen -R <host> चलाएँ, फिर से connect करें, और आपको दिखाई गई fingerprint की तुलना उस fingerprint से करें जो आपका provider console रिपोर्ट करता है। यदि आपकी तरफ से कुछ भी नहीं बदला है, तो connect न करें और अपना password न लिखें। OpenSSH इसी सटीक कारण से इस स्थिति में password authentication को पहले ही अस्वीकार कर देता है।

क्या SFTP और scp, SSH से अलग हैं?

वे इसके ऊपर चलते हैं। एक बार जब आप authenticate हो जाते हैं, तो SSH connection कई channels ले जा सकता है, और shell उनमें से केवल एक है। SFTP एक file transfer protocol है जो उसी connection पर sshd के sftp subsystem का उपयोग करता है, और scp ने OpenSSH 9.0 के बाद से ही SFTP protocol का उपयोग किया है। Port forwarding और SSH पर Git भी उसी connection पर channels हैं। वे सभी एक ही port, एक ही host key check और एक ही login का उपयोग करते हैं। ध्यान दें कि SFTP, encryption के साथ जोड़ा गया FTP नहीं है; उसे FTPS कहा जाता है और यह एक अलग protocol है।

क्या key authentication वास्तव में password से बेहतर है?

हाँ, internet से पहुँच योग्य किसी भी server के लिए। password एक छोटा secret है जिसे आप हर login पर server को देते हैं, और port 22 का अनुमान automated clients द्वारा लगातार लगाया जाता है। key pair के साथ, private हिस्सा कभी भी आपकी machine से बाहर नहीं जाता है: client वर्तमान session से जुड़ी data को sign करता है, और server उस signature की तुलना ~/.ssh/authorized_keys में मौजूद public key से करता है। एक record किए गए signature को किसी अन्य server के खिलाफ फिर से नहीं चलाया जा सकता है। private key को एक passphrase के साथ सुरक्षित रखें, क्योंकि बिना passphrase वाली key file किसी भी ऐसे व्यक्ति के लिए एक working login है जो इसे copy कर लेता है।