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

 (jpmens.net)
6 पॉइंट द्वारा GN⁺ 26 일 전 | अभी कोई टिप्पणी नहीं है. | 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

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.