SSH ချိတ်ဆက်မှု ပြဿနာဖြေရှင်းနည်း
Ubuntu VPS သို့ SSH မချိတ်နိုင်လျှင် error message အလိုက် စစ်ရမည့်လမ်းကို ရွေးပါ။ အလုပ်လုပ်နေသောဝင်ရောက်ခွင့်ကို ထိန်းထားပြီး network၊ service၊ authentication နှင့် host identity ပြဿနာများကို သီးခြားစစ်ပါ။
VPSuntu · ပြင်ဆင်ရက် · ဖတ်ရန် 7 မိနစ်ခန့်
စာမျက်နှာအကြောင်းအရာ
Error တစ်ခုကို မှတ်ပြီး လက်ရှိ access ကို ထိန်းပါ
အလုပ်လုပ်နေသော SSH session ကို မပိတ်ဘဲ provider recovery console ကို ရှာထားပါ။ Client commands သည် မိမိ Linux/macOS/WSL ကွန်ပျူတာတွင်၊ server commands သည် ရှိပြီးသား access သို့မဟုတ် authenticated console ထဲတွင် ရိုက်ရမည်။ Server command ကို local terminal တွင် မရိုက်ပါနှင့်။
Documentation address 203.0.113.10၊ ubuntu၊ port 22 နှင့် key path ကို မိမိတကယ့်တန်ဖိုးများဖြင့် အစားထိုးပါ။ Evaluated client settings ကို အရင်ပြပြီး fresh connection တစ်ကြိမ် စမ်းပါ။
ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Hostname၊ user၊ port၊ identityfile နှင့် proxy settings ကို စစ်ပါ။ ဒုတိယ command သည် ဒီစမ်းသပ်မှုအတွက် connection sharing ပိတ်သည်။ အချိန်နှင့် နောက်ဆုံး error ကို မှတ်ပါ။ Host key prompt အသစ်ကို အောက်မှ identity စစ်နည်းဖြင့် အတည်ပြုပါ။ Debug output မမျှဝေမီ usernames၊ addresses၊ paths ကို ဖုံးပါ။ Private key ကို မမျှဝေပါနှင့်။
Error နှင့်ကိုက်သော လမ်းကြောင်းကို ရွေးပါ
မျက်နှာပြင်ငယ်တွင် ကော်လံအားလုံးကြည့်ရန် ဇယားကို ဘေးတိုက်ရွှေ့ပါ။
| Message သို့မဟုတ် အဆင့် | အဓိပ္ပာယ် | နောက်စစ်ရန် |
|---|---|---|
| Connection timed out မချိတ်ရသေးမီ | TCP မချိတ်နိုင် | Address၊ route၊ firewall၊ provider state |
| Connection refused | ထို IP/port မှ တက်ကြွစွာငြင်းပယ် | Port၊ listener၊ rejection rules |
| Permission denied (publickey) | Authentication အဆင့်ရောက်ပြီး credentials မအောင်မြင် | Username၊ offered key၊ server policy |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Host identity သည် သိမ်းထားသည်နှင့် မတူ | ဆက်မချိတ်မီ trusted host key စစ်ရန် |
ဤအရာများက အကြောင်းရင်းကို ကျဉ်းစေသော်လည်း တစ်ခုတည်းကို သက်သေမပြပါ။ Timeout မတိုင်မီ Connection established ဟုပြပြီးသားဆိုလျှင် packet အားလုံးပိတ်သည်ဟု မယူဆဘဲ SSH handshake နှင့် server logs ကို စစ်ပါ။
Timeout ဖြစ်လျှင် network လမ်းကြောင်းကို လိုက်စစ်ပါ
ssh -v destination နှင့် provider panel ရှိ လက်ရှိ IP ကို တိုက်ပါ။ Hostname တွင် DNS ဟောင်း သို့မဟုတ် အခြား IPv6 destination ကြောင့် မှားနိုင်သည်။ Public IP၊ VPN သို့မဟုတ် jump host လိုသလား စစ်ပါ။
Instance running နှင့် public route ရှိကြောင်း အတည်ပြုပါ။ Provider firewall တွင် SSH destination port အမှန်နှင့် လက်ရှိ public source IP ကို စစ်ပါ။ အိမ်အင်တာနက် IP ပြောင်းသော်လည်း /32 rule ဟောင်းကျန်နိုင်သည်။ Console မှ guest firewall ကိုပါ ကြည့်ပါ။
Oracle တွင် security lists၊ NSGs၊ routes နှင့် guest firewall အားလုံး သက်ရောက်သည်။ Image rules ကို ထိန်းထားပါ။ UFW တပ်ခြင်း သို့မဟုတ် iptables flush လုပ်ခြင်းသည် diagnostic step မဟုတ်ပါ။ Oracle network ပြင်ဆင်နည်း ကို ဖတ်ပါ။ Ping မရရုံဖြင့် SSH မရဟု မဆုံးဖြတ်နိုင်ပါ။
Connection refused ဖြစ်လျှင် listener ကို စစ်ပါ
Refusal တစ်ခုက ရည်ရွယ်ထားသော VPS အမှန်ဖြစ်ကြောင်း အတည်မပြုပါ။ Identity/port ကို စစ်ပြီး ရှိပြီးသား access သို့မဟုတ် recovery console မှ server ပေါ်တွင် read-only စစ်ဆေးချက်များ ရိုက်ပါ။
systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pagerရည်ရွယ်ထားသော port/address တွင် listener ရှိသလား ကြည့်ပြီး attempt အချိန်နှင့် log ကို တိုက်ပါ။ Ubuntu တွင် socket activation သုံးနိုင်သဖြင့် ssh.socket နားထောင်နေစဉ် ssh.service inactive ဖြစ်ရုံဖြင့် SSH မရဟု မဆိုနိုင်ပါ။
sshd -t သည် daemon မစဘဲ configuration နှင့် host key validity ကို စစ်သည်။ Output မရှိဘဲအောင်မြင်ခြင်းက network ရောက်ကြောင်း မပြပါ။ Error ရှိလျှင် reload မလုပ်မီ ထိုဖိုင်/setting ကို ရှာပါ။ အကြောင်းမသိဘဲ restart မလုပ်ပါနှင့်။
Public key ငြင်းပယ်လျှင် account နှင့် offered key ကို စစ်ပါ
ခန့်မှန်းထားသော username အစား provider မူလ account သို့မဟုတ် မိမိဖန်တီးထားသော administrator ကို သုံးပါ။ Client debug တွင် ဘယ် fingerprint ကို ပို့သလဲ ကြည့်ပါ။ Agent မှ မသက်ဆိုင်သော key များ လျှော့ရန် local တွင် ဒီလိုပြန်စမ်းပါ။
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Configured IdentityFile entries များ သက်ရောက်နိုင်ဆဲဖြစ်သဖြင့် ssh -G ကို ကြည့်ပါ။ Key မဖတ်ရခြင်း သို့မဟုတ် private-key permission ကျယ်လွန်းခြင်းဆိုလျှင် server မပြင်မီ local file access ကို ပြင်ပါ။
Server တွင် target account နှင့် authorized public keys ကို စစ်ပါ။ ဥပမာ home သည် /home/ubuntu ဖြစ်သည်။ getent ပြသော တကယ့် home ဖြင့် အစားထိုးပါ။
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysAuthorized fingerprints နှင့် offered fingerprint ကို တိုက်ပါ။ Journal မှ ownership၊ permission နှင့် account policy ကို စစ်ပါ။ Default path မသုံးလျှင် AuthorizedKeysFile၊ included snippets နှင့် Match rules ကို ကြည့်ပါ။ Provider-managed key service ကြောင့် နည်းလမ်းမတူနိုင်ပါ။ ရှိပြီးသား keys ကို ထိန်းပြီး အကြောင်းရင်းဖုံးရန် StrictModes မပိတ်ပါနှင့်၊ password login မဖွင့်ပါနှင့်။
Host identity ပြောင်းလျှင် အရင်အတည်ပြုပါ
Rebuild သို့မဟုတ် IP ပြန်ခွဲပေးမှုကြောင့် host key ပြောင်းနိုင်သော်လည်း မမျှော်လင့်သောအပြောင်းအလဲသည် endpoint မှားခြင်း သို့မဟုတ် ကြားဝင်မှု ဖြစ်နိုင်သည်။ Authenticated provider panel တွင် instance ID နှင့် စီစဉ်ထားသော rebuild ကို အတည်ပြုပါ။
Trusted guest console မှ client ပြသော algorithm နှင့်ကိုက်သော public host key ကို ကြည့်ပါ။ Ed25519 အတွက် —
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256SHA256 ကို client warning နှင့် တိုက်ပါ။ ၎င်းသည် server key ဖြစ်ပြီး login key သို့မဟုတ် console gateway key မဟုတ်ပါ။ အတည်ပြုပြီးပြောင်းထားသော key အတွက် သက်ဆိုင်ရာ host entry ကို update လုပ်ရန် လိုနိုင်သည်။ ဖိုင် backup အရင်ထားပြီး အခြား entries ထိန်းပါ။ known_hosts အားလုံး မဖျက်ပါနှင့်၊ checking ကို မကျော်ပါနှင့်။ Identity မရှင်းလျှင် connection ရပ်ပြီး စုံစမ်းပါ။
ပြင်ထားသောအချက်ကို session အသစ်တွင် စမ်းပါ
တွေ့ရှိသော address၊ user၊ key၊ ကျဉ်းသော network rule သို့မဟုတ် config error ကိုသာ ပြင်ပါ။ Server ပြင်စဉ် သီးခြား access တစ်ခု ထိန်းပြီး SSH config ကို မအသုံးချမီ စစ်ပါ။ Port အသစ်တွင် service restart တင်မက socket activation settings ပါ သက်ရောက်နိုင်သည်။
Connection sharing ပိတ်ထားကာ မူလ attempt ကို ထပ်စမ်းပါ။ Account မှန်သို့ fresh login ရပြီး လိုအပ်သော sudo အလုပ်လုပ်ကြောင်း စစ်ပါ။ Session ဟောင်းမပြတ်ခြင်းသည် ဒီစစ်ဆေးချက်မဟုတ်ပါ။ Error နှင့် ပြင်ထားသည့်အချက်ကို မှတ်ပြီး deployment လမ်းညွှန် ကို ဆက်ပါ။
အမေးအဖြေ
SSH ပြင်ရန် Ubuntu ပြန်တင်သင့်သလား။
အရင်အကြောင်းရင်းရှာပါ။ IP၊ username သို့မဟုတ် key မှားခြင်းအတွက် OS ပြန်တင်ရန်မလိုဘဲ reinstall က data ဖျက်နိုင်သည်။ Access မကျန်လျှင် provider recovery ကို သုံးပါ။
Console ရလျှင် SSH လည်း ရသင့်သလား။
မဟုတ်ပါ။ Console နှင့် public SSH လမ်းကြောင်းမတူပါ။ Guest listener၊ account authentication နှင့် network rules က SSH ကို ခွင့်ပြုရမည်။