💻
ITmatic101 - MY
  • ITmatic101 - နည်းပညာဆိုင်ရာ Blog
  • ☕Linux/BSD
    • Linux distro-hopper ခရီးကြမ်း
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၁)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၂)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၃)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၄)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၅)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၆)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၇)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၈)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၉)
    • လူသုံးများ ရေပန်းစားသော GNU/Linux Distro များ အပိုင်း (၁၀)
    • Manjaro Linux အကြောင်းတစေ့တစောင်း
    • GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၁)
    • GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၂)
    • GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၃)
    • GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၄)
    • GNU/Linux Desktop Environment များအကြောင်း အပိုင်း (၅)
    • TACACS+ နဲ့ Windows AD ကိုတွဲပြီး အသုံးပြုနည်း – အပိုင်း (၁)
    • TACACS+ နဲ့ Windows AD ကိုတွဲပြီး အသုံးပြုနည်း – အပိုင်း (၂)
    • FreeRADIUS နဲ့ PPPoE Authentication အပိုင်း (၁)
    • FreeRADIUS နဲ့ PPPoE Authentication အပိုင်း (၂)
    • Ubuntu မှာအလုပ်ဖြစ်သော tool နဲ့ application (၁၀) ခုအကြောင်း
    • Docker မိတ်ဆက် အပိုင်း(၁)
    • Docker မိတ်ဆက် အပိုင်း(၂)
    • Docker မိတ်ဆက် အပိုင်း(၃)
    • GNU/Linux ကိုဘာလို့ ပြောင်းသုံးသင့်သလဲ
    • GNU/Linux မှာသုံးတဲ့ CLI ကိုဘယ်လိုခေါ်ကြသလဲ
    • Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၁)
    • Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၂)
    • Linux Kernel အကြောင်း သိကောင်းစရာ အပိုင်း (၃)
    • ပြတိုက်ထဲက SysVinit အကြောင်း
    • Open source သင်ခန်းစာများ အပိုင်း(၁)
    • Open source သင်ခန်းစာများ အပိုင်း(၂)
    • လေထုညစ်ညမ်းစပြုလာတဲ့ Linux ရဲ့ Ecosystem
    • အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၁)
    • အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၂)
    • အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၃)
    • အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၄)
    • အသုံးဝင်သော Linux Certification များအကြောင်း အပိုင်း (၅)
    • Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၁)
    • Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၂)
    • Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၃)
    • Linux မှာသုံးတဲ့ GNU General Public License အကြောင်း အပိုင်း(၄)
    • Open Source ကောက်ကြောင်း – အပိုင်း(၁)
    • Open Source ကောက်ကြောင်း – အပိုင်း( ၂)
    • “မှားတဲ့ဘက်မှာ” – အပိုင်း (၁)
    • “မှားတဲ့ဘက်မှာ” – အပိုင်း (၂)
    • SELinux မိတ်ဆက်
    • Open Source Licenses များအကြောင်း – အပိုင်း (၁)
    • Open Source Licenses များအကြောင်း – အပိုင်း (၂)
    • Keepalived မိတ်ဆက် – အပိုင်း (၁)
    • Keepalived မိတ်ဆက် – အပိုင်း (၂)
    • Linux မှာ package manager တွေကိုဘယ်လိုအသုံးပြုသလဲ
  • 🚀Automation
    • Chef မိတ်ဆက် အပိုင်း(၁)
    • Wireguard ရဲ့ automated workflow
    • အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) – အပိုင်း(၁)
    • အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) – အပိုင်း(၂)
    • အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) - အပိုင်း(၃)
    • အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) - အပိုင်း(၄)
    • ကြုံတွေ့ရသမျှ Network Automation အနုပညာ အပိုင်း(၁)
    • ကြုံတွေ့ရသမျှ Network Automation အနုပညာ အပိုင်း(၂)
    • ကြုံတွေ့ရသမျှ Network Automation အနုပညာ အပိုင်း(၃)
    • Bash နဲ့ Network Configuration Management system တစ်ခုတည်ဆောက်ပုံ – အပိုင်း(၁)
    • Bash နဲ့ Network Configuration Management system တစ်ခုတည်ဆောက်ပုံ – အပိုင်း(၂)
    • FTP/TFTP server ပေါ်မှာ network config တွေကို auto backup လုပ်ပုံ – အပိုင်း (၁)
    • FTP/TFTP server ပေါ်မှာ network config တွေကို auto backup လုပ်ပုံ – အပိုင်း (၂)
    • Kickstart ကိုအသုံးပြုပြီး Custom ISO တွေဖန်တီးပုံ
  • ⚙️Networking
    • အဘယ့်ကြောင့် GNS3
    • ZeroTier မိတ်ဆက်
    • WireGuard အကြောင်းသိကောင်းစရာ
    • Linode VPS မှာကိုယ်ပိုင် Wireguard VPN server တစ်ခုတည်ဆောက်ပုံ
    • အဘယ်ကြောင့် MikroTik
    • VRRP ကို MikroTik မှာ setup လုပ်ပုံ
  • ☁️Virtualisation and Cloud
    • KVM မှာ virtual disk တွေကို ဘယ်လို resize လုပ်လို့ရသလဲ
    • Debian 12 ပေါ်တွင် Proxmox 8 ကိုဘယ်လို integrate လုပ်သလဲ
    • Promox ပေါ်မှာ VM template တွေကို cloud-init သုံးပြီး ဖန်တီးပုံ
    • Custom LXD container templates များကိုဘယ်လို import လုပ်သလဲ
    • Cloud ဆိုသည်မှာ
  • 🍒others
    • Git အကြောင်းသိကောင်းစရာ
    • Home Lab ရှိခြင်း အနုပညာ
    • ကိုယ့်လုံခြုံရေးအတွက် အသုံးပြုသင့်တဲ့ toolkit လေးများ
    • SSH Tunneling အကြောင်းသိကောင်းစရာ
    • အခြေခံ SSH workflow များ
    • SSH Certificate Based Authentication အကြောင်းတစေ့တစောင်း
    • နေ့စဉ်သုံး စိတ်ကြိုက် Application/Software လေးများ
    • Keyboard Size တွေအကြောင်းသိသမျှ
    • သက္ကရာဇ်၂၀၂၀ ခုနှစ်တွင်း နည်းပညာဆိုင်ရာ အမှတ်တရလေးများ
    • သက္ကရာဇ်၂၀၂၁ ခုနှစ်တွင်း နည်းပညာဆိုင်ရာ အမှတ်တရလေးများ
    • Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၁)
    • Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၂)
    • Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၃)
    • Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၄)
    • Storage အကြောင်းတစေ့တစောင်း – အပိုင်း(၅)
    • အင်တာနက်မြန်မာစာ ယူနီကုဒ်ဇော်ဂျီ ပြဿနာ
    • CyanogenMod မိတ်ဆက် အပိုင်း(၁)
    • WikiLeaks ဆိုသည်မှာ အပိုင်း (၁)
    • WikiLeaks ဆိုသည်မှာ အပိုင်း (၂)
    • WikiLeaks ဆိုသည်မှာ အပိုင်း (၃)
  • 💀OffSec
    • ခုတ်မယ် ထစ်မယ် ပါးပါးလှီးမယ် OpenSSL
Powered by GitBook
On this page
  • SSH authentication အမျိုးအစားများ
  • Password authentication
  • Public Key authentication
  • အခြားသော authentication နည်းလမ်းများ
  • SSH ကို remote access အတွက်အသုံးပြုပုံ
  • StrictHostKeyChecking no ကို ~/.ssh/config ထဲမှာအသုံးပြုပုံ
  • ssh-keyscan နဲ့ remote public key ကို fingerprint လုပ်ပုံ
  • SSH-Agent ကိုအသုံးပြုပုံ
  • Local ssh-agent
  • SSH-Agent Forwarding
  • SSH ProxyJump

Was this helpful?

  1. others

အခြေခံ 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 လုပ်တဲ့ ပုံစံကို ဆက်ရှင်းပါ့မယ်။

# simply adding a new user
vagrant@ssh1:~$ sudo useradd -m tyla
vagrant@ssh1:~$ sudo passwd tyla
New password: 
Retype new password: 
passwd: password updated successfully
vagrant@ssh1:~$ sudo usermod -aG sudo tyla

# adding a new user with more options
vagrant@ssh1:~$ sudo useradd -m -c "Tyla Lin" -s /bin/bash -G sudo tyla
vagrant@ssh1:~$ sudo passwd tyla
New password: 
Retype new password: 
passwd: password updated successfully

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 လုပ်ပါတယ်။ လုပ်ရတဲ့ လုပ်ငန်းစဉ်ကအောက်ပါအတိုင်းပဲဖြစ်ပါတယ်။

  1. ပထမဆုံးအနေနဲ့ ကိုယ့်ရဲ့ local computer မှာ ssh key pair အရင် generate လုပ်ရပါ့မယ်။

vagrant@ssh1:~$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/vagrant/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/vagrant/.ssh/id_ed25519
Your public key has been saved in /home/vagrant/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:ovaa09/0cSMMfdPGrnYhlX1Uj0pCdAUVPU4YWtpZaig vagrant@ssh1
The key's randomart image is:
+--[ED25519 256]--+
|         .o o**+o|
|         . .*.+++|
|         E.+.=+.=|
|          .+.. *o|
|      . S . o + =|
|     . .   o o = |
|    o.    . + + o|
|   ..o.  o . +.o.|
|    oo... . .... |
+----[SHA256]-----+
  1. အထက်မှာပြထားသလိုမျိုး 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 ပေါ်မှာပဲ လုံခြုံအောင်သိမ်းထားရမှာပါ။

  2. Public key ကို remote machine ပေါ်မှာထည့်ဖို့ အတွက်က ကိုယ့်မှာအရင်ဆုံး password နဲ့ ဝင်လို့ရဖို့တော့လိုပါလိမ့်မယ်။ စာရေးသူတို့ လုပ်ငန်းခွင်မှာတော့ developer တွေရဲ့ public key တွေကို machine ကို build လုပ်ကတည်း ကြိုပြီး cloudinit သို့မဟုတ်၊ အခြားသော နည်းတခုခုနဲ့ automation workflow မှာကြိုပြီးပြင်ဆင်ရပါတယ်။ သို့သော် အခုဒီမှာတော့ normal workflow တခုကိုပဲ သုံးပြသွားပါ့မယ်။ အသုံးမယ့် command က ssh-copy-id ဖြစ်ပါတယ်။

vagrant@ssh1:~$ ssh-copy-id -i .ssh/id_ed25519.pub vagrant@192.168.56.12
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
vagrant@192.168.56.12's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'vagrant@192.168.56.12'"
and check to make sure that only the key(s) you wanted were added.

vagrant@ssh1:~$ ssh 192.168.56.12
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Sun Jul 21 03:07:28 AM UTC 2024

  System load:  0.0                Processes:             138
  Usage of /:   14.6% of 30.34GB   Users logged in:       0
  Memory usage: 11%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.12


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Wed Jul 17 12:27:40 2024 from 192.168.56.11
vagrant@ssh2:~$ 
  1. အထက်မှာပြထားသလိုမျိုး 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 နဲ့ ဝင်လို့ရနိုင်၊ မရနိုင်သေးတာကို စမ်းသပ်ဖို့လိုပါတယ်။

# Disable password authentication
PasswordAuthentication no

# Disable keyboard-interactive authentication
ChallengeResponseAuthentication no

# Optionally, disable PAM
UsePAM no

# Ensure public key authentication is enabled
PubkeyAuthentication yes

# restart sshd daemon to apply the change
vagrant@ssh2:~$ sudo systemctl restart sshd

အခြားသော 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 ကိုချက်ချင်းဝင်သွားပါတယ်။

$ ssh vagrant@192.168.56.11
The authenticity of host '192.168.56.11 (192.168.56.11)' can't be established.
ED25519 key fingerprint is SHA256:FrgpM50adTncJAsWACDugfF7duPzn9d6RzjZZFHNtLo.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.56.11' (ED25519) to the list of known hosts.
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Mon Jul 15 12:19:47 PM UTC 2024

  System load:  0.1923828125       Processes:             158
  Usage of /:   13.7% of 30.34GB   Users logged in:       0
  Memory usage: 16%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.11


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Mon Jul 15 12:18:45 2024 from 192.168.56.1
vagrant@ssh1:~$ 

အဲ့ဒီ remote server ကိုကိုယ့်အနေနဲ့ သိတာသေချာတယ်ဆိုရင် yes လို့ ပြန်ဖြေပေးလိုက်ရုံပါပဲ။ ဒီလိုဖြေလိုက်ရင်တော့ remote server ရဲ့ public key ကို ကိုယ့်ရဲ့ ~/.ssh/known_hosts file ထဲမှာလာပြီး ပေါင်းထည့်ပေးပါလိမ့်မယ်။ နောက်အခါတွေမှာတော့ ဒီ prompt ကိုတွေ့ရတော့မှာမဟုတ်ပါဘူး။ သို့သော်... အကြောင်းအမျိုးအမျိုးကြောင့် အဲ့ဒီ remote server ရဲ့ key တွေပြောင်းသွားရင် ~/.ssh/known_hosts ထဲက ရှိပြီးသား entry တွေကို အရင်ဆုံးဖျက်ခိုင်းပါလိမ့်မယ်။ ပြီးတော့မှ ပြန်ပြီးပေါင်းထည့်လို့ရပါလိမ့်မယ်။ Fingerprint ပြောင်းသွားတဲ့အခါ အောက်မှာပြထားတဲ့အတိုင်းတွေ့ရမှာဖြစ်ပါတယ်။

$ ssh vagrant@192.168.56.11
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:6D8mBAa5vuFSD6WqI+TbMmMFrRA4gUIDtTNgB29tnX4.
Please contact your system administrator.
Add correct host key in /home/tyla/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/tyla/.ssh/known_hosts:66
  remove with:
  ssh-keygen -f "/home/tyla/.ssh/known_hosts" -R "192.168.56.11"
Host key for 192.168.56.11 has changed and you have requested strict checking.
Host key verification failed.

ဘာကြောင့် အဲ့ဒီလိုဖြစ်ရသလဲဆိုတာကတော့ အောက်မှာဖော်ပြထားတဲ့ အချက်တွေကြောင့်ဖြစ်နိုင်ပါတယ်။

  • အရင်ကကိုယ်က 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 ထဲမှာရိုက်ထည့်ရပါလိမ့်မယ်။

Host ssh1 
	HostName 192.168.56.11
	User vagrant
	StrictHostKeyChecking no 
	UserKnownHostsFile=/dev/null

Host ssh2 
	HostName 192.168.56.12
	User vagrant
	StrictHostKeyChecking no 
	UserKnownHostsFile=/dev/null

Host ssh3 
	HostName 192.168.56.13
	User vagrant
	StrictHostKeyChecking no 
	UserKnownHostsFile=/dev/null

ဒီနေရာမှာ သတိပြုရမှာက အဲ့ဒီ 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 အရင်ဆုံးလုပ်လိုက်ပါ။

# Hostname: ssh1 / IP address: 192.168.56.11
vagrant@ssh1:~$ ssh-keyscan -t ed25519 192.168.56.12 192.168.56.13
# 192.168.56.13:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
192.168.56.13 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv
# 192.168.56.12:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
192.168.56.12 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv

အပေါ်က output မှာပြထားတဲ့ ssh public key တွေကိုမှတ်ထားလိုက်ပြီး၊ remote host ပေါ်က key တွေနဲ့ အောက်ပါအတိုင်း တိုက်စစ်ကြည့်ရင် တူလား မတူဘူးလားဆိုတာကိုတွေ့ရပါလိမ့်မယ်။ SSH နဲ့ remote access မဝင်ခင် စစ်တာဖြစ်တာကြောင့် console ကနေဖြစ်ဖြစ်၊ out-of-band (OOB) access နည်းတခုနဲ့ ဝင်ပြီးမှ စစ်တယ်လို့ ယူဆနိုင်ပါတယ်။

# Hostname: ssh2 / IP address: 192.168.56.12
vagrant@ssh2:~$ cat /etc/ssh/ssh_host_ed25519_key.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv root@vagrant

# Hostname: ssh3 / IP address: 192.168.56.13
vagrant@ssh3:~$ cat /etc/ssh/ssh_host_ed25519_key.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv root@vagrant

ဒီ lab မှာတော့ Bento ရဲ့ vagrant box တွေကိုသုံးထားတဲ့အတွက် ed25519 public key တွေအားလုံး တူနေတာကိုတွေ့မြင်ရပါလိမ့်မယ်။ ကိုယ့်ရဲ့ lab environment setup လုပ်တဲ့ပေါ်မူတည်ပြီး key တွေဟာလည်း ကွဲပြားနိုင်တာကို သတိပြုရပါ့မယ်။ ဟုတ်ပြီ... အခုစစ်ဆေးကြည့်တဲ့ အခါမှာ အားလုံးတူပြီး အဆင်ပြေတယ်ဆိုရင် နောက်အဆင့်အနေနဲ့ အဲ့ဒီ key တွေကို အောက်ပါအတိုင်း fingerprint လုပ်ထားနိုင်ပါပြီ။ -t ဆိုတာ key အမျိုးအစားကိုပြောတာဖြစ်ပြီ၊ -H ဆိုတာကတော့ hash လုပ်မယ်ပြောတာပါ။

vagrant@ssh1:~$ ssh-keyscan -t ed25519 -H 192.168.56.12 192.168.56.13
# 192.168.56.12:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
|1|eMB9ScPCbtnb2qnTz0pc4Wh3+TU=|lk5Rv3QdvcYwfp/NcoA2gzSSwMk= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv
# 192.168.56.13:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
|1|ApSKUfxQJhPsP63QMBDE/1cbdsE=|6DFLpf9j6jFv3zc0YXqY8TCoMdg= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEZQbCc8u6r2CVboxEesTZTMmZnMuEidK9zNjkD2RGEv

vagrant@ssh1:~$ ssh-keyscan -t ed25519 -H 192.168.56.12 192.168.56.13 >> ~/.ssh/known_hosts
# 192.168.56.12:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
# 192.168.56.13:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6

vagrant@ssh1:~$ ssh vagrant@192.168.56.12
vagrant@192.168.56.12's password: 
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Wed Jul 17 12:27:21 PM UTC 2024

  System load:  0.06689453125      Processes:             144
  Usage of /:   14.3% of 30.34GB   Users logged in:       0
  Memory usage: 20%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.12


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Wed Jul 17 12:27:22 2024 from 192.168.56.11
vagrant@ssh2:~$ 

အခုဆိုရင် အထက်မှာမြင်တွေ့ရတဲ့အတိုင်း 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 ကိုတခါရိုက်ထည့်ပြီးသွားတာနဲ့ နောက်တခေါက်ထပ်ရိုက်ထည့်စရာမလိုတော့ပါ။ ဘယ်လိုမျိုး အသုံးချနိုင်သလဲဆိုတာကို အောက်မှဖော်ပြပေးထားပါတယ်။

# before using ssh-agent with passphrase
vagrant@ssh1:~$ ssh vagrant@192.168.56.12
Enter passphrase for key '/home/vagrant/.ssh/id_ed25519': 
Last login: Sun Jul 21 04:15:14 2024 from 192.168.56.11
vagrant@ssh2:~$

# after setting up ssh-agent for the current session
## start ssh-agent
vagrant@ssh1:~$ eval `ssh-agent -s`
Agent pid 2144

## add the private to ssh-agent with ssh-add command
vagrant@ssh1:~$ ssh-add .ssh/id_ed25519
Enter passphrase for .ssh/id_ed25519: 
Identity added: .ssh/id_ed25519 (vagrant@ssh1)

## verify if the private key is actually loaded 
vagrant@ssh1:~$ ssh-add -l
256 SHA256:wQMUdxf7bBedaIeFlYyk9FlXv9AvfVeAIt4JEaJwCWs vagrant@ssh1 (ED25519)

## login to the remote server again 
vagrant@ssh1:~$ ssh vagrant@192.168.56.12
Last login: Sun Jul 21 04:15:24 2024 from 192.168.56.11
vagrant@ssh2:~$ 

မြင်တဲ့အတိုင်းပဲ လက်ရှိ 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 ကိုအသုံးပြုပြီး အဆင့်ဆင့်ခုန်ရပါတယ်။

  1. ကိုယ့် local machine ကနေ deployment server ပေါ်ကို ssh နဲ့ remote access ဝင်ရပါတယ်။

  2. ပြီးရင် အဲ့ဒီ deployment server ကနေ ssh ကိုအသုံးပြုပြီး အခြားသော target machines တွေကို ဖန်းတီးရပါတယ်၊ configure လုပ်ရပါတယ်။

  3. လိုအပ်ရင် အဲ့ဒီ target machine တလုံးပေါ်ကနေ၊ အခြား target machine တခုပေါ်ကိုလည်း ssh နဲ့ ဝင်ရပြန်ပါတယ်။

ဒီတော့ စာရေးသူအတွက် ssh-agent forwarding ကိုအသုံးမပြုဘူး ဆိုရင် ကိုယ့်ရဲ့ ssh private key ကို တခါခုန်တိုင်း အဲ့ဒီ source machine ပေါ်ကို copy ထည့်ရင်ထည့်၊ ဒါမှမဟုတ်ရင်တော့ ssh key pair အသစ်တခုကို တခါခုန်တိုင်း အသစ် generate လုပ်ရမှာဖြစ်ပါတယ်။ ပြဿနာက အဲ့ဒီ key တွေအားလုံးကို manage လုပ်ဖို့အတွက် တော်တော်လေးခက်ပါတယ်။ နောက်တခုက ကိုယ့် private key ကနေရာတကာ ပွစာကြဲလို့နေပါတယ်။ စာရေးသူအတွက်တော့ ဘယ်လိုမှ ကြည့်မကောင်းတဲ့ မြင်ကွင်းတခုပါ။ ဒီမှာ ssh-agent ကိုအသုံးပြုပြီး အဲ့ဒီပြဿနာကို ဘယ်လိုမျိုး ဖြေရှင်းသလဲဆိုတာကြည့်လိုက်ရအောင်။

# following steps are the same as above 
vagrant@ssh1:~$ eval `ssh-agent -s`
Agent pid 2144
vagrant@ssh1:~$ ssh-add .ssh/id_ed25519
Enter passphrase for .ssh/id_ed25519: 
Identity added: .ssh/id_ed25519 (vagrant@ssh1)
vagrant@ssh1:~$ ssh-add -l
256 SHA256:wQMUdxf7bBedaIeFlYyk9FlXv9AvfVeAIt4JEaJwCWs vagrant@ssh1 (ED25519)

# use -A flag to perform ssh-agent forwarding
vagrant@ssh1:~$ ssh -A vagrant@192.168.56.12
Last login: Sun Jul 21 04:15:24 2024 from 192.168.56.11
vagrant@ssh2:~$ 

အထက်မှပြထားတဲ့ အတိုင်း ssh-agent forwarding လုပ်ထားလိုက်ပြီဆိုရင် remote machine ပေါ်မှာ ssh authentication socket တခုကို အလိုအလျှောက် ဖန်တီးပေးလိုက်ပါတယ်။ Socket ကိုစူးစမ်းချင်ရင် echo $SSH_AUTH_SOCK လို့ရိုက်ထည့်လိုက်ရုံပါပဲ။ ဒီ socket ကိုပဲအသုံးပြီး ကိုယ့် public key နဲ့ setup လုပ်ထားတဲ့ အခြားသော remote hosts တွေပေါ်ကို နောက်တဆင့်ထပ်ပြီးခုန်လို့ရပါတယ်။ အဲ့ဒီ -A flag ကိုမပါပဲ အလွယ်တကူသုံးချင်ရင် ~/.ssh/config မှာအောက်ကအတိုင်းသွားထည့်ထားလိုက်ရုံပါပဲ။

Host ssh2
    ForwardAgent yes

ကောင်းပြီ ကိုယ့် 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 ဖြစ်ပါတယ်။

# use ssh2(192.168.56.12) as jumphost to ssh into ssh3(192.168.56.13)
vagrant@ssh1:~$ ssh -J 192.168.56.12 192.168.56.13
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-102-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

  System information as of Sun Jul 21 05:20:34 AM UTC 2024

  System load:  0.0                Processes:             142
  Usage of /:   14.6% of 30.34GB   Users logged in:       1
  Memory usage: 12%                IPv4 address for eth0: 10.0.2.15
  Swap usage:   0%                 IPv4 address for eth1: 192.168.56.13


This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Sun Jul 21 05:20:44 2024 from 192.168.56.11
vagrant@ssh3:~$ 

အလွယ်တကူသုံးနိုင်အောင်လို့ ~/.ssh/config မှာထည့်သုံးချင်ရင် အောက်မှာပြထားသလို ssh1 host ပေါ်မှာ configure လုပ်ဖို့လိုပါလိမ့်မယ်။

Host ssh2
	HostName 192.168.56.12
	User vagrant
Host ssh3
	HostName 192.168.56.13
	ProxyJump ssh2
	User vagrant
PreviousSSH Tunneling အကြောင်းသိကောင်းစရာNextSSH Certificate Based Authentication အကြောင်းတစေ့တစောင်း

Last updated 10 months ago

Was this helpful?

ဒါကတော့ စာရေးသူ နေ့စဉ်အသုံးများတဲ့ ssh workflow တွေပဲဖြစ်ပါတယ်။ SSH မှာသုံးလို့ရတဲ့ အခြားသော workflow တွေလည်းရှိပါသေးတယ်။ ကိုယ်ဘယ်လိုမျိုး ssh ကိုအသုံးချသလဲပေါ်မူတည်ပြီး အသုံးပြုတဲ့ပုံစံလေးတွေတော့ ကွာခြားနိုင်ပါတယ်။ SSH ကိုသုံးပြီး tunnel တွေဖန်တီးပုံကိုလေ့လာချင်ရင် စာရေးသူအရင်က ရေးထားတဲ့ ဒီ လေးမှာလည်းသွားရောက် လေ့လာနိုင်ပါတယ်။

post
🍒
Page cover image