SSH म्हणजे काय आणि ते कसे काम करते?

SSH म्हणजे काय?

SSH (secure shell) हे एका दूरस्थ संगणकावर लॉग-इन करण्यासाठी आणि एनक्रिप्टेड कनेक्शनद्वारे त्यावर कमांड्स चालवण्यासाठी वापरले जाणारे प्रोटोकॉल आहे. तुम्ही टाईप केलेली माहिती रिमोट मशीनवर जाते, तिथून आउटपुट परत येते आणि नेटवर्कवर लक्ष ठेवणारी कोणतीही व्यक्ती ही माहिती वाचू शकत नाही. भाड्याने घेतलेल्या Linux सर्व्हरला स्क्रीन किंवा कीबोर्ड जोडलेला नसतो, त्यामुळे SSH द्वारेच त्या मशीनचा वापर केला जातो.

हे नाव दोन गोष्टींसाठी वापरले जाते. SSH हे प्रोटोकॉल आहे, ज्याचे वर्णन RFC 4251 ते RFC 4254 मध्ये केले आहे. OpenSSH हा तो प्रोग्राम आहे जो या प्रोटोकॉलची अंमलबजावणी करतो आणि जवळजवळ प्रत्येक Linux सर्व्हर आणि लॅपटॉपवर तोच चालतो. जेव्हा कोणी "SSH into the server" असे म्हणते, तेव्हा त्यांचा अर्थ त्यांच्या मशीनवरील क्लायंट प्रोग्राम ssh हा दुसऱ्या टोकाला असलेल्या सर्व्हर प्रोग्राम sshd शी संवाद साधत आहे असा होतो.

SSH ज्या समस्येच्या निराकरणासाठी तयार केले गेले

रिमोट लॉगिन हे SSH पेक्षा खूप जुने आहे. Telnet पोर्ट 23 वर एक साधे TCP कनेक्शन उघडत असे आणि प्रत्येक बाइट जसा टाईप केला जाईल तसा पाठवत असे. यामध्ये कशाचेही एन्क्रिप्शन नसायचे, आणि त्यात तुमच्या पासवर्डचाही समावेश असायचा. ज्या कोणालाही हे नेटवर्क ट्रॅफिक दिसत असे, तो ते वाचू शकत असे: मग तो त्याच ऑफिस नेटवर्कमधील एखादी व्यक्ती असो किंवा मार्गातील कोणत्याही राउटरचा ऑपरेटर असो. rlogin फॅमिलीमध्येही हीच त्रुटी होती आणि ती क्लायंट मशीनवर नावाच्या आधारे विश्वास ठेवत असे, ज्याचा अर्थ नेटवर्कने जे नाव सांगितले त्यावर विश्वास ठेवणे असा होतो.

Tatu Ylönen यांनी 1995 मध्ये Helsinki University of Technology मध्ये पहिले SSH लिहिले, जेव्हा विद्यापीठाच्या नेटवर्कवर पासवर्ड स्निफिंगचा हल्ला झाला होता. या डिझाइनने telnet चा उपयुक्त भाग, म्हणजेच तुमच्या टर्मिनल आणि रिमोट शेलमधील बाइट स्ट्रीम, कायम ठेवला आणि telnet कडे ज्या गोष्टींची उत्तरे नव्हती अशा दोन गोष्टी जोडल्या: स्ट्रीमचे एन्क्रिप्शन आणि समोरचा सर्व्हर हाच तो सर्व्हर आहे ज्याच्याशी तुम्हाला कनेक्ट करायचे होते, याचा पुरावा.

दुसरा भाग दुर्लक्षित करणे सोपे आहे, परंतु SSH चे ते अर्धे काम आहे. केवळ एन्क्रिप्शन तुम्हाला वाचवू शकत नाही. मध्यभागी असलेले एखादे मशीन तुमचे कनेक्शन स्वीकारू शकते, ते उत्तम प्रकारे एन्क्रिप्ट करू शकते, तुम्ही पाठवलेली प्रत्येक गोष्ट वाचू शकते आणि ती खऱ्या सर्व्हरकडे पाठवू शकते. SSH याला प्रतिबंध करते, कारण ते प्रत्येक सर्व्हरला एक कायमस्वरूपी ओळख देते, ज्याला host key म्हणतात, आणि प्रत्येक कनेक्शनवर त्याची तपासणी करते.

क्लायंट आणि सर्व्हर मॉडेल कसे कार्य करते

येथे दोन प्रोग्राम्स आहेत. सर्व्हरवर, sshd सतत चालू असतो आणि कनेक्शनची वाट पाहतो. तुमच्या मशीनवर, ssh कनेक्शन तयार करतो. हे स्वतंत्र प्रोग्राम्स असून त्यांच्या कॉन्फिगरेशन फाइल्सही वेगळ्या असतात. या दोघांमध्ये गल्लत करणे हे बदल प्रभावी न ठरण्याचे सर्वात सामान्य कारण आहे.

• सर्व्हर /etc/ssh/sshd_config वाचतो. येथेच पासवर्ड लॉगिन बंद केले जाते आणि लिसनिंग पोर्ट सेट केला जातो.
• क्लायंट सिस्टम डिफॉल्ट्ससाठी /etc/ssh/ssh_config वाचतो, त्यानंतर तुमच्या स्वतःच्या प्रति-होस्ट सेटिंग्जसाठी ~/.ssh/config वाचतो.

Debian आणि Ubuntu वर सर्व्हिस युनिटला ssh म्हणतात. RHEL, Rocky आणि Fedora वर याला sshd म्हणतात. अलीकडील Ubuntu रिलीजमध्ये हे सॉकेट-अॅक्टिव्हेटेड पद्धतीने इन्स्टॉल होते, त्यामुळे मशीन पूर्णपणे उपलब्ध असतानाही systemctl status ssh हे inactive (dead) असे दाखवू शकते. याचे कारण असे की ssh.socket हे युनिट लिसनिंगचे काम करते आणि गरजेनुसार सर्व्हिस सुरू करते.

क्लायंट हा OpenSSH असणे आवश्यक नाही. Windows वरील PuTTY, फोनवरील Termius आणि एडिटर्समध्ये इन-बिल्ट असलेले रिमोट सपोर्ट हे सर्व एकाच प्रोटोकॉलद्वारे त्याच sshd शी संवाद साधतात. Windows 10 आणि 11 मध्ये देखील OpenSSH क्लायंट समाविष्ट आहे, त्यामुळे काहीही इन्स्टॉल न करता PowerShell मध्ये ssh you@server कार्य करते.

SSH पोर्ट 22 चा वापर का करते?

पोर्ट हा एक क्रमांक आहे जो कर्नलला सांगतो की येणारे कनेक्शन कोणत्या listening प्रोग्रामशी संबंधित आहे, आणि Linux वरील पोर्ट्स प्रत्येक सेवेसाठी अशाच प्रकारे काम करतात. SSH पोर्ट 22 वापरते कारण IANA ने 1995 मध्ये ते नियुक्त केले होते. Ylönen यांनी अशा प्रोटोकॉलच्या जवळचा रिकामा क्रमांक मागितला होता ज्यांना SSH ने बदलले होते: 21 हे FTP साठी होते, 23 हे telnet साठी होते आणि 22 हे वापरात नव्हते.

22 हा डीफॉल्ट पोर्ट असल्याने, सर्व काही तेच गृहीत धरते. तुमचे Git remote, तुमची बॅकअप स्क्रिप्ट आणि तुमच्या प्रोव्हायडरचे कंट्रोल पॅनेल हे सर्व प्रथम 22 वापरून पाहतात. इंटरनेटवरील प्रत्येक स्वयंचलित स्कॅनर सुद्धा हेच करतो. पासवर्ड लॉगिन सुरू असलेला नवीन सर्व्हर बूट झाल्यानंतर काही मिनिटांतच /var/log/auth.log मध्ये अशा ओळी जमा करू लागतो:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

हे ट्रॅफिक सतत असते आणि ते वैयक्तिकरित्या तुम्हाला लक्ष्य करत नाही. sshd ला पोर्ट 2222 वर हलवल्याने अशा बहुतेक ओळी कमी होतात, कारण स्कॅनर्स तुमच्या सर्व्हरचा अभ्यास करण्याऐवजी संपूर्ण इंटरनेटवर पोर्ट 22 स्कॅन करत असतात. जर कोणी मुद्दाम तुमच्या सर्व्हरकडे पाहिले, तर पोर्ट बदलल्यामुळे मशीन हॅक करणे कठीण होत नाही. पोर्ट बदलण्याकडे फक्त 'नॉइज रिडक्शन' (अनावश्यक माहिती कमी करणे) म्हणून पहा, त्यापेक्षा जास्त काहीही नाही.

लॉगिन करण्यापूर्वी सर्व्हर कसा प्रतिसाद देतो हे तुम्ही पाहू शकता:

nc 203.0.113.10 22

Ubuntu 24.04 वर हे SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13 च्या जवळ काहीतरी प्रिंट करते. हे बॅनर कोणत्याही प्रकारचे एन्क्रिप्शन अस्तित्वात येण्यापूर्वी, प्लेन टेक्स्टमध्ये पाठवले जाते, कारण दोन्ही बाजूंना प्रोटोकॉल आवृत्तीवर सहमत होण्यासाठी याची आवश्यकता असते. कनेक्शन बंद करण्यासाठी Ctrl+C दाबा.

तुम्ही कनेक्ट करता तेव्हा नेटवर्कवर काय घडते

तुम्ही प्रॉम्प्ट पाहण्यापूर्वी एक ssh you@server खालील प्रक्रिया पूर्ण करतो.

1. क्लायंट होस्टनेमचे IP ॲड्रेसमध्ये रूपांतर करतो आणि पोर्ट 22 वर TCP कनेक्शन उघडतो.
2. दोन्ही बाजू त्यांचे व्हर्जन बॅनर प्लेनटेक्स्टमध्ये पाठवतात.
3. दोन्ही बाजू त्यांना सपोर्ट असलेल्या अल्गोरिदमची यादी पाठवतात: की एक्सचेंज, सायफर, मेसेज ऑथेंटिकेशन आणि कॉम्प्रेशन. हे अजूनही प्लेनटेक्स्टमध्ये असते. दोन्ही बाजूंना माहित असलेला सर्वात मजबूत पर्याय निवडला जातो.
4. की एक्सचेंज प्रक्रिया सुरू होते. सध्याचे OpenSSH curve25519-sha256 ला प्राधान्य देते. दोन्ही टोकांना एकच सामायिक गुप्त की (shared secret) मिळते, जी कधीही नेटवर्कवरून प्रवास करत नाही. त्यामुळे ज्याने संपूर्ण संभाषण रेकॉर्ड केले आहे, तो देखील नंतर ती की शोधू शकत नाही.
5. सर्व्हर या एक्सचेंजचा निकाल त्याच्या होस्ट प्रायव्हेट की ने साइन करतो. तुमचा क्लायंट त्या स्वाक्षरीची पडताळणी त्याच्याकडे असलेल्या होस्ट पब्लिक की शी करतो. ही पायरी मधल्या एखाद्या मशीनला तुमचा सर्व्हर असल्याचे भासवण्यापासून रोखते.
6. एन्क्रिप्शन सुरू होते. सध्याच्या OpenSSH मध्ये chacha20-poly1305@openssh.com हा डीफॉल्ट सायफर आहे.
7. आता क्लायंट तुमचे ऑथेंटिकेशन करतो, पासवर्ड किंवा की वापरून. तुमचे युजरनेम आणि पासवर्ड एन्क्रिप्टेड चॅनेलच्या आतून प्रवास करतात.
8. क्लायंट एक चॅनेल उघडतो आणि शेलची मागणी करतो.

या यादीतील क्रम हा 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. प्रायव्हेट की (private key) कधीही सर्व्हरच्या बाहेर जात नाही. पब्लिक की (public key) ही सर्व्हरची ओळख असते आणि स्टेप 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. वर संपतो आणि क्लायंट कनेक्ट होण्यास नकार देतो. तो Password authentication is disabled to avoid man-in-the-middle attacks. देखील दर्शवतो, कारण अनोळखी मशीनवर पासवर्ड टाईप करणे हाच धोका टाळण्यासाठी ही तपासणी अस्तित्वात आहे.

हा संदेश आपत्कालीन वाटत असला तरी, बहुतेक वेळा तसे नसते. याची सामान्य कारणे खालीलप्रमाणे आहेत:

• तुम्ही सर्व्हर पुन्हा तयार केला किंवा पुन्हा इन्स्टॉल केला आहे, त्यामुळे sshd ने पहिल्या बूटच्या वेळी नवीन host keys तयार केल्या आहेत. हे सर्वात सामान्य कारण आहे.
• तुम्ही एक VPS नष्ट करून दुसरे तयार केले आहे आणि प्रोव्हायडरने नवीन मशीनला जुना IP address दिला आहे.
• तुम्ही अशा forward किंवा load balancer द्वारे कनेक्ट करत आहात जे आता वेगळ्या backend मशीनपर्यंत पोहोचत आहे.
• खरोखरच कोणीतरी कनेक्शनमध्ये हस्तक्षेप करत आहे.

काहीही हटवण्यापूर्वी नक्की काय झाले आहे ते ठरवा. जर तुम्ही दहा मिनिटांपूर्वीच मशीन पुन्हा इन्स्टॉल केले असेल, तर कारण स्पष्ट आहे. जर तुमच्या बाजूने काहीही बदलले नसेल, तर थांबा आणि तपास करा, कारण हा इशारा म्हणजे सुरक्षा तपासणी तिचे काम करत आहे. एकदा खात्री पटल्यावर, जुनी नोंद काढून टाका आणि पुन्हा कनेक्ट करा:

ssh-keygen -R 203.0.113.10

पुढच्या कनेक्शनमध्ये पुन्हा fingerprint प्रॉम्प्ट दिसेल, ज्यामुळे तुम्हाला प्रोव्हायडर कन्सोलशी त्याची तुलना करण्याची नवीन संधी मिळेल.

पासवर्ड लॉगिन विरुद्ध की (key) लॉगिन

पासवर्ड ऑथेंटिकेशन तुमचा पासवर्ड आधीच एनक्रिप्टेड असलेल्या चॅनेलमध्ये पाठवते आणि sshd तो अकाउंट डेटाबेसशी पडताळून पाहते, जे सहसा PAM (pluggable authentication modules) द्वारे केले जाते. यासाठी कोणत्याही पूर्वतयारीची गरज नसते, म्हणूनच सर्व्हर प्रोव्हायडर तुम्हाला फक्त root पासवर्डसह नवीन सर्व्हर देऊ शकतात.

यातील कमकुवतपणा एनक्रिप्शनमध्ये नाही. पासवर्ड हे एक छोटे गुपित असते, तुम्ही प्रत्येक लॉगिनवेळी ते सर्व्हरला पाठवता आणि पोर्ट 22 वर जगभरातील बॉट्स सतत पासवर्डचा अंदाज घेत असतात.

पब्लिक की (public key) ऑथेंटिकेशन वेगळ्या पद्धतीने काम करते. तुम्ही तुमच्या स्वतःच्या मशीनवर एक की-पेअर (key pair) तयार करता. पब्लिक की सर्व्हरवरील तुमच्या अकाउंटमध्ये ~/.ssh/authorized_keys मध्ये ठेवली जाते. प्रायव्हेट की (private key) तुमच्या लॅपटॉपवरच राहते आणि ती कधीही सर्व्हरला पाठवली जात नाही. लॉगिन करण्यासाठी, क्लायंट की एक्सचेंजमधील सेशन आयडेंटिफायरसह डेटाचा एक भाग साइन (sign) करतो आणि सर्व्हर त्याच्याकडे असलेल्या पब्लिक कीचा वापर करून ती स्वाक्षरी पडताळतो. स्वाक्षरी केलेला डेटा केवळ त्या एका सेशनपुरताच मर्यादित असल्याने, चोरलेली स्वाक्षरी इतर कोणत्याही कामासाठी निरुपयोगी ठरते.

प्रक्रियेची दिशा लक्षात ठेवा, कारण ती उलट करणे सामान्य आहे आणि ते धोकादायक ठरू शकते: पब्लिक की सर्व्हरवर जाते, तर प्रायव्हेट की तुमच्याकडे सुरक्षित राहते. सर्व्हरवर कॉपी केलेली प्रायव्हेट की आता विश्वासार्ह राहत नाही.

की लॉगिनमध्येही काही त्रुटी असू शकतात. जर फाईल परमिशन खूप मोकळ्या (loose) असतील, तर sshd की दुर्लक्षित करते आणि सर्व्हर लॉगमध्ये तसा संदेश देते:

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

क्लायंट तुम्हाला फक्त Permission denied (publickey) असा संदेश देतो, जो अनेक वेगवेगळ्या कारणांसाठी सारखाच असतो. त्यामुळे पब्लिक की एरर नीट वाचणे हे लॉक-आउट होण्यापूर्वी शिकणे फायदेशीर ठरते. की तयार करणे, त्यांना पासफ्रेजने सुरक्षित करणे आणि एजंटमध्ये लोड करणे यांसारखी व्यावहारिक कामे SSH की व्यवस्थापन मध्ये दिली आहेत, आणि स्वतःला लॉक न करता पासवर्ड लॉगिन बंद करणे VPS वर SSH सुरक्षित करणे या विभागात दिले आहे.

SFTP, scp आणि पोर्ट फॉरवर्डिंग एकाच कनेक्शनचा वापर करतात

SSH विश्वातील इतर सर्व गोष्टी कशा प्रकारे कार्य करतात, हे समजून घेण्यासाठी ही संकल्पना महत्त्वाची आहे. ऑथेंटिकेशन एक एनक्रिप्टेड कनेक्शन उघडते आणि त्या एकाच कनेक्शनवरून एकाच वेळी अनेक स्वतंत्र चॅनेल चालू शकतात. शेल हा अशा अनेक चॅनेलपैकी एक प्रकार आहे.

• रिमोट शेल: ssh you@server एक सेशन चॅनेल उघडते आणि इंटरअॅक्टिव्ह शेलची विनंती करते.
• एकच कमांड: ssh you@server uptime एक चॅनेल उघडते, एक कमांड चालवते, आउटपुट प्रिंट करते आणि बंद होते.
• SFTP: क्लायंट sshd ला त्याचे sftp सबसिस्टम सुरू करण्यास सांगतो आणि फाईल ट्रान्सफर त्याच कनेक्शनच्या आत चालते. SFTP हा एक फाईल ट्रान्सफर प्रोटोकॉल आहे जो SSH वर चालतो; याची रचना FTP शी संबंधित नाही. ज्या प्रोटोकॉलमध्ये FTP ला एनक्रिप्शन जोडले आहे, त्याला FTPS म्हणतात आणि तो पूर्णपणे वेगळा आहे.
• scp: त्याच लॉगिनचा वापर करून फाईल्स कॉपी करते. 2022 मध्ये रिलीज झालेल्या OpenSSH 9.0 पासून, scp डीफॉल्टनुसार अंतर्गत SFTP प्रोटोकॉलचा वापर करते.
• पोर्ट फॉरवर्डिंग: ssh -L 8080:localhost:80 you@server तुमच्या लॅपटॉपवरील पोर्ट 8080 ला सर्व्हरवरील पोर्ट 80 चे प्रवेशद्वार बनवते, जे एनक्रिप्टेड कनेक्शनच्या आतून वाहून नेले जाते. -R विरुद्ध दिशेने फॉरवर्डिंग करते आणि -D 1080 सेशनला SOCKS प्रॉक्सीमध्ये रूपांतरित करते.
• Git: git@github.com:user/repo.git सारखे रिमोट हे एक SSH लॉगिन असते, ज्याच्या रिमोट बाजूला शेलऐवजी कमांड हँडलर चालतो.
• rsync आणि Ansible हे देखील SSH क्लायंट आहेत. ते एक चॅनेल उघडतात, काहीतरी चालवतात आणि आउटपुट वाचतात.

या यादीतील प्रत्येक गोष्ट एकाच पोर्टचा, एकाच होस्ट की चेकचा आणि एकाच क्रेडेंशियल्सचा वापर करते. म्हणूनच एकदा की ऑथेंटिकेशन सेट केल्यावर त्याचा फायदा लगेच मिळतो: यातील प्रत्येक टूल त्याचा वारसा घेते. म्हणूनच तीच ~/.ssh/config फाईल, जी तुमचे लॉगिन सुलभ करते, जेव्हा तुम्ही एका लॅपटॉपवरून अनेक Linux सर्व्हर्स व्यवस्थापित करता तेव्हा तीच फाईल स्केलेबल ठरते.

SSH काय करत नाही

• हे तुमच्या सर्व्हरला सुरक्षित करत नाही. SSH फक्त दरवाजापर्यंतचा मार्ग सुरक्षित करते. दरवाजा तिथेच असतो आणि लोक त्याचे हँडल ओढून पाहण्याचा प्रयत्न करतच राहतील. fail2ban वापरून वारंवार होणारे लॉगिन प्रयत्न रोखणे हे ट्रॅफिकचे प्रमाण हाताळते आणि केवळ key-based authentication वापरल्यामुळे ते कशाचा अंदाज लावू शकत नाहीत, हे सुनिश्चित होते.
• हे तुम्हाला तुमच्या स्वतःच्या मशीनपासून सुरक्षित ठेवत नाही. ज्याच्याकडे तुमच्या लॅपटॉपचा ॲक्सेस आहे, त्याच्याकडे तुमची private key आणि loaded agent दोन्ही असतात.
• तुम्ही SSH वापरत आहात हे हे लपवत नाही. पोर्ट नंबर आणि cleartext version banner द्वारे याची माहिती मिळते.
• कनेक्शन प्रस्थापित होण्यापूर्वी काय घडते, हे यात समाविष्ट नसते. नाव शोधणे (name lookup) आणि कोणत्या पत्त्यावर विश्वास ठेवायचा हा तुमचा निर्णय, या गोष्टी आधी घडतात.

पुढील पावले

जर तुमच्याकडे सध्या एखाद्या प्रोव्हायडर कन्सोलमध्ये नवीन सर्व्हर उघडा असेल, तर त्याचे कार्यपद्धतीचे क्रम निश्चित आहे. सर्व्हरमध्ये प्रवेश करा, एक सामान्य युजर तयार करा, तुमची key इन्स्टॉल करा आणि त्यानंतर सोपे मार्ग बंद करा. नवीन VPS वरील पहिली दहा मिनिटे या लेखात सुरुवातीपासून शेवटपर्यंतची प्रक्रिया दिली आहे, आणि जर तुम्हाला यातील संज्ञा नवीन वाटत असतील तर VPS म्हणजे नक्की काय हा लेख तुम्हाला त्या मशीनची मूलभूत माहिती देईल. त्यानंतर, keys आणि hardening हे दोन लेख याच क्रमाने वाचावेत.

FAQ

SSH चा अर्थ काय आहे?

SSH म्हणजे secure shell. हे एका रिमोट कॉम्प्युटरवर लॉग-इन करण्यासाठी आणि एनक्रिप्टेड कनेक्शनद्वारे त्यावर कमांड्स चालवण्यासाठी वापरले जाणारे प्रोटोकॉल आहे, जे RFC 4251 ते RFC 4254 मध्ये परिभाषित केले आहे. OpenSSH ही अशी अंमलबजावणी आहे जी जवळजवळ प्रत्येकजण वापरतो: तुमच्या मशीनवरील ssh क्लायंट आणि रिमोट मशीनवरील sshd सर्व्हर. याने telnet ची जागा घेतली, जे पासवर्डसह सर्व माहिती नेटवर्कवर प्लेन टेक्स्टमध्ये पाठवत असे.

SSH पोर्ट 22 का वापरते?

IANA ने 1995 मध्ये SSH ला पोर्ट 22 नियुक्त केले, जे FTP (21) आणि telnet (23) च्या शेजारी आहे, ज्यांना बदलण्यासाठी हे प्रोटोकॉल लिहिले गेले होते. या क्रमांकाचा वापर करणे अनिवार्य नाही: सर्व्हरवर /etc/ssh/sshd_config मधील Port ते बदलू शकते आणि क्लायंटवर ssh -p द्वारे वेगळा पोर्ट निवडता येतो. 22 हा डीफॉल्ट पोर्ट असल्याने, स्वयंचलित स्कॅनर्स सतत त्यावर प्रयत्न करत असतात, म्हणूनच नवीन सर्व्हरची /var/log/auth.log फाईल Failed password for invalid user ओळींनी भरून जाते. पोर्ट बदलल्याने हा त्रास कमी होतो, परंतु यामुळे कोणतीही वास्तविक सुरक्षा मिळत नाही.

SSH ने होस्ट की बदलल्याची चेतावणी दिल्यास मी काय करावे?

कोणतीही गोष्ट हटवण्यापूर्वी त्याचे कारण शोधा. सामान्यतः याचे कारण निरुपद्रवी असते: सर्व्हर पुन्हा तयार (rebuild) केला गेल्यामुळे sshd ने नवीन होस्ट की तयार केल्या असतील, किंवा जुन्या IP ॲड्रेसवर नवीन मशीन आले असेल. जर तुम्हाला माहित असेल की मशीन पुन्हा तयार केले आहे, तर साठवलेली की काढून टाकण्यासाठी ssh-keygen -R <host> चालवा, पुन्हा कनेक्ट करा आणि तुम्हाला दिसणारा फिंगरप्रिंट तुमच्या प्रोव्हायडर कन्सोलवर दिलेल्या फिंगरप्रिंटशी जुळवून पहा. जर तुमच्या बाजूने काहीही बदलले नसेल, तर कनेक्ट करू नका आणि पासवर्ड टाकू नका. याच कारणास्तव OpenSSH या स्थितीत पासवर्ड ऑथेंटिकेशन नाकारते.

SFTP आणि scp हे SSH पेक्षा वेगळे आहेत का?

ते SSH वर चालतात. एकदा तुम्ही ऑथेंटिकेट झाल्यावर, SSH कनेक्शन अनेक चॅनेल वाहून नेऊ शकते आणि शेल हे त्यापैकी फक्त एक आहे. SFTP हा एक फाईल ट्रान्सफर प्रोटोकॉल आहे जो त्याच कनेक्शनवर sshd च्या sftp सबसिस्टमचा वापर करतो आणि OpenSSH 9.0 पासून scp अंतर्गत SFTP प्रोटोकॉलचा वापर करत आहे. पोर्ट फॉरवर्डिंग आणि SSH द्वारे Git हे देखील त्याच कनेक्शनवरील चॅनेल आहेत. हे सर्व एकाच पोर्टचा, एकाच होस्ट की चेकचा आणि एकाच लॉग-इनचा वापर करतात. लक्षात ठेवा की SFTP म्हणजे एनक्रिप्शन जोडलेले FTP नाही; त्याला FTPS म्हणतात आणि तो एक वेगळा प्रोटोकॉल आहे.

की ऑथेंटिकेशन खरोखर पासवर्डपेक्षा चांगले आहे का?

हो, इंटरनेटवरून ॲक्सेस करता येणाऱ्या कोणत्याही सर्व्हरसाठी हे खरे आहे. पासवर्ड हे एक लहान गुपित असते जे तुम्ही प्रत्येक लॉग-इनच्या वेळी सर्व्हरला देता आणि पोर्ट 22 वर स्वयंचलित क्लायंटद्वारे सतत अंदाज लावले जातात. की-पेअर (key pair) वापरल्यास, प्रायव्हेट की कधीही तुमच्या मशीनबाहेर जात नाही: क्लायंट सध्याच्या सत्राशी संबंधित डेटावर स्वाक्षरी करतो आणि सर्व्हर ~/.ssh/authorized_keys मधील पब्लिक कीच्या आधारे त्या स्वाक्षरीची पडताळणी करतो. रेकॉर्ड केलेली स्वाक्षरी दुसऱ्या सर्व्हरवर पुन्हा वापरता येत नाही. प्रायव्हेट कीला पासफ्रेजने सुरक्षित ठेवा, कारण पासफ्रेज नसलेली की फाईल ती कॉपी करणाऱ्या कोणासाठीही थेट लॉग-इनचे साधन ठरू शकते.