SSH प्रमाणपत्र: एक बेहतर SSH अनुभव

 (jpmens.net)
6 पॉइंट द्वारा GN⁺ 2026-04-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SSH प्रमाणपत्र पारंपरिक public key-आधारित SSH authentication की जटिलताओं को हल करते हैं और client तथा server के बीच automatic trust प्रदान करते हैं
  • OpenSSH 5.4 से समर्थित, जहाँ CA (Certificate Authority) user और host keys पर हस्ताक्षर करता है ताकि authorized_keys बदले बिना authentication हो सके
  • प्रमाणपत्रों में validity period, allowed users (principal), access IP, forced command (force-command) जैसी जानकारी शामिल की जा सकती है, जिससे सूक्ष्म access control संभव होता है
  • TOFU (Trust on First Use) प्रक्रिया हट जाती है, और host key बदलने पर भी बिना warning के सुरक्षित रूप से connect किया जा सकता है
  • automatic signing server या tools की मदद से बड़े server environment में SSH management automation और security में सुधार संभव है

SSH प्रमाणपत्र का अवलोकन और पारंपरिक SSH key-आधारित authentication की सीमाएँ

  • SSH connection के समय पहली बार access किए जा रहे server की host key fingerprint जांचनी होती है, लेकिन ज़्यादातर user इसे verify किए बिना 'yes' दर्ज कर TOFU (Trust on First Use) पद्धति का उपयोग करते हैं
    • admin server का fingerprint सीधे जाँच सकते हैं या ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key कमांड से verify कर सकते हैं
  • public key-आधारित authentication password के बिना login की सुविधा देता है, लेकिन हर server के authorized_keys फ़ाइल में public key तैनात करनी पड़ती है
  • SSH agent (ssh-agent) का उपयोग करने पर private key memory में रखी जा सकती है, जिससे बार-बार input दिए बिना authentication संभव होता है
  • पारंपरिक तरीके की सीमाएँ
    • हर user के लिए server पर public key कॉपी करनी पड़ती है
    • host key बदलने पर client में warning message दिखाई देता है
    • TOFU के कारण trust management असुविधाजनक हो जाता है

SSH प्रमाणपत्र और Certificate Authority (CA)

  • SSH Certificate को OpenSSH 5.4 (मार्च 2010) से support किया गया है, और यह मौजूदा SSH key format का विस्तारित रूप है
  • SSH CA एक SSH key pair से बना होता है, जहाँ public key trust root की भूमिका निभाती है
  • मुख्य फायदे
    • server की authorized_keys फ़ाइल में बदलाव की ज़रूरत नहीं
    • host key बदलने पर कोई warning नहीं
    • TOFU प्रक्रिया हटने से automatic trust संभव
    • प्रमाणपत्र में allowed user (principal), allowed IP, validity period, forced command (force-command) आदि शामिल किए जा सकते हैं
    • प्रमाणपत्र expire होने पर access अपने आप बंद हो जाता है

SSH CA सेटअप और signing प्रक्रिया

  • CA system पर ECDSA algorithm से CA key pair बनाना
    • ssh-keygen -t ecdsa -C "SSH CA" -f CA/ssh-ca
  • user अपनी public key (*.pub) CA को देता है, और CA उस पर sign करके certificate (*-cert.pub) जारी करता है
    • उदाहरण: ssh-keygen -s CA/ssh-ca -I "Jane Jolie" -n jane -z 001 -V +1w jane.pub
  • server configuration
    • CA public key को /etc/ssh/ssh-ca.pub में सहेजें और TrustedUserCAKeys setting जोड़ें
    • server host key को CA से sign करें (ssh-keygen -h -s CA/ssh-ca ...) और HostCertificate entry में दर्ज करें
  • client configuration
    • known_hosts फ़ाइल में @cert-authority की एक line जोड़ें
    • उदाहरण: @cert-authority *.example.com $(cat CA/ssh-ca.pub)

SSH certificate-आधारित connection और verification

  • user signed certificate और private key को साथ में उपयोग करके connect करता है (ssh -i jane -l jane alice.example.com)
  • server log में certificate का ID, serial number, CA fingerprint दर्ज होता है
  • कई hostnames या IP को certificate के principal के रूप में जोड़ा जा सकता है
  • certificate में दिए गए principal के अलावा किसी और user से login की कोशिश करने पर “Certificate invalid: name is not a listed principal” error आता है
  • certificate में forced command (force-command) या allowed IP (source-address) सेट करके सूक्ष्म access control किया जा सकता है

जाँच और troubleshooting checklist

  • server-side जाँच बिंदु

    • TrustedUserCAKeys setting और CA public key की उपलब्धता
    • host key signing और HostCertificate निर्दिष्ट होना
    • sshd को restart करना आवश्यक

  • client-side जाँच बिंदु

    • user key CA द्वारा signed होनी चाहिए
    • known_hosts में @cert-authority entry और principal का मेल होना चाहिए
    • certificate expire होने पर “Certificate invalid: expired” message दिखता है
    • certificate constraints मेल न खाने पर password prompt आ सकता है
    • SSH agent में certificate जोड़ने पर key और certificate दोनों register होते हैं (ssh-add jane)
    • signing के समय option (-O) से features नियंत्रित किए जा सकते हैं
    • उदाहरण: -O clear से सभी permissions हटाकर केवल permit-agent-forwarding, permit-port-forwarding की अनुमति देना

host key certificate automation

  • Python module sshkey-tools और BottlePy का उपयोग करके automatic signing server (hkbot) बनाया जा सकता है
    • CA server पर hkbot.py चलाने के बाद HTTP request के माध्यम से host public key upload करने पर वह अपने आप sign हो जाती है
    • client पर curl -F hostkey=@/etc/ssh/ssh_host_ed25519_key.pub http://CA:8870 | sh कमांड से automatic install किया जा सकता है
    • /etc/ssh/sshd_config को modify और verify करने के बाद systemctl restart sshd से लागू करें
  • इसके बाद SSH connection के समय certificate-आधारित automatic trust और login संभव हो जाता है

SSH प्रमाणपत्रों के फायदे का सारांश

  • TOFU की ज़रूरत नहीं, client और server के बीच automatic trust
  • कम अवधि वाले valid certificates जारी करके अस्थायी access control संभव
  • certificate expire होने पर access अपने आप बंद, authorized_keys साफ़ करने की ज़रूरत नहीं
  • forced command, PTY restriction, access IP control जैसी सूक्ष्म policy settings संभव
  • automation tools से बड़े server environment का management सरल किया जा सकता है
  • संबंधित project के रूप में Smallstep SSH का परिचय

अतिरिक्त संदर्भ सामग्री

अपडेट

  • SSH CA ऐसे environments में विशेष रूप से उपयोगी है जहाँ अपने server हों और root access उपलब्ध हो
  • multi-user system में पारंपरिक known_hosts और authorized_keys तरीका अब भी आवश्यक है
  • SSH certificate format standardization draft: draft-miller-ssh-cert-06

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-04
Hacker News की राय

  • यह हैरानी की बात है कि लोग अब भी SSH password इस्तेमाल करते हैं
    खासकर बड़े enterprise environment में कई password policies आपस में उलझी होती हैं, इसलिए सिर्फ server में login करने में भी बहुत समय लग जाता है
    इसलिए ssh-keygen से key इस्तेमाल करने को कहो तब भी ज्यादातर लोग “कभी न कभी कर लूंगा” सोचते हैं और आखिर में करते नहीं

    • key तब उपयोगी होती हैं जब किसी व्यक्ति या कंपनी के पास central management system हो
      लेकिन व्यवहार में अक्सर एक ही shared key कई servers पर इस्तेमाल होती है, या keys share की जाती हैं, जिससे management आसानी से बिखर जाता है
      password का कम से कम यह फायदा है कि वह simple होता है
    • मैं कई सालों से Yubikey-आधारित HSM से SSH keys manage कर रहा हूँ
      password नहीं है, लेकिन login करते समय Yubikey को physically touch करना पड़ता है
    • ssh-copy-id जैसे distributed key usage से hackers के लिए network के अंदर lateral movement आसान हो जाता है, इसलिए कई organizations इसे रोकती हैं

  • हर कुछ महीनों में कोई न कोई फिर से SSH certificates खोजता है और उस पर blog post लिखता है
    मैंने भी 15 साल पहले इससे संबंधित लेख लिखा था, लेकिन अब देखता हूँ तो वह अधूरा था

    • बहुत से लोग key और certificate को गड़बड़ा देते हैं
      security engineers भी कभी-कभी भूल जाते हैं कि वे SSH certificate नहीं बल्कि key authentication इस्तेमाल कर रहे हैं
    • SSH certificates उपयोगी हैं क्योंकि वे किसी खास user को सीमित अवधि और permissions के साथ access दे सकते हैं
    • मुझे भी SSH certificates के बारे में पता था, लेकिन मैं key-based setup से migrate नहीं कर पाया
      कई servers की keys manually manage करना बहुत झंझट वाला है
      अब सोच रहा हूँ कि क्या अभी भी switch करना फायदेमंद होगा
    • 10 साल पहले जब मेरी नौकरी में SSH CA बनाया गया था, तब ऊपर वाला blog post संदर्भ के रूप में इस्तेमाल किया था

  • TOFU(Trust On First Use) तरीका simple है, लेकिन काफी दूर तक काम कर जाता है
    अपने servers पर host key को एक बार खुद verify कर लूँ, तो मेरे लिए वह काफी है
    बड़े enterprise environment में internal servers की public key list को SSL-signed internal website पर डाल सकते हैं
    लेकिन जहाँ servers बहुत ज्यादा हों या बार-बार बदलते हों, वहाँ certificates कहीं बेहतर हैं, और TOFU की कई सीमाएँ हैं
    अच्छा होता अगर browser में भी server TLS key बदलने पर alert करने की सुविधा होती

    • मैं 1996 से SSH इस्तेमाल कर रहा हूँ, लेकिन वास्तव में public key को manually verify करने वाला किसी को नहीं देखा
      ज्यादातर लोग बस “yes” टाइप करके आगे बढ़ जाते हैं

  • कंपनी में Zscaler की SSL inspection की वजह से बहुत समय और पैसा बर्बाद होता है
    “self-signed certificate in certificate chain” error आते ही हमेशा सिरदर्द शुरू हो जाता है

    • मैंने एक दोस्त की कंपनी के Windows 11 में installed Zscaler का analysis किया था, और वह लगभग malware के स्तर का लगा
      वह अपना root certificate install करता है और browser settings lock कर देता है ताकि proxy इस्तेमाल न किया जा सके
      Firefox या Chrome settings files बदलो, तो वह उन्हें तुरंत overwrite कर देता है
      यहाँ तक कि GUI में इसे बंद करने के लिए भी IT password चाहिए
      Cybereason antivirus से बस थोड़ा ही बेहतर है
    • हमारी कंपनी का Cisco Umbrella भी ऐसा ही है
      यह सभी HTTP-based protocols को तोड़ देता है
      Git, RubyGems, go mod, Nix जैसे ढेरों tools टूट जाते हैं
      vendor कहता है कि यह “transparent” है, लेकिन असल में बिलकुल नहीं
      समस्या diagnose करने में घंटों लग जाते हैं, और ज्यादातर admins को इसकी इस तबाही मचाने वाली क्षमता का पता ही नहीं होता
    • वैसे, SSH certificates X.509 certificates से अलग हैं

  • लेख में CA certificates के फायदों का ही ज़िक्र था, लेकिन नुकसान भी साफ़ तौर पर मौजूद हैं
    मैंने TOFU की वजह से कभी कोई security issue नहीं झेला

    • “अब तक कोई incident नहीं हुआ, इसलिए यह safe है” कहना वैसा ही है जैसे seatbelt न लगाने को सही ठहराना
      अगर SSH certificates के नुकसान हैं, तो वे ठोस रूप से क्या हैं, यह जानना चाहूँगा
    • TOFU सुविधाजनक है, लेकिन अनिवार्य नहीं
      security मजबूत करनी हो तो USB जैसे secure channel से public key exchange कर सकते हैं
      certificates इस्तेमाल करने पर भी आखिरकार वही प्रक्रिया करनी पड़ती है, बस management user से admin की तरफ खिसक जाता है
      बड़े organizations में certificates उपयोगी हो सकते हैं, लेकिन सामान्य security गुण समान रहते हैं
    • अगर CA configuration पहले से सेट की जा सकती है, तो TOFU से बचा जा सकता है
      इसे installation script या deployment image में शामिल किया जा सकता है
      TOFU का मतलब सिर्फ तब है जब पहले से setup किए गए box को access करना हो
    • “TOFU की वजह से अभी तक कोई security incident नहीं हुआ” का मतलब बस इतना है कि अभी तक नहीं हुआ

  • हमारे dev/stg environment में हम हर दिन आधी machines फिर से reinstall करते हैं
    SSH host certificates की वजह से known_hosts मिटाने या keys बचाए रखने की ज़रूरत नहीं पड़ती, इसलिए यह बहुत सुविधाजनक है

  • मैं personal project के तौर पर Sshifu नाम का tool बना रहा हूँ
    यह SSH certificate-based login और SSO को आसान बनाने वाला tool है
    server पर sshifu-server install करके उसे CA की तरह इस्तेमाल करते हैं, और हर SSH server को इस CA पर trust करने के लिए configure किया जाता है
    user को बस npx sshifu command से login करना होता है
    GitHub repository देखें

  • वास्तविक production environment में certificate-based access अक्सर जटिल management problems तक ले जाता है
    certificate expiry, user removal, server failure के समय login जैसी कई तरह की समस्याएँ आती हैं
    Userify में 15 साल से ऐसे मुद्दों से निपटा गया है, और stable SSH authentication infrastructure बनाना बिल्कुल आसान नहीं है

    • लेकिन मेरा मानना है कि SaaS model सबसे खराब विकल्प है

  • pico.sh में SSH certificate support जोड़ा गया, और RBAC-style access control लागू कर पाने की वजह से यह बहुत उपयोगी साबित हुआ
    documentation link देखें

  • production में SSH certificates उल्टा complexity को centralize करके समस्या बढ़ा देते हैं
    single CA हमेशा available होना चाहिए, और failure होने पर पूरा access रुक जाता है
    TTL tuning, trust root management, debugging की कठिनाई जैसी व्यावहारिक समस्याएँ भी बहुत हैं
    अंत में लोग फिर से cache या agents वापस ले आते हैं
    हमने इसका उल्टा किया: हर node HTTPS के ज़रिए user information को local authorized_keys में sync करता है
    इससे central control बना रहता है, लेकिन failure localized रहता है
    Userify में यही तरीका इस्तेमाल हो रहा है, और यह authentication के साथ permission management भी संभालता है
    सिर्फ certificates से user creation, sudo roles, home directory cleanup जैसी समस्याएँ हल नहीं होतीं

    • किसी ने पूछा: TOFU को कैसे हल करते हैं?