SSH কী এবং এটি কীভাবে কাজ করে?

SSH কী?

SSH (secure shell) হলো একটি প্রোটোকল যার মাধ্যমে দূরবর্তী কোনো কম্পিউটারে লগ-ইন করা যায় এবং একটি এনক্রিপ্টেড সংযোগের মাধ্যমে সেখানে কমান্ড চালানো যায়। আপনি যা টাইপ করেন তা রিমোট মেশিনে চলে যায়, সেখান থেকে আউটপুট ফিরে আসে এবং মাঝপথে নেটওয়ার্ক পর্যবেক্ষণকারী কেউ এই তথ্যের কিছুই পড়তে পারে না। একটি ভাড়াকৃত Linux সার্ভারে কোনো স্ক্রিন বা কিবোর্ড যুক্ত থাকে না, তাই SSH-ই হলো সেই মাধ্যম যার সাহায্যে মেশিনটি ব্যবহার করা হয়।

এই নামটি দুটি বিষয়কে নির্দেশ করে। SSH হলো প্রোটোকল, যা RFC 4251 থেকে RFC 4254-এ বর্ণিত হয়েছে। OpenSSH হলো সেই প্রোগ্রাম যা এই প্রোটোকলটি বাস্তবায়ন করে এবং প্রায় প্রতিটি Linux সার্ভার ও ল্যাপটপে এটিই চলে। যখন কেউ বলেন "SSH into the server", তখন তারা তাদের মেশিনের ক্লায়েন্ট প্রোগ্রাম ssh দিয়ে অপর প্রান্তের সার্ভার প্রোগ্রাম sshd-এর সাথে যোগাযোগ করার কথা বোঝান।

SSH যে সমস্যাটি সমাধানের জন্য তৈরি হয়েছিল

রিমোট লগইন SSH-এর চেয়ে অনেক পুরনো। Telnet পোর্ট 23-এ একটি plain TCP সংযোগ খুলত এবং প্রতিটি বাইট ঠিক যেভাবে টাইপ করা হতো, সেভাবেই পাঠিয়ে দিত। এতে কোনো কিছুই এনক্রিপ্ট করা থাকত না, এমনকি আপনার পাসওয়ার্ডও নয়। যে কেউ এই ট্রাফিক দেখতে পেলে তা পড়তে পারত: একই অফিসের নেটওয়ার্কে থাকা কোনো ব্যক্তি অথবা পথের যেকোনো রাউটারের অপারেটর। rlogin পরিবারেরও একই দুর্বলতা ছিল এবং এটি ক্লায়েন্ট মেশিনের নামকে বিশ্বাস করত, যার অর্থ হলো নেটওয়ার্ক যে নাম দাবি করত, তাকেই বিশ্বাস করা হতো।

Tatu Ylönen 1995 সালে Helsinki University of Technology-তে প্রথম SSH তৈরি করেন, যখন বিশ্ববিদ্যালয়ের নেটওয়ার্কে পাসওয়ার্ড স্নুপিংয়ের একটি আক্রমণ ঘটেছিল। এই ডিজাইনে Telnet-এর প্রয়োজনীয় অংশটি রাখা হয়েছে, যা আপনার টার্মিনাল এবং রিমোট শেলের মধ্যে একটি বাইট স্ট্রিম তৈরি করে। এর সাথে এমন দুটি বিষয় যুক্ত করা হয়েছে যার কোনো সমাধান Telnet-এর কাছে ছিল না: স্ট্রিমের এনক্রিপশন এবং অপর প্রান্তে থাকা সার্ভারটিই যে আপনার কাঙ্ক্ষিত সার্ভার, তার প্রমাণ।

দ্বিতীয় অংশটি এড়িয়ে যাওয়া সহজ, অথচ এটি SSH-এর অর্ধেক কাজ। শুধুমাত্র এনক্রিপশন আপনাকে রক্ষা করতে পারবে না। মাঝখানে থাকা কোনো মেশিন আপনার সংযোগ গ্রহণ করে তা নিখুঁতভাবে এনক্রিপ্ট করতে পারে, আপনার পাঠানো সবকিছু পড়তে পারে এবং তারপর তা আসল সার্ভারে পাঠিয়ে দিতে পারে। SSH প্রতিটি সার্ভারকে একটি স্থায়ী পরিচয় প্রদান করে এই আক্রমণ ঠেকায়, যাকে বলা হয় host key, এবং প্রতিটি সংযোগের সময় এটি যাচাই করা হয়।

ক্লায়েন্ট এবং সার্ভার মডেল যেভাবে কাজ করে

এখানে দুটি প্রোগ্রাম থাকে। সার্ভারে, sshd সব সময় চলতে থাকে এবং সংযোগের জন্য অপেক্ষা করে। আপনার মেশিনে, ssh সেই সংযোগ তৈরি করে। এগুলো আলাদা আলাদা প্রোগ্রাম এবং এদের কনফিগারেশন ফাইলও আলাদা। এই দুটির মধ্যে গুলিয়ে ফেলা একটি সাধারণ ভুল, যার কারণে কোনো এডিট কার্যকর হয় না।

• সার্ভার /etc/ssh/sshd_config ফাইলটি পড়ে। এখানেই পাসওয়ার্ড লগইন বন্ধ করা হয় এবং লিসেনিং পোর্ট সেট করা হয়।
• ক্লায়েন্ট সিস্টেম ডিফল্টের জন্য /etc/ssh/ssh_config পড়ে, এবং হোস্ট অনুযায়ী আপনার নিজস্ব সেটিংসের জন্য ~/.ssh/config পড়ে।

Debian এবং Ubuntu-তে সার্ভিস ইউনিটটিকে ssh বলা হয়। RHEL, Rocky এবং Fedora-তে একে sshd বলা হয়। সাম্প্রতিক Ubuntu রিলিজগুলোতে এটি socket activated হিসেবে ইনস্টল হয়, তাই systemctl status ssh হয়তো inactive (dead) রিপোর্ট করতে পারে, যদিও মেশিনটি পুরোপুরি reachable থাকে। কারণ ssh.socket হলো সেই ইউনিট যা লিসেনিংয়ের কাজ করে এবং প্রয়োজনে সার্ভিসটি চালু করে।

ক্লায়েন্ট হিসেবে যে OpenSSH-ই হতে হবে এমন কোনো কথা নেই। Windows-এ PuTTY, ফোনে Termius এবং এডিটরগুলোতে বিল্ট-ইন থাকা রিমোট সাপোর্ট—সবই একই প্রোটোকলে একই sshd-এর সাথে যোগাযোগ করে। Windows 10 এবং 11-এ OpenSSH ক্লায়েন্ট অন্তর্ভুক্ত থাকে, তাই কোনো কিছু ইনস্টল করা ছাড়াই PowerShell-এ ssh you@server কাজ করে।

SSH কেন port 22 ব্যবহার করে?

একটি port হলো এমন একটি সংখ্যা যা kernel-কে জানায় যে একটি incoming connection কোন listening program-এর জন্য। Linux-এ ports সব সার্ভিসের জন্যই একইভাবে কাজ করে। SSH port 22 ব্যবহার করে কারণ IANA 1995 সালে এটি বরাদ্দ করেছিল। Ylönen এমন একটি খালি সংখ্যা চেয়েছিলেন যা SSH-এর মাধ্যমে প্রতিস্থাপিত প্রোটোকলগুলোর কাছাকাছি থাকে: 21 ছিল FTP, 23 ছিল telnet, এবং 22 ছিল অব্যবহৃত।

যেহেতু 22 ডিফল্ট, তাই সবকিছুই এটি ধরে নেয়। আপনার Git remote, backup script এবং আপনার প্রোভাইডারের control panel—সবই প্রথমে 22 ব্যবহার করার চেষ্টা করে। ইন্টারনেটের প্রতিটি automated scanner-ও তাই করে। password login চালু থাকা একটি নতুন সার্ভার বুট হওয়ার কয়েক মিনিটের মধ্যেই /var/log/auth.log-এ এই ধরনের লাইন জমা হতে শুরু করে:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

এই traffic অবিরাম চলতে থাকে এবং এটি ব্যক্তিগতভাবে আপনাকে লক্ষ্য করে নয়। sshd-কে port 2222-এ সরিয়ে নিলে এই লাইনগুলোর বেশিরভাগই কমে যায়, কারণ scanner-রা আপনার সার্ভারকে আলাদাভাবে পরীক্ষা না করে পুরো ইন্টারনেট জুড়ে port 22 স্ক্যান করে। এটি কোনো আক্রমণকারীর জন্য মেশিনটিকে হ্যাক করা কঠিন করে তোলে না। port পরিবর্তনকে শুধুমাত্র নয়েজ কমানোর উপায় হিসেবে দেখুন, এর বেশি কিছু নয়।

লগইন করার আগেই আপনি সার্ভারের উত্তর পর্যবেক্ষণ করতে পারেন:

nc 203.0.113.10 22

Ubuntu 24.04-এ এটি SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13-এর কাছাকাছি কিছু প্রিন্ট করে। কোনো encryption শুরু হওয়ার আগেই এই banner-টি cleartext-এ পাঠানো হয়, কারণ প্রোটোকল ভার্সন নিয়ে একমত হওয়ার জন্য উভয় পক্ষেরই এটি প্রয়োজন। সংযোগটি বন্ধ করতে Ctrl+C চাপুন।

সংযোগ স্থাপনের সময় নেটওয়ার্কে যা ঘটে

নিচে সেই ক্রমটি দেওয়া হলো যা একটি ssh you@server আপনার প্রম্পট দেখানোর আগে সম্পন্ন করে।

1. ক্লায়েন্ট হোস্টনামটিকে একটি IP ঠিকানায় রূপান্তর করে এবং তারপর পোর্ট 22-এ একটি TCP সংযোগ খোলে।
2. উভয় পক্ষই তাদের ভার্সন ব্যানার প্লেইন টেক্সটে পাঠায়।
3. উভয় পক্ষই তাদের সমর্থিত অ্যালগরিদমের তালিকা পাঠায়: কি এক্সচেঞ্জ, সাইফার, মেসেজ অথেন্টিকেশন এবং কম্প্রেশন। এটিও প্লেইন টেক্সটে থাকে। উভয় পক্ষের জানা সবচেয়ে শক্তিশালী বিকল্পটিই নির্বাচন করা হয়।
4. কি এক্সচেঞ্জ সম্পন্ন হয়। বর্তমান OpenSSH curve25519-sha256-কে অগ্রাধিকার দেয়। উভয় প্রান্তেই একই শেয়ারড সিক্রেট তৈরি হয়, কিন্তু সেই সিক্রেটটি কখনোই নেটওয়ার্কের মধ্য দিয়ে যায় না। ফলে কেউ যদি পুরো কথোপকথন রেকর্ড করেও রাখে, সে পরবর্তীতে এটি বের করতে পারবে না।
5. সার্ভার তার হোস্ট প্রাইভেট কি দিয়ে এই এক্সচেঞ্জের ফলাফল স্বাক্ষর করে। আপনার ক্লায়েন্ট তার কাছে থাকা হোস্ট পাবলিক কি-এর সাথে স্বাক্ষরটি যাচাই করে। এই ধাপটিই মাঝখানে থাকা কোনো যন্ত্রকে আপনার সার্ভারের ছদ্মবেশ ধারণ করা থেকে বিরত রাখে।
6. এনক্রিপশন শুরু হয়। বর্তমান OpenSSH-এ chacha20-poly1305@openssh.com হলো ডিফল্ট সাইফার।
7. কেবল এখন ক্লায়েন্ট আপনাকে পাসওয়ার্ড বা কি-এর মাধ্যমে অথেন্টিকেট করে। আপনার ইউজারনেম এবং পাসওয়ার্ড এনক্রিপ্ট করা চ্যানেলের ভেতর দিয়ে যায়।
8. ক্লায়েন্ট একটি চ্যানেল খোলে এবং একটি শেল (shell) অনুরোধ করে।

এই তালিকার ক্রমটিই telnet থেকে এর মূল পার্থক্য। চ্যানেল এনক্রিপ্ট হওয়ার পর এবং সার্ভার তার পরিচয় নিশ্চিত করার পর অথেন্টিকেশন ঘটে, তাই এমন কোনো মুহূর্ত নেই যখন আপনার পাসওয়ার্ড নেটওয়ার্কে উন্মুক্ত অবস্থায় থাকে।

কেউ যদি নেটওয়ার্ক পর্যবেক্ষণ করে, তবে সে কিছু তথ্য জানতে পারে। সে আপনার IP ঠিকানা, সার্ভারের IP ঠিকানা, পোর্ট 22, উভয় পক্ষের প্লেইন টেক্সট ভার্সন ব্যানার এবং প্রতিটি প্যাকেটের সময় ও আনুমানিক আকার দেখতে পায়। সে আপনার ইউজারনেম, পাসওয়ার্ড, কমান্ড বা সেগুলোর আউটপুট দেখতে পায় না। 1 নম্বর ধাপে হোস্টনাম লুকআপ SSH-এর অংশ নয় এবং এটি সাধারণত গোপন থাকে না, তাই যে DNS কুয়েরি আপনার সার্ভারের নাম রেজলভ করে তা প্রকাশ করে দিতে পারে যে আপনি কোন মেশিনে পৌঁছাতে যাচ্ছেন, যদিও সেশনটি নিজে সুরক্ষিত থাকে।

হোস্ট কি (host key) এবং প্রথম সংযোগের ফিঙ্গারপ্রিন্ট প্রম্পট

যখন openssh-server ইনস্টল করা হয়, এটি মেশিনের জন্য হোস্ট কি পেয়ার (host key pairs) তৈরি করে এবং সেগুলোকে /etc/ssh/-এ লিখে রাখে, উদাহরণস্বরূপ ssh_host_ed25519_key এবং ssh_host_ed25519_key.pub। প্রাইভেট অংশটি কখনোই সার্ভার থেকে বাইরে যায় না। পাবলিক অংশটি হলো সার্ভারের পরিচয়, এবং ধাপ 5-এ স্বাক্ষরটি (signature) এর সাথেই যাচাই করা হয়।

আপনি যখন প্রথমবার কোনো নতুন সার্ভারে সংযোগ করেন, আপনার ক্লায়েন্টের কাছে তুলনা করার মতো কিছু থাকে না, তাই এটি আপনাকে জিজ্ঞাসা করে:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

এই ফিঙ্গারপ্রিন্টটি হলো হোস্ট পাবলিক কি-এর একটি SHA256 হ্যাশ, যা base64 ফরম্যাটে প্রিন্ট করা হয়, যাতে এটি খালি চোখে তুলনা করার মতো যথেষ্ট ছোট হয়। yes টাইপ করলে সেই কি-টি আপনার নিজের মেশিনের ~/.ssh/known_hosts ফাইলে সংরক্ষিত হয়। পরবর্তীতে একই ঠিকানায় প্রতিটি সংযোগের সময় সার্ভার যে কি প্রদান করে, তা সংরক্ষিত কি-এর সাথে তুলনা করা হয়। যখন সেগুলো মিলে যায়, তখন কোনো কিছু প্রিন্ট হয় না এবং আপনি সরাসরি আপনার প্রম্পটে চলে যান।

এই মডেলটিকে বলা হয় 'ট্রাস্ট অন ফার্স্ট ইউজ' (trust on first use), এবং এর সীমাবদ্ধতা সম্পর্কে সৎ থাকা প্রয়োজন। প্রথম সংযোগের মুহূর্তটিই হলো একমাত্র সময় যখন আপনি অরক্ষিত থাকেন, কারণ আপনি এমন একটি কি গ্রহণ করছেন যা আপনি আগে কখনো দেখেননি। এই ঝুঁকি এড়াতে, অন্য কোনো উপায়ে ফিঙ্গারপ্রিন্টটি সংগ্রহ করুন এবং তা যাচাই করুন। বেশিরভাগ প্রোভাইডার তাদের ওয়েব কনসোলের বুট আউটপুটে এটি প্রদর্শন করে, এবং আপনি নিজেও সার্ভারে এটি প্রিন্ট করতে পারেন:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

এটি সেই একই SHA256: স্ট্রিং প্রিন্ট করে যা প্রম্পটে আপনাকে দেখানো হয়েছিল। প্রম্পটে [fingerprint] অপশনটি ঠিক এই কারণেই রাখা হয়েছে: আপনার প্রত্যাশিত ফিঙ্গারপ্রিন্টটি পেস্ট করুন, এবং ক্লায়েন্ট কেবল তখনই সংযোগ চালিয়ে যাবে যদি তা সার্ভারের দেওয়া কি-এর সাথে মিলে যায়।

Debian এবং Ubuntu-তে, known_hosts ডিফল্টভাবে হ্যাশ করা থাকে, তাই ফাইলটিতে পাঠযোগ্য হোস্টনেমের পরিবর্তে |1| দিয়ে শুরু হওয়া লাইন থাকে। কোনো নির্দিষ্ট হোস্টের এন্ট্রি খুঁজে বের করতে ssh-keygen -F 203.0.113.10 কমান্ডটি চালান।

SSH কেন বলে যে host key পরিবর্তিত হয়েছে?

কখনো না কখনো আপনি এই বিশাল সতর্কবার্তার মুখোমুখি হবেন:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

এটি Host key verification failed. দিয়ে শেষ হয় এবং client সংযোগ করতে অস্বীকার করে। এটি Password authentication is disabled to avoid man-in-the-middle attacks.-ও প্রদর্শন করে, কারণ একটি অপরিচিত মেশিনে আপনার password টাইপ করা ঠিক সেই ক্ষতি যা প্রতিরোধের জন্যই এই পরীক্ষাটি বিদ্যমান।

বার্তাটি জরুরি মনে হলেও, বেশিরভাগ সময় এটি তেমন কিছু নয়। সাধারণ কারণগুলো হলো:

• আপনি সার্ভারটি নতুন করে তৈরি বা reinstall করেছেন, তাই sshd প্রথম boot-এর সময় নতুন host key তৈরি করেছে। এটিই এখন পর্যন্ত সবচেয়ে সাধারণ কারণ।
• আপনি একটি VPS ধ্বংস করে অন্যটি তৈরি করেছেন এবং provider নতুন মেশিনটিকে পুরনো IP address দিয়েছে।
• আপনি এমন কোনো forward বা load balancer-এর মাধ্যমে সংযোগ করছেন যা এখন ভিন্ন কোনো backend মেশিনে পৌঁছাচ্ছে।
• সত্যিই কেউ সংযোগটি intercept বা বাধাগ্রস্ত করছে।

কোনো কিছু মুছে ফেলার আগে নিশ্চিত হোন কোনটি কারণ। যদি আপনি দশ মিনিট আগে মেশিনটি reinstall করে থাকেন, তবে কারণটি স্পষ্ট। যদি আপনার দিক থেকে কোনো পরিবর্তন না হয়ে থাকে, তবে থামুন এবং তদন্ত করুন, কারণ এই সতর্কবার্তাটি তার কাজ সঠিকভাবে করছে। একবার নিশ্চিত হওয়ার পর, পুরনো entry-টি মুছে ফেলুন এবং পুনরায় সংযোগ করুন:

ssh-keygen -R 203.0.113.10

পরবর্তী সংযোগে আবার fingerprint prompt দেখাবে, যা আপনাকে provider console-এর সাথে এটি মিলিয়ে দেখার নতুন সুযোগ দেবে।

পাসওয়ার্ড লগইন বনাম কি (key) লগইন

পাসওয়ার্ড অথেন্টিকেশন আপনার পাসওয়ার্ডটিকে ইতিমধ্যে এনক্রিপ্ট করা চ্যানেলের ভেতর দিয়ে পাঠায় এবং sshd এটিকে অ্যাকাউন্ট ডেটাবেসের সাথে যাচাই করে, সাধারণত PAM (pluggable authentication modules)-এর মাধ্যমে। এর জন্য কোনো প্রস্তুতির প্রয়োজন হয় না, যে কারণে একটি প্রোভাইডার আপনাকে শুধুমাত্র একটি root পাসওয়ার্ডসহ নতুন সার্ভার দিতে পারে।

এর দুর্বলতা এনক্রিপশনে নয়। সমস্যা হলো, পাসওয়ার্ড একটি ছোট গোপন তথ্য, প্রতিবার লগইন করার সময় আপনি এটি সার্ভারে পাঠান এবং পোর্ট 22-এ সারাক্ষণ এমন সব মেশিন দ্বারা অনুমান করার চেষ্টা (guess) চালানো হয় যারা কখনোই ক্লান্ত হয় না।

পাবলিক কি (public key) অথেন্টিকেশন ভিন্নভাবে কাজ করে। আপনি আপনার নিজের মেশিনে একটি কি পেয়ার (key pair) তৈরি করেন। পাবলিক অংশটি সার্ভারে আপনার অ্যাকাউন্টের ভেতর ~/.ssh/authorized_keys-এ রাখা হয়। প্রাইভেট অংশটি আপনার ল্যাপটপেই থাকে এবং কখনোই সার্ভারে পাঠানো হয় না। লগইন করার জন্য, ক্লায়েন্ট এমন একটি ডেটা সাইন (sign) করে যাতে কি এক্সচেঞ্জ থেকে প্রাপ্ত সেশন আইডেন্টিফায়ার থাকে এবং সার্ভার তার কাছে থাকা পাবলিক কি ব্যবহার করে সেই সিগনেচার যাচাই করে। যেহেতু সাইন করা ডেটাটি শুধুমাত্র এই একটি সেশনের সাথেই যুক্ত, তাই কোনোভাবে সিগনেচারটি ধরা পড়লেও তা অন্য কোনো কাজে ব্যবহার করা সম্ভব নয়।

দিকটি খেয়াল রাখুন, কারণ এটি উল্টে ফেলা খুব সাধারণ এবং ক্ষতিকর: পাবলিক কি সার্ভারে যায়, প্রাইভেট কি আপনার কাছে থাকে। সার্ভারে কপি করা কোনো প্রাইভেট কি আর বিশ্বাসযোগ্য নয়।

কি লগইনের নিজস্ব কিছু ব্যর্থতার ধরন আছে। ফাইলের পারমিশন খুব বেশি ঢিলেঢালা হলে sshd কি-গুলোকে উপেক্ষা করে এবং সার্ভার লগে তা উল্লেখ করে:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

ক্লায়েন্ট আপনাকে শুধুমাত্র Permission denied (publickey) বার্তাটি দেখায়, যা এক ডজন ভিন্ন ভিন্ন কারণের জন্য একই বার্তা। তাই পাবলিক কি এরর সঠিকভাবে পড়া শিখে রাখা জরুরি, যাতে আপনি সার্ভার থেকে লকড আউট না হয়ে যান। কি তৈরি করা, সেগুলোকে পাসফ্রেজ দিয়ে সুরক্ষিত করা এবং এজেন্ট-এ লোড করার ব্যবহারিক কাজগুলো SSH কি ম্যানেজমেন্ট-এ আলোচনা করা হয়েছে, এবং নিজেকে সার্ভার থেকে বিচ্ছিন্ন না করে পাসওয়ার্ড লগইন বন্ধ করার প্রক্রিয়াটি VPS-এ SSH হার্ডেনিং-এ রয়েছে।

SFTP, scp এবং port forwarding একই connection ব্যবহার করে

এই ধারণাটিই SSH-এর বাকি বিষয়গুলোকে সহজ করে তোলে। Authentication একটি encrypted connection তৈরি করে এবং এই connection একই সময়ে একাধিক স্বাধীন channel বহন করতে পারে। shell হলো এমন অনেকগুলো channel-এর মধ্যে একটি।

• একটি remote shell। ssh you@server একটি session channel খোলে এবং একটি interactive shell-এর অনুরোধ জানায়।
• একটি একক command। ssh you@server uptime একটি channel খোলে, একটি command চালায়, output প্রদর্শন করে এবং exit করে।
• SFTP। client sshd-কে তার sftp subsystem শুরু করতে বলে এবং file transfer একই connection-এর ভেতর দিয়ে চলে। SFTP হলো একটি file transfer protocol যা SSH-এর ওপর ভিত্তি করে চলে এবং এর ডিজাইনের সাথে FTP-এর কোনো সম্পর্ক নেই। যে protocol-টি মূলত FTP কিন্তু তাতে encryption যোগ করা হয়েছে, তাকে বলা হয় FTPS, এবং এটি সম্পূর্ণ ভিন্ন।
• scp। একই login ব্যবহার করে file copy করে। 2022 সালে মুক্তি পাওয়া OpenSSH 9.0 থেকে, scp ডিফল্টভাবে SFTP protocol ব্যবহার করে।
• Port forwarding। ssh -L 8080:localhost:80 you@server আপনার laptop-এর port 8080-কে server-এর port 80-এর একটি প্রবেশদ্বার হিসেবে তৈরি করে, যা encrypted connection-এর ভেতর দিয়ে কাজ করে। -R উল্টো দিকে forward করে এবং -D 1080 session-টিকে একটি SOCKS proxy-তে রূপান্তর করে।
• Git। git@github.com:user/repo.git-এর মতো একটি remote হলো একটি SSH login, যার remote side-এ shell-এর পরিবর্তে একটি command handler চলে।
• rsync এবং Ansible-ও SSH client। তারা একটি channel খোলে, কিছু চালায় এবং output পড়ে।

এই তালিকার প্রতিটি বিষয় একই port, একই host key check এবং একই credentials ব্যবহার করে। এই কারণেই একবার key authentication সেটআপ করলে তা তাৎক্ষণিকভাবে কাজে আসে: প্রতিটি tool-ই এটি উত্তরাধিকারসূত্রে পায়। এই কারণেই একই ~/.ssh/config file, যা আপনার login-কে সংক্ষিপ্ত করে, সেটিই আবার যখন আপনি একাধিক Linux server পরিচালনা করেন, তখন আপনার কাজকে সহজ করে তোলে।

SSH যা করে না

• এটি আপনার সার্ভারকে সুরক্ষিত করে না। SSH কেবল দরজার পথটিকে সুরক্ষিত রাখে। দরজাটি সেখানে থেকেই যায় এবং মানুষ হ্যান্ডেলটি ঘোরানোর চেষ্টা চালিয়ে যাবে। fail2ban দিয়ে বারবার লগইন করার প্রচেষ্টা ঠেকানো এই চাপের পরিমাণ নিয়ন্ত্রণ করে এবং শুধুমাত্র key-based authentication ব্যবহার করলে তারা যে পাসওয়ার্ড অনুমান করার চেষ্টা করে তা আর সম্ভব হয় না।
• এটি আপনার নিজের মেশিন থেকে আপনাকে সুরক্ষা দেয় না। আপনার ল্যাপটপে যার অ্যাক্সেস আছে, তার কাছেই আপনার private key এবং loaded agent-এর নিয়ন্ত্রণ থাকে।
• এটি আপনি যে SSH ব্যবহার করছেন তা গোপন করে না। port number এবং cleartext version banner এটি প্রকাশ করে দেয়।
• সংযোগ তৈরি হওয়ার আগে কী ঘটে, তা এটি নিয়ন্ত্রণ করে না। name lookup এবং কোন ঠিকানাকে বিশ্বাস করবেন—এই সিদ্ধান্তগুলো সংযোগের আগেই নিতে হয়।

এর পরবর্তী ধাপসমূহ

আপনার সামনে যদি কোনো প্রোভাইডার কনসোলে নতুন একটি সার্ভার খোলা থাকে, তবে কাজের একটি নির্দিষ্ট ক্রম অনুসরণ করা সুবিধাজনক। সার্ভারে প্রবেশ করুন, একটি সাধারণ ইউজার তৈরি করুন, আপনার কি (key) ইনস্টল করুন এবং তারপর সহজ প্রবেশপথগুলো বন্ধ করে দিন। নতুন VPS-এ প্রথম দশ মিনিট নিবন্ধটিতে এই ধাপগুলো শুরু থেকে শেষ পর্যন্ত বর্ণনা করা হয়েছে, এবং যদি শব্দগুলো আপনার কাছে নতুন মনে হয়, তবে VPS আসলে কী নিবন্ধটি আপনাকে সার্ভারের ভেতরের প্রযুক্তি সম্পর্কে ধারণা দেবে। এরপর, কি (keys) এবং হার্ডেনিং (hardening) সংক্রান্ত দুটি নিবন্ধ এই ক্রমানুসারে পড়ে নিন।

FAQ

SSH-এর পূর্ণরূপ কী?

SSH-এর পূর্ণরূপ হলো secure shell। এটি একটি প্রোটোকল যা দূরবর্তী কম্পিউটারে লগইন করতে এবং একটি এনক্রিপ্টেড সংযোগের মাধ্যমে কমান্ড চালাতে ব্যবহৃত হয়, যা RFC 4251 থেকে RFC 4254-এ সংজ্ঞায়িত করা হয়েছে। OpenSSH হলো সেই ইমপ্লিমেন্টেশন যা প্রায় সবাই ব্যবহার করে: আপনার মেশিনে থাকা ssh ক্লায়েন্ট এবং দূরবর্তী মেশিনে থাকা sshd সার্ভার। এটি telnet-এর স্থলাভিষিক্ত হয়েছে, যা পাসওয়ার্ডসহ সবকিছু নেটওয়ার্কে প্লেইন টেক্সটে পাঠাত।

SSH কেন 22 নম্বর পোর্ট ব্যবহার করে?

IANA 1995 সালে SSH-কে 22 নম্বর পোর্ট বরাদ্দ করে, যা 21 নম্বর পোর্টের FTP এবং 23 নম্বর পোর্টের telnet-এর পাশাপাশি ছিল—এই প্রোটোকলগুলোকেই প্রতিস্থাপন করার জন্য SSH তৈরি করা হয়েছিল। এই নম্বরটি ব্যবহার করা বাধ্যতামূলক নয়: সার্ভারে /etc/ssh/sshd_config-এর মধ্যে Port ব্যবহার করে এটি পরিবর্তন করা যায় এবং ক্লায়েন্টে ssh -p ব্যবহার করে ভিন্ন পোর্ট বেছে নেওয়া যায়। যেহেতু 22 ডিফল্ট পোর্ট, তাই স্বয়ংক্রিয় স্ক্যানারগুলো ক্রমাগত এতে নক করতে থাকে, যার কারণে একটি নতুন সার্ভারের /var/log/auth.log ফাইলটি Failed password for invalid user লাইনে ভরে যায়। পোর্ট পরিবর্তন করলে এই অনাকাঙ্ক্ষিত ট্রাফিক কমে, তবে এটি প্রকৃত কোনো নিরাপত্তা প্রদান করে না।

SSH যখন হোস্ট কি (host key) পরিবর্তনের সতর্কতা দেয়, তখন আমার কী করা উচিত?

যেকোনো কিছু মুছে ফেলার আগে কারণটি খুঁজে বের করুন। সাধারণত এর কারণ ক্ষতিকারক নয়: সার্ভারটি রিবিল্ড করা হয়েছে, তাই sshd নতুন হোস্ট কি তৈরি করেছে, অথবা পুরনো IP অ্যাড্রেসটি নতুন কোনো মেশিনকে দেওয়া হয়েছে। যদি আপনি নিশ্চিত হন যে মেশিনটি রিবিল্ড করা হয়েছে, তবে সংরক্ষিত কি মুছে ফেলতে ssh-keygen -R <host> চালান, পুনরায় সংযোগ করুন এবং আপনাকে দেখানো ফিঙ্গারপ্রিন্টটি আপনার প্রোভাইডার কনসোলে থাকা ফিঙ্গারপ্রিন্টের সাথে মিলিয়ে দেখুন। যদি আপনার দিক থেকে কোনো পরিবর্তন না হয়ে থাকে, তবে সংযোগ করবেন না এবং পাসওয়ার্ড দেবেন না। ঠিক এই কারণেই OpenSSH এই অবস্থায় পাসওয়ার্ড অথেন্টিকেশন প্রত্যাখ্যান করে।

SFTP এবং scp কি SSH থেকে আলাদা?

এগুলো SSH-এর ওপর ভিত্তি করে চলে। একবার অথেন্টিকেশন সম্পন্ন হলে, SSH সংযোগটি বেশ কয়েকটি চ্যানেল বহন করতে পারে এবং শেল তার মধ্যে একটি মাত্র। SFTP হলো একটি ফাইল ট্রান্সফার প্রোটোকল যা একই সংযোগের ওপর sshd-এর sftp সাবসিস্টেম ব্যবহার করে, এবং OpenSSH 9.0 সংস্করণ থেকে scp অভ্যন্তরীণভাবে SFTP প্রোটোকল ব্যবহার করে আসছে। পোর্ট ফরওয়ার্ডিং এবং SSH-এর মাধ্যমে Git-ও একই সংযোগের চ্যানেল। এগুলোর সবই একই পোর্ট, একই হোস্ট কি চেক এবং একই লগইন প্রক্রিয়া ব্যবহার করে। মনে রাখবেন, SFTP মানে এনক্রিপশনযুক্ত FTP নয়; এনক্রিপশনযুক্ত FTP-কে FTPS বলা হয় এবং এটি একটি সম্পূর্ণ আলাদা প্রোটোকল।

কি (key) অথেন্টিকেশন কি পাসওয়ার্ডের চেয়ে সত্যিই ভালো?

হ্যাঁ, ইন্টারনেটের মাধ্যমে অ্যাক্সেসযোগ্য যেকোনো সার্ভারের জন্য এটি ভালো। পাসওয়ার্ড হলো একটি ছোট গোপন তথ্য যা আপনি প্রতিবার লগইনের সময় সার্ভারকে প্রদান করেন, আর 22 নম্বর পোর্টে স্বয়ংক্রিয় ক্লায়েন্টরা ক্রমাগত পাসওয়ার্ড অনুমান করার চেষ্টা করে। কি পেয়ার (key pair)-এর ক্ষেত্রে, প্রাইভেট অংশটি কখনোই আপনার মেশিন ছেড়ে যায় না: ক্লায়েন্ট বর্তমান সেশনের সাথে যুক্ত ডেটাতে স্বাক্ষর (sign) করে এবং সার্ভার ~/.ssh/authorized_keys-এ থাকা পাবলিক কি-এর সাথে সেই স্বাক্ষরটি যাচাই করে। একটি রেকর্ড করা স্বাক্ষর অন্য কোনো সার্ভারে পুনরায় ব্যবহার (replay) করা সম্ভব নয়। প্রাইভেট কি-কে একটি পাসফ্রেজ দিয়ে সুরক্ষিত রাখুন, কারণ পাসফ্রেজ ছাড়া একটি কি ফাইল যে কেউ কপি করে নিলে তা দিয়ে সহজেই লগইন করা সম্ভব।