SSH पर पासवर्ड प्रमाणीकरण एक सामान्य सर्वर की सबसे बड़ी खुली सतह है। इसके ख़िलाफ़ न Fail2ban मदद करता है, न कोई सीमा: घंटे में एक कोशिश वाले हज़ार पते कभी किसी सीमा तक नहीं पहुँचेंगे, और वे ठीक तब तक अनुमान लगाते रहेंगे जब तक अनुमान लगाना संभव है। कुंजियाँ इस संभावना को ही हटा देती हैं, और पूरी hardening सूची में यही एक सेटिंग है जो स्थिति को गुणात्मक रूप से बदलती है।

इसमें डरावनी बस एक ही बात है: पासवर्ड बंद करके बाहर रह जाना। नीचे वह क्रम है जिसमें ऐसा नहीं हो सकता।

कुंजी

अपनी मशीन पर बनाई जाती है, सर्वर पर नहीं:

ssh-keygen -t ed25519 -C "work laptop"

RSA नहीं, ed25519: छोटी, तेज़, और लंबाई के सवालों से मुक्त। RSA सिर्फ़ तब चाहिए जब किसी बहुत पुरानी चीज़ तक पहुँचना हो; तब -t rsa -b 4096।

कुंजी पर पासफ़्रेज़ लगाना ठीक रहता है: कुंजी फ़ाइल लैपटॉप से चुराई जा सकती है, और पासफ़्रेज़ के बिना वह तुरंत काम करती है। इसे हर बार टाइप नहीं करना पड़ेगा — यह ssh-agent सँभालता है, और macOS तथा ज़्यादातर डेस्कटॉप Linux पर वह पहले से चल रहा होता है।

सर्वर पर कॉपी करने में एक कमांड लगती है, जब तक पासवर्ड अभी काम कर रहा है:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

अगर ssh-copy-id उपलब्ध न हो, तो .pub फ़ाइल की सामग्री सर्वर पर ~/.ssh/authorized_keys में एक पंक्ति के रूप में जोड़ी जाती है। अनुमतियाँ मायने रखती हैं: .ssh डायरेक्टरी 700, फ़ाइल 600, उपयोगकर्ता के स्वामित्व में। किसी और सूरत में sshd चुपचाप फ़ाइल पढ़ने से मना कर देता है, और यही «कुंजी काम नहीं करती» का सबसे आम कारण है।

वह जाँच जो सब तय कर देती है

कुछ भी बंद करने से पहले, पहला कनेक्शन बंद किए बिना दूसरा खोलें:

ssh -o PasswordAuthentication=no user@203.0.113.25

यह विकल्प क्लाइंट को पासवर्ड पर लौटने से रोकता है — यानी अगर लॉगिन हुआ, तो कुंजी से हुआ। जब तक यह कमांड काम न करे, आगे न बढ़ें। और पहला कनेक्शन आख़िर तक खुला रखें: जो कुछ आप तोड़ पाएँ, उसे यही ठीक करता है।

पासवर्ड बंद करना और एक ग़ैरज़ाहिर पेच

सेटिंग्स अलग फ़ाइल में जाती हैं ताकि पैकेज अपडेट उन्हें ऊपर से न लिख दे। पर फ़ाइल का नाम मायने रखता है:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

बात यह है कि OpenSSH किसी पैरामीटर के लिए जो पहली क़ीमत मिलती है उसे लेता है, न कि आख़िरी, जैसा लगभग हर जगह होता है। sshd_config.d की फ़ाइलें वर्णक्रम में पढ़ी जाती हैं, और Ubuntu की क्लाउड छवियाँ वहाँ 50-cloud-init.conf रखती हैं, जिसमें अक्सर PasswordAuthentication yes होता है। ऐसे में 90 नंबर वाली आपकी फ़ाइल कुछ नहीं करेगी: सेटिंग लगी हुई दिखेगी और पासवर्ड काम करता रहेगा। इसीलिए नंबर 10 — वह पहले पढ़ी जाती है।

असल में क्या निकला, यह अनुमान लगाए बिना देखा जा सकता है:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

यह कमांड सभी include के बाद की प्रभावी कॉन्फ़िगरेशन छापती है। इसी पर भरोसा करें, फ़ाइलों की सामग्री पर नहीं।

फिर वाक्य-रचना की जाँच और सेवा का नरम पुनःलोड:

sudo sshd -t && sudo systemctl reload ssh

sshd -t अनिवार्य है: restart के साथ कॉन्फ़िग में टाइपो सेवा को बंद और आपको बाहर छोड़ देता है। reload खुले सत्रों को भी नहीं तोड़ता।

Ubuntu 24.04: पोर्ट वहाँ नहीं है जहाँ आप सोचते हैं

हाल के Ubuntu पर एक अलग जाल: वहाँ sshd systemd सॉकेट के ज़रिये शुरू होता है। इस मोड में sshd_config की Port पंक्ति कुछ नहीं करती — सुनता सॉकेट है, डीमन नहीं। अगर आप पोर्ट बदल रहे हैं, तो संपादन यही चाहिए:

sudo systemctl edit ssh.socket

और ListenStream= (ख़ाली क़ीमत पिछली को रीसेट करती है) में नया पोर्ट बताना होगा। जो लक्षण इसे खोलता है: कॉन्फ़िग बदला, सेवा दोबारा चालू की, और सर्वर अब भी 22 पर जवाब देता है।

पोर्ट बदलने की बात चली है तो: सुरक्षा के रूप में यह काम नहीं करता — स्कैनर किसी भी पोर्ट पर सेवा मिनटों में ढूँढ़ लेते हैं। इसका एकमात्र असर शांत लॉग है, क्योंकि सामूहिक अनुमान सिर्फ़ 22 पर जाता है। यह सुविधाजनक है, पर इसे सुरक्षा से न मिलाएँ।

लॉगिन की अनुमति किसे है

एक काम की चीज़ है स्पष्ट सूची:

AllowUsers deploy admin

जो सूची में नहीं, वह कुंजी जाँचे जाने से पहले ही कट जाता है। इससे वह मामला भी ढँक जाता है जब कोई पैकेज शेल और होम डायरेक्टरी वाला सिस्टम उपयोगकर्ता बना देता है।

अंदर आने का अतिरिक्त रास्ता

एक लैपटॉप पर एक कुंजी विफलता का इकलौता बिंदु है। डिस्क मर जाती है, लैपटॉप खो जाता है, और सर्वर हमेशा के लिए अपहुँच हो जाता है। समझदार न्यूनतम:

  • authorized_keys में किसी दूसरे उपकरण से दूसरी कुंजी;
  • निजी कुंजी की प्रति पासवर्ड प्रबंधक में या एन्क्रिप्टेड स्टिक पर;
  • प्रदाता की परखी हुई कंसोल पहुँच — VNC या serial। परखी हुई का मतलब है कि आप उससे कम से कम एक बार लॉगिन कर चुके हैं, यह नहीं कि «पैनल में कहीं कोई बटन है»।

इसी मौक़े पर देख लें कि authorized_keys में पहले से क्या है — अपने उपयोगकर्ता की भी और root की भी। वहाँ पड़ी पराई कुंजी किसी भी पासवर्ड बदलाव को झेल जाती है और काम करती पहुँच बनी रहती है।

इसके बाद

पासवर्ड का अनुमान लगना ख़त्म नहीं होगा, वह बस बेकार हो जाएगा: लॉग में हज़ारों Failed password पंक्तियाँ बनी रहेंगी, जिनमें से कोई भी सफलता में नहीं बदल सकती। अब देखने लायक सफल लॉगिन हैं: किस पते से, किस उपयोगकर्ता के नाम से, किस समय। अनजाने पते से कुंजी द्वारा सफल लॉगिन दस लाख असफलताओं से कहीं ज़्यादा महत्वपूर्ण घटना है, और आम धारा में उसे देखना कहीं मुश्किल। यही तस्वीर नीचे डेमो पेज दिखाता है।