Page cover

SSH Certificate Based Authentication အကြောင်းတစေ့တစောင်း

Linux ကိုစအသုံးပြုတော့မယ်ဆိုတာနဲ့ SSH အကြောင်းကိုအခြေခံအားဖြင့်နားလည်ထားရပါ့မယ်။ SSH မှာဘယ် command ကိုအသုံးပြုပြီးတော့ SSH server daemon ကို setup လုပ်သလဲ၊ sshd_config ကိုဘယ်လိုမျိုးစနစ်တကျလုပ်ရသလဲဆိုတာအပြင်၊ SSH client ဘက်မှာလည်း ဘယ်လို command တွေကိုအသုံးပြုပြီး remote server ထဲကိုဝင်ရသလဲဆိုတာမျိုးကိုတော့ စာရေးသူတို့ သိထားရပါတယ်။ သို့သော် SSH ဟာ remote server ထဲကိုဝင်ဖို့သက်သက်မဟုတ်ပဲနဲ့ OpenSSH suite မှာတခါတည်းပါလာတဲ့ အခြားသော feature တွေလည်းရှိပါတယ်။ ဥပမာဆိုရင် SCP လိုမျိုး file တွေ၊ folder တွေကို local machine ကနေ၊ remote server ထဲကို copy လုပ်တဲ့အခါမှာအသုံးပြုနိုင်တဲ့ utility ဟာ SSH ပေါ်မှာအခြေခံထားပါတယ်။ ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတဲ့ အခြားသော SSH tunneling feature တွေလည်းရှိပါတယ်။ SSH tunneling အကြောင်းလေ့လာချင်ရင်တော့ ဒီ link https://my.itmatic101.com/others/ssh-tunneling-intro မှာသွားကြည့်လို့ရပါတယ်။ ဒါ့အပြင် မကြာသေးခင်ကမှ အလုပ်ခွင်မှာ အခြားသူတွေ မတူတဲ့ SSH workflow တွေကိုအသုံးပြုနေတာကို သတိထားမိလို့ အဲ့ဒီအကြောင်းကို article တခုရေးဖြစ်ပါသေးတယ်။ အဲ့ဒီထဲမှာ SSH မှာအသုံးပြုနိုင်တဲ့ authentication method တွေအကြောင်းကို ဆွေးနွေးဖြစ်ခဲ့ပါတယ်။ Certificate based authentication ကိုလည်းထည့်သွင်း ဖော်ပြဘူးတာကြောင့် ဒီ article မှာတော့ အဲ့ဒီအကြောင်းတခုတည်းကို ရေးဖို့စိတ်ကူးဖြစ်ခဲ့ပါတယ်။ SSH workflow အကြောင်းကိုဖတ်ချင်ရင်တော့ ဒီ link https://my.itmatic101.com/others/akhyekhan-ssh-workflow-myaa ကနေသွားပြီးတော့ဖတ်လို့ရပါတယ်။

ပုံမှန်အားဖြင့် SSH မှာ username နဲ့ password ကိုအသုံးပြုနိုင်ပါတယ်။ သို့သော် လုံခြုံရေးအတွက် password ကိုရသလောက်ရှောင်ရှားသင့်ပါတယ်။ ဒီထက်တဆင့်မြင့်ပြီး password အစား SSH public/private key authentication ကိုအသုံးပြုနိုင်ပါတယ်။ Key authentication ဟာ လုံခြုံရေးအရရော၊ အဆင်ပြေမူအတွက်ရောနှစ်ခုလုံးအတွက် အသုံးတည့်နိုင်ပါတယ်။ ပြဿနာက ကြိုတင်ပြင်ဆင်ဖို့အတွက်လုပ်ရတဲ့ လုပ်ငန်းဆောင်တာတွေရှိတာရယ်၊ လုံခြုံရေးအတွက်ဟာကွက်တခုလည်းရှိနေပြန်ပါတယ်။

Key based authentication ပြဿနာ

SSH Key Based Authentication

Key distribution နဲ့ management အခက်အခဲ

SSH ရဲ့ key authentication ကိုအသုံးပြုမယ်ဆိုရင် user တိုင်းဟာ ssh-keygen နဲ့ public/private keys pair တခုရှိဖို့လိုပါတယ်။ ဒီနေရာမှာတော့ ဒီ key pair တွေကိုဘယ်လိုမျိုး manage လုပ်နိုင်သလဲဆိုတာကို အသေးစိတ်မရှင်းလိုပါ။ တစ်ယောက်နဲ့ တစ်ယောက် key ကို manage လုပ်ပုံလည်းကွာခြားနိုင်တာမို့ workflow ပေါ်မှာပဲမူတည်နိုင်ပါတယ်။ ဟုတ်ပြီ... ssh-keygen နဲ့ rsa သို့မဟုတ် ed25519 key အမျိုးအစားတခုကို generate လုပ်ပြီးတာနဲ့ အဲ့ဒီ key pair ထဲ public key ကို ကိုယ် remote ဝင်ချင်တဲ့ server admin ကို share ပေးရပါတယ်။ အဲ့ဒီ public key နဲ့ server admin က user account တခုဖန်တီးပြီးတော့ အဲ့ဒီ account ရဲ့ authorized_keys မှာကြိုပြီးတော့ထည့်ပေးရပါလိမ့်မယ်။ လုပ်ရတဲ့ အဆင့်တွေကအများကြီးမဟုတ်ပေမယ့်လည်း အဲ့ဒီ user ဟာ တခုထပ်ပိုတဲ့ remote server တွေကို remote ဝင်ဖို့အတွက်လိုအပ်ရင်တော့ ဖော်ပြပါ အဆင့်တွေကို နောက် server တလုံးပေါ်မှာလုပ်ရပါလိမ့်မယ်။ စာရေးသူအတွက်မှာတော့ ဒီလိုမျိုး တူညီတဲ့အဆင့်တွေကို ထပ်ခါထပ်ခါလုပ်တဲ့နေရာမှာ သက်ရှိထင်ရှားလူတစ်ယောက်ထပ်စာရင်၊ ဒီကိစ္စမျိုးမှာလူထက်သာတဲ့ computer machine တွေကိုသာ ပိုပြီးတော့ယုံကြည်စိတ်ချပါတယ်။ ဒီအတွက် automation ဟာအဖြေပါ။

နောက်တခုက... server တွေကို အကြောင်းအမျိုးမျိုးကြောင့် rebuild လုပ်တဲ့အခါမှာ အဲ့ဒီ key တွေကိုလည်းပြန်ပြီးတော့ user account တွေနဲ့ အတူတူပြန် configure လုပ်ရပါတယ်။ Git လိုမျိုး version control system တခုကို အသုံးမပြုဘူးဆိုရင် ဘယ် key ဟာဖြင့် ဘယ် user အတွက် up-to-date ဖြစ်သလဲဆိုတာမျိုး တခုချင်းစီလိုက်စစ်ဆေးရပါလိမ့်မယ်။ Automation ကိုသုံးလို့ရပေမယ့်လည်း စနစ်တကျတည်ဆောက်တဲ့ automation ဖြစ်ဖို့လိုပါလိမ့်မယ်။ ဒီလိုမှမဟုတ်ရင် အမှားများကာ troubleshoot ခဏခဏလုပ်ရလို့ အချိန်တွေကုန်ပြီး စိတ်ပင်ပန်းရလို့ automation ဆိုတဲ့ဟာကြီးကို မယုံကြည်လို့ မသုံးတော့တဲ့ culture တခုပေါက်ဖွားလာပါလိမ့်မယ်။ ဒါဟာ organisation တခုအတွက် မကောင်းတဲ့ လက္ခဏာတခုပါ။

မလုံလောက်သေးတဲ့ လုံခြုံရေး

SSH ရဲ့ key based authentication မှာ TOFU (Trust On First Use) ဆိုတဲ့ model ကိုသုံးပါတယ်။ ဆိုလိုရင်းက ပထမဆုံးတခေါက်မှာ SSH နဲ့ key authentication လုပ်တဲ့အခါ အဲ့ဒီ remote host ကို known_hosts ထဲမှာထည့်မလားမေးပါလိမ့်မယ်။ စာရေးသူ အပါအဝင် အခြားသော sysadmin တွေဟာ လုံလောက်တဲ့ verification မလုပ်ပဲနဲ့ yes လိုပဲ အလွယ်ဖြေတတ်ကြပါတယ်။ ထိုအတူ အဲ့ဒီ server တွေကို rebuild လုပ်တာပဲဖြစ်ဖြစ်၊ re-IP လုပ်တာပဲဖြစ်ဖြစ် known_hosts ထဲက fingerprint တွေမတူတာဖြစ်ပါတယ်။ အဲ့ဒီအခါမှာ SSH က man-in-the-middle (MITM) attack ဆိုပြီး false positive alert ကိုပြပါတယ်။ သေချာပေါက်သိလို့ match မဖြစ်တဲ့ fingerprint ကိုဖယ်ပြီး ပြန်ထည့်လို့ရနိုင်ပေမယ့် လုံလောက်တဲ့ verification မရှိပဲနဲ့ အလွယ်တကူပြန်ထည့်တတ်ပါတယ်။ ဒါကြောင့် adversary တွေဘက်က အဲ့ဒီအားနည်းချက်တွေကို အခွင့်ကောင်းယူပြီး exploit လုပ်ချင်ကလုပ်လို့ရနိုင်ပါတယ်။

မှတ်မှတ်ရရ ၂၀၀၈ ခုနှစ်တုန်းက SSH key authentication အတွက် CVE တခုရှိခဲ့ဘူးပါတယ်။ Debian OpenSSL Predictable PRNG (CVE-2008-0166) ဆိုပြီးလူသိများပါတယ်။ ထို CVE အကြောင်းကိုအသေးစိတ်သိချင်ရင် ဒီ GitHub link https://github.com/g0tmi1k/debian-ssh မှာသွားရောက်လေ့လာနိုင်ပါတယ်။ Exploit ကိုဘယ်လိုသုံးသလဲဆိုတာကို နောက် article တခုမှာသပ်သပ်ရေးခဲ့ဘူးပါတယ်။ အဲ့ဒီ article ကိုဖတ်ချင်ရင်တော့ ဒီ link https://my.itmatic101.com/offsec/khokme-taitme-papalhime-openssl ကနေသွားဖတ်လို့ရပါတယ်။ ဒါကြောင့် SSH key authentication ဆိုတာနဲ့ ပြီးပြည့်စုံအောင် စိတ်မချရသေးပါ။

SSH certificate based authentication ကိုဘယ်လို configure လုပ်ပုံအဆင့်ဆင့်

SSH Certificate Based Authentication

ဒီ labကို တည်ဆောက်ဖို့အတွက် စာရေးသူ LXC container နှစ်ခုကိုအသုံးပြုပါ့မယ်။ တခုကို server ကိုခေါ်ပြီး၊ နောက်တခုကိုတော့ client လို့ပဲအလွယ်ခေါ်လိုက်ပါ့မယ်။ စာရေးသူရဲ့ host machine ကိုတော့ certificate authority (CA) အနေနဲ့အသုံးပြုပြီး demo လုပ်ပြသွားပါ့မယ်။

Server-side တွင် setup လုပ်ပုံ

  • ပထမဆုံးလိုအပ်တဲ့ LXC container တွေကိုအရင်ဆုံးဖန်တီးလိုက်ရအောင်။

  • နောက်အဆင့်အနေနဲ့ host machine ပေါ်မှာ certificate authority (CA) အတွက်အောက်ပါအတိုင်းပြင်ဆင်ပေးရပါလိမ့်မယ်။

  • ca_key အဆင်သင့်ဖြစ်ပြီဆိုတာနဲ့ ca_key.pub public key file ကို server ရဲ့ /etc/ssh/ directory မှာသွားထည့်ပေးပြီး၊ /etc/ssh/sshd_config file ထဲမှာ TrustedUserCAKeys /etc/ssh/ca_key.pub ဆိုတဲ့ဟာနောက်ဆုံးမှာသွားထည့်ပေးလိုက်ပါ။

  • server ရဲ့ /etc/ssh/ directory ကနေ ssh_host_rsa_key.pub ဆိုတဲ့ host public key file ကို CA ရဲ့ ca_key ဆိုတဲ့ private key နဲ့ အောက်မှာပြထားသလိုမျိုး signing လုပ်ပေးဖို့လိုပါလိမ့်မယ်။ ပြီးရင်ထွက်လာတဲ့ cert file ကို /etc/ssh/ အောက်မှာပြန်ထည့်ပြီး HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub ဆိုတဲ့ဟာကို sshd_config မှာထပ်ပေါင်းထည့်ပေးလိုက်ပါ။ sshd_config ထဲမှာ change ထားတဲ့ဟာတွေကို apply လုပ်ဖို့အတွက် systemctl reload sshd ဆိုတဲ့ systemd command နဲ့ ssh server daemon ကို reload လုပ်လိုက်ပါ။

Client-side တွင် setup လုပ်ပုံ

  • အရင်ဆုံးအနေနဲ့ client ရဲ့ /etc/ssh/ssh_known_hosts file ထဲမှာ ca_key.pub မှာပါတဲ့ content နဲ့အောက်မှာပြထားတဲ့အတိုင်း ပေါင်းထည့်လိုက်ပါ။

  • Client ဘက်မှာလည်းလိုအပ်တဲ့ SSH key pair ကို generate လုပ်ပြီး ရလာတဲ့ public key ကို CA ရဲ့ private key နဲ့ အောက်မှာပြထားသလို signing လုပ်ပေးရပါလိမ့်မယ်။ Signing လုပ်ပြီးလိုရလာတဲ့ cert file ကိုတော့ client ဘက်မှာ ubuntu ဆိုတဲ့ user ရဲ့ .ssh/ directory အောက်မှာပြန်ထည့်ပေးရပါ့မယ်။

  • အခုဆိုရင်တော့ client ကနေ server ထဲကို SSH နဲ့ certificate based authentication လုပ်ဖို့အတွက် အဆင်သင့်ဖြစ်ပါပြီ။ စမ်းကြည့်လိုက်ရအောင်။

အထက်မှာမြင်ရတဲ့အတိုင်းပဲ client machine ကနေ remote server ထဲကို SSH certificate based authentication နဲ့ အောင်မြင်စွာဝင်လိုက်နိုင်ပါပြီ။ ဟုတ်ပြီ... နောက်တဆင့်အနေနဲ့ ပိုပြီး စိတ်ဝင်စားဖို့ကောင်းသွားအောင် နောက်ထပ် server တခုကိုအခုလက်ရှိ lab ထဲမှာထည့်တဲ့ လုပ်ငန်းစဉ်ကိုလေ့လာကြည့်ရအောင်။

Server တခုထပ်ပေါင်းထည့်ခြင်း လုပ်ငန်းစဉ်

  • နောက်ထပ်ပေါင်းထည့်မယ့် server ကိုတော့ server1 လို့ပဲအလွယ်ခေါ်လိုက်ရအောင်။ LXC container တခုကိုအောက်မှာ ဖော်ပြထားတဲ့အတိုင်း အရင်ဖန်တီးပေးလိုက်ပါ။

  • အရှေ့မှာလုပ်ဆောင်ခဲ့တဲ့ server-side ဘက်က setup ကိုခပ်သွပ်သွပ်လေးနောက်တခါလုပ်လိုက်ရအောင်ဗျ။ ဘယ်လိုမျိုးလုပ်မလဲဆိုတာကို အောက်မှာကြည့်လိုက်ရအောင်။

Server-side မှာလုပ်စရာတွေလုပ်ပြီးတာနဲ့ ရှိပြီးသား client ကနေ ဘာမှထွေထွေထူးထူးလုပ်စရာ မလိုပဲနဲ့ ဒီအတိုင်း SSH နဲ့ဝင်ရောက်နိုင်တာကိုတွေ့ရမှာပါ။ စာရေးသူတို့ အနေနဲ့ client အသစ်တွေထပ်ထည့်ချင်ရင်လည်း client-side မှာလုပ်တဲ့ အဆင့်တွေကိုလုပ်လိုက်ရုံနဲ့ SSH ကိုကောင်းမွန်လုံခြုံစွာ စတင်အသုံးချနိုင်ပါတယ်။

Key based authentication ကို setup လုပ်တာထပ်စာရင်၊ certificate based authentication ကို setup လုပ်ရတာ အဆင့်တွေအများကြီးနဲ့ ရှုပ်ထွေးတယ်လို့ဆိုနိုင်ပေမယ့်လည်း သူ့ရဲ့ workflow ထဲမှာကိုက certificate authority (CA) ကိုအသုံးချပြီးတော့ cyber-security မှာလူသိများ CIA (Confidentiality, Integrity and Availability) model ကိုအသုံးချထားပါတယ်။ ဒါကြောင့်လည်း key based authentication မှာလိုမျိုး TOFU အတွက် တကူးတက manually verify လုပ်စရာမလိုပါ။ Scalability အတွက်လည်း လွန်စွာလွယ်ကူတာကြောင့် လုပ်ငန်းခွင်တွေမှာ အတော်လေးကိုအသုံးတည့်နိုင်ပါတယ်။ အားလုံးအတွက်လည်း ဒီ article ဟာအလွယ်တကူ နားလည်နိုင်ပြီး အသုံးတည့်မယ်လို့ မျှော်လင့်ပါတယ်။

Previousအခြေခံ SSH workflow များNextနေ့စဉ်သုံး စိတ်ကြိုက် Application/Software လေးများ

Last updated

Was this helpful?