হাতে-কলমে Security Group, SSH আর Session Manager

এই লেসন শেষে তুমি যা পারবে

• একটা সত্যিকারের instance-এর জন্য Security Group সাজাতে পারবে: ঠিক port, ঠিক source, আর admin access-এর জন্য আলাদা একটা group।
• চেনা port-গুলো দেখামাত্র চিনবে, পরীক্ষায় আসা database আর file sharing-এর port-সহ।
• Key pair বানাতে আর সেটা নিরাপদে রাখতে পারবে, আর Linux, Mac বা Windows থেকে Linux instance-এ SSH করতে পারবে।
• SSH ব্যর্থ হলে error দেখেই বুঝবে কোথায় খুঁজতে হবে: timeout, connection refused, permission denied, key ফাইল বেশি খোলা, host key বদলে গেছে।
• সরাসরি SSH, bastion, EC2 Instance Connect, Instance Connect Endpoint আর Session Manager — কখন কোনটা, ঠিক করতে পারবে।
• EC2-এর application-কে access key না দিয়ে IAM role দিয়ে AWS ব্যবহার করতে দেবে, আর Windows instance-এ RDP দিয়ে বা RDP port না খুলেই ঢুকতে পারবে।

#তত্ত্ব থেকে চালু instance-এ

লেসন ৩.৫-এ আমরা দেখেছি Security Group কীভাবে কাজ করে: শুধু allow rule, stateful, network interface-এ লাগানো থাকে, আর rule-এ অন্য group-কে source বানানো যায়। লেসন ৩.৪-এ দেখেছি bastion host, আর Session Manager-এর সাথে প্রথম পরিচয়। এই লেসন হাতে-কলমে কাজের: তুমি এইমাত্র একটা instance চালু করলে, এখন ঠিক traffic-কে ঢুকতে দিতে হবে, নিজে লগইন করতে হবে, আর বাকি সবাইকে বাইরে রাখতে হবে।

এখানে আসলে দুটো আলাদা প্রশ্ন, আর নতুনরা প্রায়ই দুটোকে গুলিয়ে ফেলে:

1. Network দিয়ে instance পর্যন্ত কে পৌঁছাতে পারবে? এটা ঠিক করে Security Group (সাথে Network ACL, route আর public IP)।
2. পৌঁছানোর পর কে লগইন করতে পারবে? SSH-এর বেলায় key pair, RDP-র বেলায় Windows password, আর Instance Connect বা Session Manager-এর বেলায় IAM।

লগইন করতে দুটোই লাগে। “connect হচ্ছে না” ধরনের বেশির ভাগ সমস্যার সমাধান হয়ে যায় শুধু এটা বের করলেই যে এই দুটোর কোনটা আটকেছে।

#চালু instance-এ Security Group

instance launch করার সময় console একটা Security Group চায়। কয়েকটা অভ্যাস করে নিলে পরে অনেক ঝামেলা কমে:

• প্রতিটা কাজের জন্য আলাদা group। যেমন sg-web (যে কারও জন্য 80 আর 443) আর sg-admin (22 শুধু তোমার অফিস থেকে)। একটা network interface-এ ৫টা পর্যন্ত group লাগানো যায়, আর সবগুলোর rule মিলেমিশে কাজ করে। সব জায়গা থেকে admin access একসাথে বন্ধ করতে চাইলে শুধু sg-admin খুলে নাও বা খালি করে দাও; web-এর rule-এ হাতই দিতে হয় না।
• “My IP” সাবধানে ব্যবহার করো। Console তোমার এখনকার address-টা /32 হিসেবে বসিয়ে দিতে পারে। কিন্তু বাসার internet-এ router restart হলেই প্রায়ই নতুন public address চলে আসে, তখন গতকালের rule আজ আর মেলে না। অফিসের address যদি স্থির হয়, সেগুলো একটা managed prefix list-এ রেখে সব group থেকে সেটাকেই ব্যবহার করা যায়।
• বদল সাথে সাথে কাজ করে। Rule বদলালে বা group লাগালে চালু instance-এ তখনই প্রভাব পড়ে; restart লাগে না।
• Outbound শুরু থেকেই খোলা। নতুন group সব outbound traffic যেতে দেয়। এটা কড়া করবে শুধু তখনই, যখন instance-এর দরকারি সব গন্তব্য (update, API, Systems Manager) তুমি নিশ্চিত জানো।

#যে port-গুলো জানতেই হবে

পরীক্ষায় অনেক সময় port-টাই পুরো প্রশ্ন: “Linux instance-এ লগইন হচ্ছে না” → Security Group-এ port 22 দেখো; “Windows instance-এ লগইন হচ্ছে না” → port 3389।

#একটা WordPress সাইটের rule set

একটা ছোট ব্যবসা একটা instance-এ WordPress চালায়। ভিজিটর আসবে দুনিয়ার যেকোনো জায়গা থেকে; server দেখভাল করে শুধু মালিক।

0.0.0.0/0 মানে দুনিয়ার যেকোনো IPv4 address; /32 মানে ঠিক একটা address। এখানে দুটো রকমফের মাথায় রাখো:

• MySQL একই instance-এ: WordPress তার সাথে কথা বলে localhost দিয়ে, তাই port 3306 খোলারই দরকার নেই।
• MySQL আলাদা database server-এ: সেই server-এর group 3306 খুলবে WordPress server-এর Security Group থেকে, 0.0.0.0/0 থেকে কখনো না।

আরও ভালো হয় SSH-এর rule-টাই পুরো বাদ দিয়ে Session Manager (নিচে আছে) ব্যবহার করলে: তখন server-এ খোলা থাকে শুধু 80 আর 443।

#Key pair

AWS-এর Linux instance-এ SSH করতে password লাগে না। লাগে একটা key pair:

• public key থাকে instance-এ, default user-এর ~/.ssh/authorized_keys ফাইলে। প্রথম boot-এর সময় cloud-init এটা ওখানে বসিয়ে দেয়;
• private key থাকে তোমার কাছে, ল্যাপটপের একটা ফাইলে।

লগইনের সময় ssh একটা challenge-এ private key দিয়ে sign করে দেখায় যে key-টা সত্যিই তোমার কাছে আছে; instance সেই signature public key দিয়ে মিলিয়ে নেয়। Private key নিজে কখনো network দিয়ে যায় না।

EC2 key pair নিয়ে যা জানতে হবে:

#ফাইলটা সুরক্ষিত রাখো: chmod 400

তোমার কম্পিউটারের অন্য user-রা যদি private key ফাইল পড়তে পারে, ssh সেই key ব্যবহারই করে না। ফাইল বেশি খোলা থাকলে একটা warning আসে যে private key ফাইলটা অরক্ষিত, তারপর লগইন ব্যর্থ হয়। একবার ঠিক করে নাও:

chmod 400 my-key.pem          # Linux আর Mac: শুধু তুমি পড়তে পারবে

Windows-এ inherited permission সরিয়ে দাও, যাতে শুধু তোমার account ফাইলটা পড়তে পারে (ফাইলের Properties → Security → Advanced থেকে, অথবা icacls দিয়ে)।

#Private key হারিয়ে গেলে

AWS সেটা ফেরত দিতে পারে না। EBS root volume-ওয়ালা Linux instance-এ আবার ঢোকার সাধারণ উপায়গুলো:

• Session Manager বা EC2 Instance Connect, যদি আগে থেকেই চালু থাকে: ঢুকে authorized_keys-এ একটা নতুন public key যোগ করে দাও;
• instance stop করো, root volume খুলে আরেকটা সাহায্যকারী instance-এ লাগাও, ফাইলে নতুন public key যোগ করো, তারপর volume আগের জায়গায় ফিরিয়ে instance চালু করো।

#Linux, Mac আর Windows থেকে SSH

যেখানে OpenSSH আছে, সেখানে command একই:

ssh -i my-key.pem ec2-user@198.51.100.10

এর তিনটা অংশ: private key (-i), user name, আর instance-এর public IP বা DNS নাম। User name নির্ভর করে image-এর ওপর:

প্রথমবার connect করলে ssh server-এর host key fingerprint দেখিয়ে জিজ্ঞেস করে, একে বিশ্বাস করবে কি না। তোমার উত্তর জমা থাকে ~/.ssh/known_hosts-এ, যাতে পরের বার ওই address-এ অন্য কোনো মেশিন উত্তর দিলে ssh ধরতে পারে।

#SSH ব্যর্থ হলে: error-টা পড়ো

প্রতিটা message আলাদা আলাদা স্তরের দিকে আঙুল তোলে। Timeout মানে firewall আর refused মানে application কেন, সেটা লেসন ৩.৫-এ দেখেছি; এখানে SSH-এর পুরো checklist:

#EC2 Instance Connect

EC2 Instance Connect দিয়ে নিজের কাছে key ফাইল না রেখেই SSH session খোলা যায়। Console-এ Connect চাপলে browser-এই একটা terminal খুলে যায়, আবার CLI দিয়েও করা যায়। পর্দার পেছনে যা হয়:

1. IAM দেখে, এই instance-এ এই OS user-এর জন্য key পাঠানোর অনুমতি তোমার আছে কি না (ec2-instance-connect:SendSSHPublicKey)।
2. Service একটা অস্থায়ী public key instance metadata-তে পাঠিয়ে দেয়। এটা চলে মাত্র ৬০ সেকেন্ড, লগইন করার জন্য যথেষ্ট।
3. তারপর port 22-এ একটা সাধারণ SSH connection হয়। instance-এ থাকা ec2-instance-connect package-এর কারণে sshd ওই অস্থায়ী key মেনে নেয়।

যা যা লাগে:

• সমর্থিত image: package-টা Amazon Linux 2023, Amazon Linux 2 আর Ubuntu 20.04 ও পরের সংস্করণে আগে থেকেই থাকে; অন্য Linux image-এ install করে নিতে হয়;
• Security Group-এ port 22 খোলা। Browser দিয়ে ঢুকলে connection আসে ওই Region-এর EC2 Instance Connect service-এর address range থেকে, তোমার ল্যাপটপ থেকে নয়। তাই managed prefix list com.amazonaws.<region>.ec2-instance-connect দিয়ে সেটা allow করো;
• Browser পদ্ধতিতে instance-এর একটা public IP (private instance-এর জন্য নিচের endpoint ব্যবহার করো)।

CLI থেকে Instance Connect তোমার নিজের কম্পিউটার থেকেই key পাঠাতে পারে; তখন SSH আসে তোমার নিজের address থেকে:

aws ec2-instance-connect ssh --instance-id i-0123456789abcdef0

#EC2 Instance Connect Endpoint: private instance-এ SSH আর RDP

EC2 Instance Connect Endpoint হলো একটা endpoint, যেটা তুমি VPC-র একটা subnet-এ বানাও। Console বা CLI থেকে তোমার connection AWS ওই endpoint দিয়ে tunnel করে instance-এর private IP পর্যন্ত পৌঁছে দেয়:

• পথে public IP, internet gateway, bastion host কিছুই লাগে না;
• কে tunnel খুলতে পারবে, ঠিক করে IAM (ec2-instance-connect:OpenTunnel), আর প্রতিটা tunnel CloudTrail-এ লেখা থাকে;
• এটা SSH (22) আর RDP (3389) বহন করে; একেকটা tunnel সর্বোচ্চ এক ঘণ্টা থাকে;
• endpoint-এর জন্য আলাদা কোনো খরচ নেই;
• লগইন তবুও key দিয়েই হয়, তোমার নিজের key বা Instance Connect-এর পাঠানো অস্থায়ী key।

এখানে endpoint-ই হলো তোমার instance-এর client, তাই Security Group-ও সেভাবে সাজাতে হয়: instance port 22 (বা 3389) allow করবে endpoint-এর Security Group থেকে, আর endpoint-কে ওই port-এ instance-এর দিকে traffic পাঠাতে দিতে হবে।

#Session Manager

AWS Systems Manager Session Manager দিয়ে instance-এ shell পাওয়া যায় কোনো inbound port ছাড়াই। লেসন ৩.৪-এ একে bastion-এর আধুনিক বিকল্প হিসেবে দেখেছিলাম; এবার দেখি এটা কীভাবে কাজ করে।

1. instance-এ SSM Agent চলে। Amazon Linux 2023, Amazon Linux 2, Ubuntu আর AWS-এর দেওয়া Windows Server image-গুলোতে এটা আগে থেকেই install করা থাকে।
2. instance-এর Systems Manager-এর সাথে কথা বলার অনুমতি থাকতে হয়: সাধারণত AmazonSSMManagedInstanceCore managed policy দেওয়া একটা IAM role (instance profile)। বিকল্প হলো Default Host Management Configuration, যেটা account আর Region-এর সব instance-কে একসাথে এই অনুমতি দেয়।
3. Agent-এর HTTPS 443-এ বাইরে যাওয়ার পথ লাগে: NAT gateway বা internet gateway দিয়ে internet-এ, অথবা private ভাবে ssm, ssmmessages আর ec2messages-এর interface VPC endpoint দিয়ে। এই তিনটে দিলে নিশ্চিন্ত; তবে SSM Agent 3.3.40.0 থেকে agent অনুমতি থাকলে ec2messages-এর বদলে ssmmessages দিয়েই কাজ সারে, তাই না হলেই নয় এমন দুটো হলো ssm আর ssmmessages (lesson 25.3)।
4. তোমার IAM-এ ওই instance-এ session শুরু করার অনুমতি থাকতে হয় (ssm:StartSession)। তারপর console থেকে, অথবা aws ssm start-session দিয়ে session খোলো (CLI-তে Session Manager plugin লাগে)।

Agent Systems Manager-এর সাথে একটা বাইরের দিকের connection সবসময় খোলা রাখে, আর তোমার session চলে সেটার ভেতর দিয়েই। instance-এর Security Group-এ কোনো inbound rule লাগে না, আর বানানো, ভাগ করা বা হারানোর মতো কোনো SSH key-ও নেই।

Session Manager আর কী কী দেয়:

• Logging। Session-এর output CloudWatch Logs-এ পাঠানো যায় আর S3 bucket-এ জমা রাখা যায়; চাইলে AWS Key Management Service-এর নিজের key দিয়ে session encrypt-ও করা যায়।
• সূক্ষ্ম নিয়ন্ত্রণ। IAM policy দিয়ে বলে দেওয়া যায়, শুধু নির্দিষ্ট tag-ওয়ালা instance-এ session খোলা যাবে, যেমন env=dev।
• Port forwarding। নিজের ল্যাপটপ থেকে instance-এর কোনো port-এ (বা তার পেছনের database-এ) পৌঁছানো যায়, তাও কোনো inbound কিছু না খুলেই।
• এর ভেতর দিয়ে SSH আর ফাইল কপি (scp), যেসব tool SSH ছাড়া চলে না তাদের জন্য, port 22 না খুলেই।
• Windows-এও চলে: PowerShell session, আর Fleet Manager দিয়ে browser-এ পুরো RDP desktop।
• EC2 instance-এর জন্য বাড়তি কোনো খরচ নেই।

#ঢোকার উপায়গুলো পাশাপাশি

#instance-এ কখনো access key রেখো না

আজ হোক কাল হোক, instance-এর application-এর AWS-কেই দরকার পড়বে: S3 থেকে পড়া, queue-তে লেখা, DynamoDB-তে query। সহজ শর্টকাট মনে হয় instance-এ aws configure চালিয়ে একটা access key বসিয়ে দেওয়া। এটা কখনো করবে না। কারণ এই key:

• দীর্ঘমেয়াদি: কেউ বন্ধ না করা পর্যন্ত দুনিয়ার যেকোনো কম্পিউটার থেকে কাজ করে;
• disk-এর সাথে সাথে ঘোরে: image-এ, snapshot-এ, backup-এ, আর ভুল করে code repository-তেও চলে যায়;
• সাধারণত application-এর যতটুকু দরকার, তার চেয়ে অনেক বেশি permission নিয়ে থাকে;
• প্রতিটা instance-এ হাতে করে rotate করতে হয়।

এর বদলে instance-এ একটা IAM role লাগাও (instance profile-এর মাধ্যমে):

• instance-এর AWS CLI আর AWS-এর software library-গুলো instance metadata থেকে role-এর অস্থায়ী credential নিজেই খুঁজে নেয় (metadata নিরাপদে পড়ার নিয়ম লেসন ৪.৩-এ)।
• মেয়াদ শেষ হওয়ার অনেক আগেই AWS এগুলো নিজে থেকে rotate করে দেয়। Disk-এ গোপন কিছুই থাকে না।
• Role-এর policy application-কে ঠিক যতটুকু দরকার ততটুকুই দেয়, যেমন “শুধু এই একটা bucket পড়া”।
• একটা instance-এ একবারে একটাই role থাকে। চালু instance-এই role লাগানো, বদলানো বা সরানো যায়, restart লাগে না।

#Windows instance: RDP-র পথ

Windows instance চালানো হয় Remote Desktop (RDP, port 3389) দিয়ে, user name আর password দিয়ে; SSH key দিয়ে নয়।

1. Security Group-এ 3389 খোলো, শুধু তোমার address থেকে (0.0.0.0/0 কখনো না)।
2. Launch-এর পর কয়েক মিনিট অপেক্ষা করো, তারপর console-এ Get Windows password বেছে নাও। প্রথম boot-এ Windows একটা random Administrator password বানিয়ে সেটা তোমার key pair-এর public key দিয়ে encrypt করে রেখেছে; তুমি private key (.pem) দিলে সেটা decrypt হয়। এ কারণেই Windows-এ RSA key pair লাগে।
3. RDP client খোলো (Windows-এ Remote Desktop Connection, Mac-এ Windows App), public IP-তে connect করো, আর ওই password দিয়ে Administrator হিসেবে লগইন করো।

Internet-এর জন্য 3389 না খুলেই ঢোকার উপায়:

• Fleet Manager Remote Desktop (Systems Manager-এর অংশ): browser-এই পুরো graphical RDP session, যেটা বয়ে নেয় Session Manager।
• PowerShell session-এর জন্য Session Manager।
• Private instance-এ RDP-র জন্য EC2 Instance Connect Endpoint।

#System design-এ কীভাবে ব্যবহার হয়

একটা production setup সাধারণত এমন দেখায়:

• Internet থেকে কোনো SSH নেই। Application server-গুলো থাকে private subnet-এ; তাদের Security Group শুধু load balancer-কে application-এর port-এ ঢুকতে দেয়। Port 22 কোথাও খোলা নেই।
• মানুষের জন্য Session Manager, VPC endpoint দিয়ে, যাতে management traffic-ও internet-এ না যায়। Session log যায় retention policy দেওয়া একটা S3 bucket-এ, আর IAM-এর নিয়ম tag ধরে (developer-রা env=dev-এ, production-এ শুধু ছোট একটা দল)।
• Software-এর জন্য IAM role। প্রতিটা instance পায় একটা role, তার application-এর ঠিক যতটুকু permission দরকার ততটুকু। কোথাও কোনো access key নেই।
• লগইনই যত কম, তত ভালো। instance বানানো হয় image থেকে, আর সেটআপ হয় নিজে নিজে (লেসন ৪.৩), তাই হাতে করে কিছু ঠিক করতে কাউকে ঢুকতে হয় না; খারাপ হয়ে যাওয়া instance মেরামত না করে বদলে ফেলা হয়।
• জরুরি অবস্থার একটা পথ। একটা লিখে রাখা emergency রাস্তা রাখো, যেমন একটা Instance Connect Endpoint, কড়া IAM permission দিয়ে, আর প্রতিবার ব্যবহারে alert যায় এমন ব্যবস্থা করে।

#নিজে করে দেখো

# 1. Key pair বানাও, private key সুরক্ষিত করো
aws ec2 create-key-pair --key-name lab-key --key-type ed25519 \
  --query KeyMaterial --output text > lab-key.pem
chmod 400 lab-key.pem

# 2. Admin Security Group: SSH শুধু তোমার এখনকার address থেকে
MYIP=$(curl -s https://checkip.amazonaws.com)
ADMIN=$(aws ec2 create-security-group --group-name admin --description "SSH from my IP" \
  --vpc-id $VPC --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $ADMIN --protocol tcp --port 22 --cidr $MYIP/32

# 3. লগইন (debug output-এ TCP, host key আর authentication-এর ধাপ দেখা যায়)
ssh -v -i lab-key.pem ec2-user@198.51.100.10

# চাইলে ~/.ssh/config-এ একটা shortcut, তারপর শুধু "ssh lab"
#   Host lab
#     HostName 198.51.100.10
#     User ec2-user
#     IdentityFile ~/lab-key.pem

# 4. EC2 Instance Connect: অস্থায়ী key পাঠিয়ে connect (key ফাইল লাগে না)
aws ec2-instance-connect ssh --instance-id i-0123456789abcdef0

# 5. Private Instance-এর জন্য Instance Connect Endpoint
aws ec2 create-instance-connect-endpoint --subnet-id $PRIVATE_SUBNET --security-group-ids $EICE_SG
aws ec2-instance-connect ssh --instance-id i-0abcdef1234567890 --connection-type eice

# 6. Session Manager: Instance-কে role দাও, তারপর shell খোলো (Session Manager plugin লাগে)
aws ec2 associate-iam-instance-profile --instance-id i-0abcdef1234567890 \
  --iam-instance-profile Name=ssm-core-profile
aws ssm describe-instance-information --query "InstanceInformationList[].InstanceId"
aws ssm start-session --target i-0abcdef1234567890

# 7. Session Manager চালু হয়ে গেলে SSH পুরো বন্ধ করে দাও
aws ec2 revoke-security-group-ingress --group-id $ADMIN --protocol tcp --port 22 --cidr $MYIP/32

#সারসংক্ষেপ

মূল কথাগুলো

• instance পর্যন্ত পৌঁছানো (Security Group, NACL, public IP, route) আর লগইন করা (key, password, IAM) আলাদা দুটো পরীক্ষা; লগইনে দুটোই পার হতে হয়।
• Admin access রাখো আলাদা Security Group-এ, 22 বা 3389 খোলো শুধু চেনা address থেকে, 0.0.0.0/0 থেকে কখনো না। বাসার IP বদলে যায়, খেয়াল রেখো।
• Port: 21 FTP, 22 SSH আর SFTP, 80 HTTP, 443 HTTPS, 3389 RDP, 3306 MySQL/Aurora, 5432 PostgreSQL, 1433 SQL Server, 1521 Oracle, 2049 NFS, 445 SMB।
• AWS রাখে শুধু public key; private key download হয় একবারই। OpenSSH-এর জন্য .pem (Windows 10+ সহ), PuTTY-র জন্য .ppk। ফাইলে chmod 400 দাও। Default user: Amazon Linux-এ ec2-user, Ubuntu-তে ubuntu।
• Timeout → network-এর পথ (প্রায়ই তোমার IP বদলে গেছে)। Refused → sshd শুনছে না। Permission denied → ভুল user বা ভুল key।
• Instance Connect IAM দিয়ে ৬০ সেকেন্ডের একটা key পাঠায়, কিন্তু port 22 তবুও লাগে (service-এর range থেকে)। Instance Connect Endpoint public IP বা bastion ছাড়াই private instance-এ SSH বা RDP পৌঁছে দেয়।
• Session Manager: SSM Agent + instance-এর অনুমতি + বাইরে যাওয়ার পথ (NAT বা VPC endpoint) + user-এর জন্য IAM। কোনো inbound port নেই, key নেই, session log যায় S3/CloudWatch Logs-এ (CloudTrail লেখে শুধু কে session শুরু করল)।
• EC2-এর application ব্যবহার করবে IAM role, instance-এ রাখা access key কখনো নয়।
• Windows: RDP চলে 3389-এ, password decrypt হয় key pair-এর private key দিয়ে; Fleet Manager দিয়ে 3389 না খুলেই RDP পাওয়া যায়।

নিজেকে যাচাই করো: হাতে-কলমে Security Group, SSH আর Session Manager৩০টি প্রশ্ন