အခြေခံ SSH workflow များ
Linux ကိုစပြီး အသုံးပြုတော့ အရင်ဆုံးလေ့လာရတာက ssh နဲ့ remote server တခုထဲကို ဘယ်လိုမျိုးဝင်ရသလဲဆိုတာပါပဲ။ ပုံမှန်အားဖြင့် Windows admin တစ်ယောက်အနေနဲ့ ssh အကြောင်းကို သိစရာမလိုပါ။ Linux နဲ့ BSD လိုမျိုး Unix-like operating system တွေမှာတော့ မသိမဖြစ်၊ မရှိမဖြစ်လိုအပ်တဲ့ tool တခုပါ။ အလုပ်မှာပဲဖြစ်ဖြစ်၊ အိမ်မှာပဲဖြစ်ဖြစ် ကိုယ် manage လုပ်ရတဲ့ environments တွေကို ssh နဲ့ပဲ remote access လုပ်ရပါတယ်။ သို့သော်... စာရေးသူအတွက်တော့ ssh နဲ့ပတ်သတ်ပြီးတော့ မသိတာလေးတွေ အခုအချိန်ထိရှိနေတတ်ပါတယ်။ ကိုယ်သုံးနေကြ workflow မဟုတ်တဲ့အခါမှာ ssh နဲ့ပတ်သတ်လို့ အသစ်အသစ်တွေကို မကြာခဏထပ်မံလေ့လာ ဖြစ်တဲ့အခါတွေရှိပါတယ်။ ကိုယ်ဘယ်လိုမျိုး အသုံးပြုသလဲပေါ်မူတည်ပြီးတော့ အသုံးတည့်ပုံတွေ မတူတာကိုလည်း လုပ်ငန်းခွင်မှာ လုပ်ဖော်ကိုင်ဖက်တွေနဲ့ စကားစပ်တဲ့အခါမှ သိရှိရပြန်ပါတယ်။ ဒီတော့ စာရေးသူ အနေနဲ့ ssh ကိုကိုယ်အနေနဲ့ဆို ဘယ်လိုမျိုးသုံးသလဲဆိုတာကို မှတ်တမ်းတင်ထားရင်ကောင်းမှလို့ တွေးမိပြီး ဒီ blog post ကိုပြန်ရေးဖြစ်ပါတယ်။
SSH authentication အမျိုးအစားများ
SSH authentication အကြောင်းကို မရှင်းခင်၊ Linux server ပေါ်မှာ login ဝင်ဖို့အတွက် user account တွေကို အောက်မှာပြထားတဲ့သလိုမျိုး အရင်ဆုံးဖန်တီးဖို့လိုပါလိမ့်မယ်။ သက်ဆိုင်ရာ user account ကို ဖန်တီးပြီးရင်နောက်တဆင့်မှာ authentication လုပ်တဲ့ ပုံစံကို ဆက်ရှင်းပါ့မယ်။
Password authentication
Password authentication ဆိုတာကတော့ ရှင်းပါတယ်။ အထက်မှာပြထားတဲ့အတိုင်း user account ကို ဖန်တီးပြီးတာနဲ့ အဲ့ဒီ account ကိုသုံးပြီး ssh နဲ့ remote access လုပ်လို့ရပါပြီ။ အသုံးပြုရမယ့် command က ssh tyla@ssh1
သို့မဟုတ် ssh tyla@192.168.56.11
ဆိုပြီးဝင်လိုက်ရုံပါပဲ။ ပြထားတဲ့ command ကိုသုံးမယ်ဆိုရင် DNS server၊ ဒါမှမဟုတ် /etc/hosts
ကနေ name resolution လုပ်ဖို့လိုပါလိမ့်မယ်။ ဒီနည်းက remote server ကို ssh နဲ့ဝင်ဖို့ အဆင်ပြေပေမယ့် လုံခြုံရေးအတွက်မကောင်းပါဘူး။ Password ဆိုတာကအခြားသူတယောက်ရသွားတာနဲ့ ပြီးသွားပါပြီ။ ဒါ့အပြင် key logger တွေသုံးပြီး password ကိုရနိုင်သလို၊ brute force နည်းနဲ့လည်း မှန်းဆလို့ရနိုင်ပြန်ပါတယ်။ Password တခုတည်းနဲ့ ဘယ် system ကိုမှ လုံခြုံအောင်လုပ်လို့မရပါ။ ဒါကြောင့်လည်း Linux admin တွေဟာ တတ်နိုင်သလောက် password authentication ကမသုံးပဲနဲ့၊ နောက်တနည်း ဖြစ်တဲ့ public/private asymmetric key authentication ကိုသုံးကြတာများပါတယ်။
Public Key authentication
အထက်မှက password authentication ရဲ့ မလုံခြုံပုံကိုရှင်းပြပြီးနောက်၊ ssh မှာစိတ်ဝင်စားဖို့ကောင်းတဲ့ cryptographic key authentication အကြောင်းကို ဆက်လက်ရှင်းလိုပါတယ်။ Key authentication ကိုနေရာတော်တော်များမှာ အသုံးကြပါတယ်။ စာရေးသူ နေ့စဉ်အလုပ်ခွင်မှရော၊ အိမ်မှာပါ ဒီနည်းနဲ့ပဲ ssh ကို setup လုပ်ပါတယ်။ လုပ်ရတဲ့ လုပ်ငန်းစဉ်ကအောက်ပါအတိုင်းပဲဖြစ်ပါတယ်။
ပထမဆုံးအနေနဲ့ ကိုယ့်ရဲ့ local computer မှာ ssh key pair အရင် generate လုပ်ရပါ့မယ်။
အထက်မှာပြထားသလိုမျိုး ssh public/private key pair တခုကို /home/vagrant/.ssh/ မှာသွားပြီး generate လုပ်ပေးပါတယ်။ ကိုယ့်ရဲ့ private key ကို passphrase ထည့်ပြီး လုံခြုံရေးပိုကောင်းအောင်လုပ်ရနိုင်ပါသေးတယ်။ နောက်အဆင့်အနေနဲ့ အဲ့ဒီထဲက public key ကို destination host သို့မဟုတ် server ရဲ့ ~/.ssh/authorized_keys ထဲမှာသွားပြီး ထည့်ပေးရပါလိမ့်မယ်။ .pub နဲ့ဆုံးတဲ့ file က public key ဖြစ်ပါတယ်။ နောက်တခုက private key ဖြစ်ပြီး၊ ကိုယ်ရဲ့ local machine ပေါ်မှာပဲ လုံခြုံအောင်သိမ်းထားရမှာပါ။
Public key ကို remote machine ပေါ်မှာထည့်ဖို့ အတွက်က ကိုယ့်မှာအရင်ဆုံး password နဲ့ ဝင်လို့ရဖို့တော့လိုပါလိမ့်မယ်။ စာရေးသူတို့ လုပ်ငန်းခွင်မှာတော့ developer တွေရဲ့ public key တွေကို machine ကို build လုပ်ကတည်း ကြိုပြီး cloudinit သို့မဟုတ်၊ အခြားသော နည်းတခုခုနဲ့ automation workflow မှာကြိုပြီးပြင်ဆင်ရပါတယ်။ သို့သော် အခုဒီမှာတော့ normal workflow တခုကိုပဲ သုံးပြသွားပါ့မယ်။ အသုံးမယ့် command က
ssh-copy-id
ဖြစ်ပါတယ်။
အထက်မှာပြထားသလိုမျိုး ssh key authentication ကို setup လုပ်ပြီးသွားရင် remote access အတွက် ssh ကို password ရိုက်ထည့်စရာမလိုတော့ပါဘူး။ တခေါက်လောက် သေချာအောင် စမ်းသပ်ပြီးရင် နောက်တဆင့်ကို ဆက်သွားဖို့အတွက် remote machine ဖြစ်တဲ့ ssh2 ပေါ်မှာ ssh configuration ကိုပြင်ဆင်ပေးရပါ့မယ်။ Key authentication ကပိုပြီးတော့ လုံခြုံတဲ့အတွက် ဒီတခုတည်းကိုပဲအသုံးပြုလို့ရအောင် password authentication ကို disable လုပ်ရပါ့မယ်။ ဘယ်လိုမျိုး configure လုပ်ရသလဲဆိုတာ အောင်မှာတချက်ကြည့်ရအောင်ဗျ။ ပြင်ရမယ့် ssh configuration file နေရာက /etc/ssh/sshd_config ဖြစ်ပါတယ်။ အောက်ဖော်ပြပါအတိုင်း configure လုပ်ပြီးရင်
sudo systemctl restart sshd
ဆိုပြီး sshd daemon ကို restart လုပ်ဖို့လိုပါလိမ့်မယ်။ လုပ်အပ်တာတွေ အကုန်လုံးပြင်ဆင်ပြီးရင် အခြားသော host တခုနေ password နဲ့ ဝင်လို့ရနိုင်၊ မရနိုင်သေးတာကို စမ်းသပ်ဖို့လိုပါတယ်။
အခြားသော authentication နည်းလမ်းများ
အထက်မှာပြောသွားတဲ့ authentication နည်းလမ်းတွေအပြင်၊ ssh နဲ့တွဲပြီးသုံးလို့ရတဲ့ အခြားသောနည်းလမ်းတွေလည်းရှိပါသေးတယ်။ စာရေးသူ ကိုယ်တိုင် ကိုယ့်ရဲ့ workflow မှာအသုံးပြုနေကြမဟုတ်တဲ့အတွက် ဒီ post မှာအကျယ်တဝင့် မရှင်းလိုတော့ပါဘူး။ သို့သော် စိတ်ဝင်စားလို့ရှိရင် ကိုယ်တိုင်လေ့လာလို့ရအောင်လို့ အောက်မှာဖော်ပြပေးသွားပါ့မယ်။
Host-based authentication
GSSAPI (Generic Security Services Application Program Interface) authentication
Keyboard-interactive authentication
Certificate-based authentication
SSH ကို remote access အတွက်အသုံးပြုပုံ
SSH ကိုသုံးပြီးတော့ remote server တခုထဲကို ဝင်ချင်ရင် အခြေခံဖြစ်တဲ့ command ကတော့ ssh <username>@<remote-server-ip-or-hostname>
ဖြစ်ပါတယ်။ Remote server က online ဖြစ်နေပြီး၊ sshd ကိုလည်း run နေတယ်၊ firewall မှာလည်း ssh port 22 ကို ခွင့်ပြုထားတယ်ဆိုရင် အောက်မှာပြထားတဲ့အတိုင်း prompt တခုပေါ်ပါလိမ့်မယ်။ ဒီ ssh client ကနေ အဲ့ဒီ remote server ကို ပထမဆုံးအနေနဲ့ ဝင်တာဖြစ်တဲ့အတွက်လည်း အခုလိုမျိုး prompt ပြတာလည်းဖြစ်ပါတယ်။ ဒီမှာတော့ ssh key authentication ကို setup လုပ်ပြီးသားမို့ yes လို့ ထည့်ပြီးတာနဲ့ remote access ကိုချက်ချင်းဝင်သွားပါတယ်။
အဲ့ဒီ remote server ကိုကိုယ့်အနေနဲ့ သိတာသေချာတယ်ဆိုရင် yes လို့ ပြန်ဖြေပေးလိုက်ရုံပါပဲ။ ဒီလိုဖြေလိုက်ရင်တော့ remote server ရဲ့ public key ကို ကိုယ့်ရဲ့ ~/.ssh/known_hosts file ထဲမှာလာပြီး ပေါင်းထည့်ပေးပါလိမ့်မယ်။ နောက်အခါတွေမှာတော့ ဒီ prompt ကိုတွေ့ရတော့မှာမဟုတ်ပါဘူး။ သို့သော်... အကြောင်းအမျိုးအမျိုးကြောင့် အဲ့ဒီ remote server ရဲ့ key တွေပြောင်းသွားရင် ~/.ssh/known_hosts ထဲက ရှိပြီးသား entry တွေကို အရင်ဆုံးဖျက်ခိုင်းပါလိမ့်မယ်။ ပြီးတော့မှ ပြန်ပြီးပေါင်းထည့်လို့ရပါလိမ့်မယ်။ Fingerprint ပြောင်းသွားတဲ့အခါ အောက်မှာပြထားတဲ့အတိုင်းတွေ့ရမှာဖြစ်ပါတယ်။
ဘာကြောင့် အဲ့ဒီလိုဖြစ်ရသလဲဆိုတာကတော့ အောက်မှာဖော်ပြထားတဲ့ အချက်တွေကြောင့်ဖြစ်နိုင်ပါတယ်။
အရင်ကကိုယ်က ssh ဝင်ထားခဲ့လို့ known_hosts file ထဲမှာ entry ရှိနေပြီးမှ အဲ့ဒီကို reinstall ပြန်လုပ်လိုက်လို့ပဲဖြစ်ဖြစ်၊ server ကို upgrade လုပ်ပြီးတော့ ssh public key ကိုပြန်ပြီးတော့ generate အသစ်ထုတ်ယူလို့လည်းဖြစ်နိုင်ပါတယ်။
ပိုပြီးတော့ ဆိုးတဲ့အနေအထားတခုမှာ man-in-the-middle attack လို့ခေါ်တဲ့ အလယ်က တဦးတယောက်ဝင်ပြီး intercept လုပ်နေလို့လည်း ဖြစ်နိုင်ပါတယ်။
တခါတရံ server migration လုပ်လို့ မတူတဲ့ ssh keys တွေပြောင်းသွားတာလည်းဖြစ်နိုင်ချေရှိပါတယ်။
နောက်တခုက remote server က IP address ပြောင်းသွားပြီး ကိုယ်သုံးတဲ့ hostname ကမတူတဲ့ IP address နောက်တခုကိုသွား access လုပ်လို့လည်း ဖြစ်နိုင်တယ်။
ဒါတွေက ssh မှာ remote access ဝင်တဲ့အခါ ဖြစ်လေ့ဖြစ်ထရှိတဲ့ ပြဿနာအချို့ပါ။ အခြားသောအကြောင်းကြောင်းတွေလည်းဖြစ်နိုင်ချေရှိပါတယ်။ ဒီလို failure မျိုးနဲ့ကြုံတဲ့အခါ ဖြေရှင်းဖို့ရာ နည်းလမ်းနှစ်ခုရှိပါတယ်။ ပထမတခုက သူ့ error message မှာပြထားတဲ့ အတိုင်း ssh-keygen -f "/home/tyla/.ssh/known_hosts" -R "192.168.56.11"
ဆိုတဲ့ ssh-keygen command ကိုအသုံးပြုပြီးတော့ လက်ရှိ entry ကိုအရင်ဆုံးဖယ်ရှားဖြစ်လို့ရပါတယ်။ နောက်နည်းလမ်းတခုကတော့ ကိုယ့် home directory ထဲမှာ vi ~/.ssh/known_hosts
ဆိုပြီးတော့ ဝင်ကြည့် စစ်ဆေးကာဖယ်ရှားလို့လည်းဖြစ်နိုင်ပါတယ်။
StrictHostKeyChecking no ကို ~/.ssh/config ထဲမှာအသုံးပြုပုံ
အထက်မှာဖော်ပြပါ အဆင့်တွေက ssh ကို admin တယောက်အနေနဲ့ remote server ထဲကဝင်ပြီး manage လုပ်တဲ့အခါမှာတဲ့ အခြေခံအကျဆုံး အဆင့်ဖြစ်ပါတယ်။ ပုံမှန်အားဖြင့် အဲ့ဒီ workflow က human login အတွက် အဆင်ပြေနိုင်ပေမယ့်၊ machine login လို့ခေါ်တဲ့ server တလုံးကနေ နောက်server တလုံးဆီကို automation အတွက်ဝင်တဲ့အခါမှာတော့ automation workflow ကလိုသလောက် fully automated မဖြစ်နိုင်ပါ။ Command line အနေနဲ့ အသုံးပြုမယ်ဆိုရင် ssh -o StrictHostKeyChecking=no vagrant@192.168.56.11
လို့ရိုက်ထည့်ပြီးတော့ သူ့ warning မတက်လာအောင်လုပ်လို့ရပါတယ်။
ဒီလိုမှမဟုတ်ဘူး automation မှာ script တွေနဲ့ သုံးနိုင်အောင်လို့ configuration file ထဲမှာတောက်လျှောက်ထည့်ထားချင်တယ်ဆိုရင် အောက်မှာပြထားတဲ့အတိုင်း ~/.ssh/config
ဆိုတဲ့ file ထဲမှာရိုက်ထည့်ရပါလိမ့်မယ်။
ဒီနေရာမှာ သတိပြုရမှာက အဲ့ဒီ remote host တွေကို လုံးဝအကြွင်းမဲ့ အယုံပေးပြီး automated workflow မှာထည့်သွင်းအသုံးပြုထားတဲ့အတွက် လုံခြုံရေး (security) မှာတော့ ဘေးထွက်ဆိုးကျိုးတွေ ရှိနိုင်ပါတယ်။ လုံခြုံရေးနဲ့ ချောမွေ့အဆင်ပြေမူဆိုတဲ့ နှစ်ခုကိုအမြဲတန်း ထိန်းညှိရတာက IT system တွေမှာပုံမှန်ပါပဲ။
ssh-keyscan နဲ့ remote public key ကို fingerprint လုပ်ပုံ
နောက်တနည်းကတော့ initial setup မှာအဆင့်လေးတွေ နည်းနည်းပိုပေမယ့်လည်း သေချာစိစစ်ပြီးတော့မှ ကိုယ့်ရဲ့ automated workflow ကို စမယ်ဆိုလည်းဖြစ်နိုင်ပါတယ်။ Linux ရဲ့ ssh client တွေမှာပါတဲ့ ssh-keyscan ကိုအသုံးပြုနိုင်ပါတယ်။ ပထမဆုံး အနေနဲ့ remote host တွေကို အောက်မှာပြထားသလို key scan အရင်ဆုံးလုပ်လိုက်ပါ။
အပေါ်က output မှာပြထားတဲ့ ssh public key တွေကိုမှတ်ထားလိုက်ပြီး၊ remote host ပေါ်က key တွေနဲ့ အောက်ပါအတိုင်း တိုက်စစ်ကြည့်ရင် တူလား မတူဘူးလားဆိုတာကိုတွေ့ရပါလိမ့်မယ်။ SSH နဲ့ remote access မဝင်ခင် စစ်တာဖြစ်တာကြောင့် console ကနေဖြစ်ဖြစ်၊ out-of-band (OOB) access နည်းတခုနဲ့ ဝင်ပြီးမှ စစ်တယ်လို့ ယူဆနိုင်ပါတယ်။
ဒီ lab မှာတော့ Bento ရဲ့ vagrant box တွေကိုသုံးထားတဲ့အတွက် ed25519 public key တွေအားလုံး တူနေတာကိုတွေ့မြင်ရပါလိမ့်မယ်။ ကိုယ့်ရဲ့ lab environment setup လုပ်တဲ့ပေါ်မူတည်ပြီး key တွေဟာလည်း ကွဲပြားနိုင်တာကို သတိပြုရပါ့မယ်။ ဟုတ်ပြီ... အခုစစ်ဆေးကြည့်တဲ့ အခါမှာ အားလုံးတူပြီး အဆင်ပြေတယ်ဆိုရင် နောက်အဆင့်အနေနဲ့ အဲ့ဒီ key တွေကို အောက်ပါအတိုင်း fingerprint လုပ်ထားနိုင်ပါပြီ။ -t ဆိုတာ key အမျိုးအစားကိုပြောတာဖြစ်ပြီ၊ -H ဆိုတာကတော့ hash လုပ်မယ်ပြောတာပါ။
အခုဆိုရင် အထက်မှာမြင်တွေ့ရတဲ့အတိုင်း authenticity of host ဆိုတာ မတက်လာတော့ပါဘူး။ ဒီ host နှစ်ခုမှာ ssh key authentication ကို setup မလုပ်ရသေးတဲ့ အတွက် password နဲ့ပဲ remote access ဝင်လို့ရပါတယ်။
SSH-Agent ကိုအသုံးပြုပုံ
Local ssh-agent
စာရေးသူ အနေနဲ့ SSH-Agent ကို အသုံးပြုတဲ့ workflow နှစ်ခုရှိပါတယ်။ ပထမတခု ssh private/public key pair ကို passphrase ထည့်တဲ့အခါမှာ ssh က private key ကို access လုပ်ဖို့လိုတိုင်း အဲ့ဒီ passphrase ရိုက်ထည့်ပြီးမှ ကိုယ့် authentication ကအောင်မြင်ပါတယ်။ တနည်းအားဖြင့် ကိုယ့်ရဲ့ private key ကိုပိုပြီးလုံခြုံအောင်လို့ နောက်အလွှာတခုထပ်ထည့်လိုက်သလိုဖြစ်သွားပါတယ်။ လုံခြုံရေးအတွက်ကောင်းသွားပေမယ့် အဆင်တော့သိပ်မပြေတော့ပါဘူး။ ဒီတော့ဖြေတဲ့နည်း ssh-agent ပါ။ ကိုယ်သုံးမယ့် terminal session တခုမှာ passphrase ကိုတခါရိုက်ထည့်ပြီးသွားတာနဲ့ နောက်တခေါက်ထပ်ရိုက်ထည့်စရာမလိုတော့ပါ။ ဘယ်လိုမျိုး အသုံးချနိုင်သလဲဆိုတာကို အောက်မှဖော်ပြပေးထားပါတယ်။
မြင်တဲ့အတိုင်းပဲ လက်ရှိ session တခုမှာ passphrase ရိုက်ထည့်ပြီး ကိုယ့် private key ကို ssh-agent ကိုပေးထားလိုက်ရုံနဲ့ passphrase ကိုတောက်လောက် ထပ်မတောင်းတော့ပါဘူး။ ဒီမှာသတိထားရမှာက လက်ရှိ terminal session ကို အဆုံးသတ်လိုက်ပြီးသွားတာနဲ့ အဲဒီမှာ load လုပ်ထားတဲ့ private key ကိုလည်း discard လုပ်လိုက်တဲ့အတွက်၊ နောက် session အသစ်မှာ passphrase ပြန်ရိုက်ပြီး private key ကို load ပြန်လုပ်ရပါလိမ့်မယ်။
SSH-Agent Forwarding
ဒုတိယအသုံးပြုတဲ့ပုံစံကတော့ automation အတွက် ssh-agent ကိုအသုံးချပုံတခုဖြစ်ပါတယ်။ ဆိုပါတော့... ကိုယ့် private key ကို ကိုယ့်ရဲ့ local machine မှာပဲထားချင်တယ်၊ အဆင့်ဆင့်ခုန်တဲ့ နေရာတိုင်းမှာ private key တွေကိုလိုက်မထားချင်ဘူးဆိုပါတော့။ အကြောင်းကနှစ်ခုရှိပါတယ်၊ ပထမတခုက ssh ရဲ့ private key ကို ကိုယ့် local machine မှာ generate လုပ်ထားရင်၊ အဲ့ဒီ key ဟာ local machine ကနေတဆင့် copy လုပ်ပြီး အခြား machine တခုရဲ့ ~/.ssh/ မှာထည့်သုံးရင်၊ asymmetric key authentication ရဲ့ rule ကိုချိုးဖောက်သလိုဖြစ်နေပါတယ်။ စာရေးသူရဲ့ လုပ်ငန်းခွင်မှာ နေ့စဉ်နဲ့အမျှ ssh ကိုအသုံးပြုတဲ့အခါ ssh ကိုအသုံးပြုပြီး အဆင့်ဆင့်ခုန်ရပါတယ်။
ကိုယ့် local machine ကနေ deployment server ပေါ်ကို ssh နဲ့ remote access ဝင်ရပါတယ်။
ပြီးရင် အဲ့ဒီ deployment server ကနေ ssh ကိုအသုံးပြုပြီး အခြားသော target machines တွေကို ဖန်းတီးရပါတယ်၊ configure လုပ်ရပါတယ်။
လိုအပ်ရင် အဲ့ဒီ target machine တလုံးပေါ်ကနေ၊ အခြား target machine တခုပေါ်ကိုလည်း ssh နဲ့ ဝင်ရပြန်ပါတယ်။
ဒီတော့ စာရေးသူအတွက် ssh-agent forwarding ကိုအသုံးမပြုဘူး ဆိုရင် ကိုယ့်ရဲ့ ssh private key ကို တခါခုန်တိုင်း အဲ့ဒီ source machine ပေါ်ကို copy ထည့်ရင်ထည့်၊ ဒါမှမဟုတ်ရင်တော့ ssh key pair အသစ်တခုကို တခါခုန်တိုင်း အသစ် generate လုပ်ရမှာဖြစ်ပါတယ်။ ပြဿနာက အဲ့ဒီ key တွေအားလုံးကို manage လုပ်ဖို့အတွက် တော်တော်လေးခက်ပါတယ်။ နောက်တခုက ကိုယ့် private key ကနေရာတကာ ပွစာကြဲလို့နေပါတယ်။ စာရေးသူအတွက်တော့ ဘယ်လိုမှ ကြည့်မကောင်းတဲ့ မြင်ကွင်းတခုပါ။ ဒီမှာ ssh-agent ကိုအသုံးပြုပြီး အဲ့ဒီပြဿနာကို ဘယ်လိုမျိုး ဖြေရှင်းသလဲဆိုတာကြည့်လိုက်ရအောင်။
အထက်မှပြထားတဲ့ အတိုင်း ssh-agent forwarding လုပ်ထားလိုက်ပြီဆိုရင် remote machine ပေါ်မှာ ssh authentication socket တခုကို အလိုအလျှောက် ဖန်တီးပေးလိုက်ပါတယ်။ Socket ကိုစူးစမ်းချင်ရင် echo $SSH_AUTH_SOCK
လို့ရိုက်ထည့်လိုက်ရုံပါပဲ။ ဒီ socket ကိုပဲအသုံးပြီး ကိုယ့် public key နဲ့ setup လုပ်ထားတဲ့ အခြားသော remote hosts တွေပေါ်ကို နောက်တဆင့်ထပ်ပြီးခုန်လို့ရပါတယ်။ အဲ့ဒီ -A flag ကိုမပါပဲ အလွယ်တကူသုံးချင်ရင် ~/.ssh/config မှာအောက်ကအတိုင်းသွားထည့်ထားလိုက်ရုံပါပဲ။
ကောင်းပြီ ကိုယ့် private key နေရာတကာမှာ မရှိတော့ဘူးဆိုတော့ လုံခြုံပြီလို့ တွေးကောင်းတွေးမိပါလိမ့်မယ်။ မဟုတ်ပါ။ Cybersecurity လောကမှာပြောတာတခုရှိပါတယ်။ လုံခြုံရေးနဲ့ပတ်သတ်လာရင်၊ ပြီးပြည့်စုံအောင်လုံခြုံတာနဲ့ လုံးဝမလုံခြုံဘူးဆိုတဲ့ အစွန်းနှစ်ဘက်မရှိဘူးတဲ့။ ကိုယ်သုံးတဲ့ security model နဲ့ policy တွေကိုပေါ်မှပဲမူတည်တယ်လို့ဆိုပါတယ်။ အခုလည်း ဒီလိုပါပဲ အထက်မှာရှင်းပြခဲ့သလို $SSH_AUTH_SOCK ဟာ ကိုယ်တခါခုန်တိုင်း အဲ့ဒီ remote host ပေါ်တိုင်းမှာ ဖန်တီးတဲ့အတွက်၊ အဲ့ဒီ socket ကို အဲ့ဒီ remote host ပေါ်မှာ sudo privilege ရှိတဲ့အခြားတယောက်က hijack လုပ်ချင်ရင် အလွယ်တကူလုပ်လို့ရပါတယ်။ ဒါဆိုရင်တော့ ကိုယ့်ရဲ့ user account နဲ့ impersonate လုပ်ပြီး ခြေရာလက်ရာဖောက်တာ၊ back-door တွေထားခဲ့နိုင်တာမျိုး လုပ်လို့ရပါတယ်။ ဒီ့အတွက် ssh မှာရှိတဲ့ နောက် solution တခုက ProxyJump ပဲဖြစ်ပါတယ်။
SSH ProxyJump
SSH ProxyJump ကိုအသုံးပြုတဲ့ ပုံစံမျိုးစုံရှိပါတယ်။ ဒီ post မှာတော့ အထက်မှာရှင်းသွားတဲ့ ssh-agent အသုံးပုံမှာပဲ ProxyJump ကိုအစားထိုး သုံးပြချပါတယ်။ အသုံးပြုပုံက အောက်မှာပြထားတဲအတိုင်းပါပဲ။ သုံးရမယ့် command ကတော့ ssh -J 192.168.56.12 192.168.56.13
ဖြစ်ပါတယ်။
အလွယ်တကူသုံးနိုင်အောင်လို့ ~/.ssh/config မှာထည့်သုံးချင်ရင် အောက်မှာပြထားသလို ssh1 host ပေါ်မှာ configure လုပ်ဖို့လိုပါလိမ့်မယ်။
ဒါကတော့ စာရေးသူ နေ့စဉ်အသုံးများတဲ့ ssh workflow တွေပဲဖြစ်ပါတယ်။ SSH မှာသုံးလို့ရတဲ့ အခြားသော workflow တွေလည်းရှိပါသေးတယ်။ ကိုယ်ဘယ်လိုမျိုး ssh ကိုအသုံးချသလဲပေါ်မူတည်ပြီး အသုံးပြုတဲ့ပုံစံလေးတွေတော့ ကွာခြားနိုင်ပါတယ်။ SSH ကိုသုံးပြီး tunnel တွေဖန်တီးပုံကိုလေ့လာချင်ရင် စာရေးသူအရင်က ရေးထားတဲ့ ဒီ post လေးမှာလည်းသွားရောက် လေ့လာနိုင်ပါတယ်။
Last updated