SSH-এর ইতিহাস: Telnet থেকে OpenSSH পর্যন্ত বিবর্তন

SSH-এর ইতিহাসের সূচনা

SSH-এর ইতিহাসের সূচনা হয় চুরি হওয়া পাসওয়ার্ডের মাধ্যমে। 1995 সালের আগে, কোনো রিমোট Unix মেশিনে লগইন করার অর্থ ছিল telnet বা rlogin ব্যবহার করা, এবং উভয়ই আপনার পাসওয়ার্ড নেটওয়ার্কের মধ্য দিয়ে প্লেইন টেক্সট হিসেবে পাঠাত। যে কেউ নেটওয়ার্ক ট্রাফিক পর্যবেক্ষণ করে তা পড়ে ফেলতে পারত, এবং 1990-এর দশকের শুরুর দিকে মানুষ ঠিক সেই কাজটিই বড় পরিসরে করছিল।

SSH ছিল এই সমস্যার সমাধানে একজনের উদ্যোগ, যা 1995 সালে লেখা হয় এবং বিনামূল্যে উন্মুক্ত করে দেওয়া হয়। এরপর থেকে এই প্রোটোকলটি একবার নতুন করে তৈরি করা হয়েছে, এবং বর্তমানে প্রায় সবাই যে প্রোগ্রামটি ব্যবহার করে তা মূলত একটি ফর্কের ফর্ক। নিচের তারিখগুলো গুরুত্বপূর্ণ, কারণ প্রতিটি পদক্ষেপ ছিল একটি নির্দিষ্ট ব্যর্থতার প্রতিক্রিয়া।

Telnet এবং rlogin আসলে কী পাঠাত

Telnet-এর সংজ্ঞা দেওয়া হয়েছে RFC 854-এ, যা 1983 সালের মে মাসে Jon Postel এবং Joyce Reynolds প্রকাশ করেন। এটি TCP-এর মাধ্যমে পরিচালিত একটি টার্মিনাল সেশন বর্ণনা করে এবং এতে কোনো ধরনের এনক্রিপশন নেই। আপনার টাইপ করা প্রতিটি বাইট, এমনকি আপনার পাসওয়ার্ডও, প্লেইন টেক্সট হিসেবে পরিবাহিত হয়, যা পথের যেকোনো ডিভাইস পড়তে পারে।

rlogin এসেছে Berkeley Unix থেকে এবং পরবর্তীতে RFC 1282 (BSD Rlogin, B. Kantor, ডিসেম্বর 1991)-এ নথিভুক্ত করা হয়। এটি পাসওয়ার্ড পড়ার চেয়েও খারাপ একটি বিষয় যুক্ত করেছিল: হোস্ট-ভিত্তিক বিশ্বাস (host-based trust)। একটি সার্ভারকে এমনভাবে কনফিগার করা যেত যাতে কোনো পাসওয়ার্ড ছাড়াই নির্দিষ্ট কোনো হোস্ট থেকে লগইন গ্রহণ করা হয়। এই RFC-তে "A Cautionary Tale" নামে একটি বিভাগ আছে, যেখানে বলা হয়েছে, "বিশ্বস্ত হোস্ট থেকে পাসওয়ার্ড অথেন্টিকেশন এড়িয়ে চলা হলে, একটি সিস্টেম আক্রান্ত হলেই এই কনফিগারেশনে থাকা সমস্ত সিস্টেম ঝুঁকির মুখে পড়ে।" এতে আরও উল্লেখ করা হয়েছে যে, এই বিশ্বাস হোস্টনামের ওপর নির্ভরশীল, তাই DNS (domain name system) হ্যাক হলে বা spoofed address ব্যবহার করলে এই নিরাপত্তা ব্যবস্থা অকার্যকর হয়ে যায়।

উভয় ডিজাইনই সেই সময়ের নেটওয়ার্কের জন্য উপযুক্ত ছিল। শুরুর দিকের Ethernet ছিল একটি শেয়ারড মিডিয়াম: একটি সেগমেন্টের প্রতিটি মেশিন প্রতিটি ফ্রেম পেত এবং তাদের প্রত্যাশা ছিল যে তারা নিজেদের ঠিকানায় আসা ছাড়া অন্য ফ্রেমগুলো উপেক্ষা করবে। যে মেশিন এগুলো উপেক্ষা করা বন্ধ করত, যাকে promiscuous mode বলা হয়, সেটি অন্য সবার ট্রাফিক দেখতে পেত। এর সাথে যদি হাজার হাজার শিক্ষার্থীকে শেল অ্যাকাউন্ট দেওয়া একটি বিশ্ববিদ্যালয়ের কথা চিন্তা করেন, তবে একটি অ্যাকাউন্ট হ্যাক হওয়া মানেই পুরো বিভাগের পাসওয়ার্ড সংগ্রহকারীর হাতে চলে যাওয়া।

1994 সালের পরামর্শপত্র যাতে কোনো সমাধান ছিল না

3 ফেব্রুয়ারি 1994 সালে CERT পরামর্শপত্র CA-94:01 প্রকাশ করে, যার শিরোনাম ছিল "Ongoing Network Monitoring Attacks"। এতে জানানো হয় যে, অনুপ্রবেশকারীরা ইন্টারনেটের হাজার হাজার সিস্টেমের অ্যাক্সেস তথ্য চুরি করেছে। তারা যে টুলটি ব্যবহার করেছিল তা নেটওয়ার্ক ইন্টারফেসকে promiscuous mode-এ নিয়ে যেত এবং প্রতিটি নতুন telnet, rlogin ও FTP সেশনের শুরুর অংশ রেকর্ড করত, যেখানে ব্যবহারকারীর নাম ও পাসওয়ার্ড থাকে।

CERT প্রতিটি নেটওয়ার্ক-অ্যাক্সেসযোগ্য অ্যাকাউন্টের পাসওয়ার্ড পরিবর্তন করার পরামর্শ দেয়। প্রোটোকলগুলোর প্রেক্ষাপটে এটি বিবেচনা করলে সমস্যাটি স্পষ্ট হয়ে ওঠে: নতুন পাসওয়ার্ডটি প্রথমবার ব্যবহারের সময় একই তারের মধ্য দিয়ে প্লেইন টেক্সট বা অসংরক্ষিত অবস্থায় প্রবাহিত হয়। telnet বা rlogin-এর ভেতরে কোনো সমাধান ছিল না, কারণ এই প্রোটোকলগুলোর কোনোটিতেই নিরাপত্তা ব্যবস্থা যুক্ত করার মতো কোনো স্থান ছিল না।

হেলসিংকি-তে কেন একটি স্নিফিং অ্যাটাক SSH তৈরির কারণ হয়েছিল

1995 সালে হেলসিংকি ইউনিভার্সিটি অফ টেকনোলজির নেটওয়ার্কে একটি পাসওয়ার্ড স্নিফিং অ্যাটাক হয়, যা CERT আগে থেকেই সতর্ক করেছিল। সেখানকার একজন গবেষক Tatu Ylönen এর একটি বিকল্প তৈরি করেন এবং 1995 সালের জুলাই মাসে তা ফ্রিতে রিলিজ করেন। তিনি এর নাম দেন Secure Shell।

দুটি ডিজাইন সিদ্ধান্ত একে সফল করে তোলে। সেশনটি এনক্রিপ্ট করা ছিল, তাই নেটওয়ার্ক সেগমেন্টে আড়ি পাতা কেউ কোনো কাজের তথ্য পেত না। এছাড়া সার্ভার একটি কী (key) ব্যবহার করে নিজের পরিচয় নিশ্চিত করত, ফলে ক্লায়েন্ট বুঝতে পারত সে সঠিক মেশিনে যুক্ত হয়েছে কি না। rlogin-এর ক্ষেত্রে হোস্টনামের ওপর নির্ভরতা যে নিরাপত্তা ঝুঁকি তৈরি করত, এটি তা দূর করে।

এটি জনপ্রিয় হওয়ার আরেকটি কারণ হলো এর কমান্ডগুলো ব্যবহারকারীদের পরিচিত কমান্ডের মতোই ছিল। ssh ব্যবহার করা হতো rsh এবং rlogin-এর পরিবর্তে, আর scp ব্যবহার করা হতো rcp-এর পরিবর্তে। ফলে এটি ব্যবহারে অভ্যস্ত হতে নতুন কোনো কর্মপদ্ধতি শেখার প্রয়োজন হয়নি। 1995 সালের শেষ নাগাদ এর ব্যবহারকারীর সংখ্যা 50টি দেশে প্রায় 20,000-এ পৌঁছায়। সেই ডিসেম্বরে, Ylönen সফটওয়্যারটি উন্নয়ন ও বিক্রির জন্য SSH Communications Security প্রতিষ্ঠা করেন।

ফ্রি রিলিজ থেকে বাণিজ্যিক পণ্য

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

1999 সালে OpenBSD কেন OpenSSH ফর্ক করেছিল

1999 সালের শুরুর দিকে Björn Grönvall সেই সর্বশেষ ফ্রি রিলিজটিতে ফিরে যান এবং সেটির বাগগুলো ঠিক করতে শুরু করেন। তার সংস্করণটির নাম ছিল OSSH, এবং এটি শুধুমাত্র SSH 1.3 প্রোটোকল সমর্থন করত।

OpenBSD প্রজেক্ট OSSH গ্রহণ করে এবং সেটিকে নতুন করে তৈরি করে। প্রজেক্টের নিজস্ব ভাষ্যমতে, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell এবং Dug Song কোডটি পরিষ্কার, অডিট এবং সম্প্রসারণের কাজ করেছিলেন। এর ফলাফল ছিল OpenSSH 1.2.2, যা 1 ডিসেম্বর 1999 তারিখে OpenBSD 2.6-এর সাথে রিলিজ করা হয়।

একটি ছোট অপারেটিং সিস্টেম প্রজেক্টের করা ফর্ক কেন প্রায় প্রতিটি মেশিনে জায়গা করে নিল? কারণ OpenBSD-এর এটি থেকে নির্দিষ্ট কিছু প্রয়োজন ছিল। OpenBSD একটি অডিট করা বেস সিস্টেম সরবরাহ করে, যা ডিফল্ট কনফিগারেশনে নিরাপদ থাকার কথা। তাই এনক্রিপ্টেড রিমোট লগইন সুবিধাটিকে সেই বেস সিস্টেমের অন্তর্ভুক্ত হতে হতো, এমন একটি লাইসেন্সের অধীনে যাতে কোনো বিধিনিষেধ নেই। অডিট করা কোড এবং অবাধ লাইসেন্স—ঠিক এই জিনিসটিই অন্য সব অপারেটিং সিস্টেম ভেন্ডররাও চেয়েছিল। Damien Miller, Philip Hands এবং অন্যরা প্রায় সাথে সাথেই একটি পোর্টেবল ব্রাঞ্চ তৈরি করা শুরু করেন, আর এখান থেকেই 10.5p1-এর মতো ভার্সনের p অংশটি এসেছে। OpenBSD পরিষ্কার সংস্করণটি তৈরি করে, আর পোর্টেবল ব্রাঞ্চটি অন্য সবকিছুর জন্য প্রয়োজনীয় গ্লু (glue) বা সংযোগকারী কোড যোগ করে। Unix যেভাবে আজকের প্রচলিত সিস্টেমগুলোতে বিভক্ত হয়েছে তা থেকেই বোঝা যায় কেন এই গ্লু-এর প্রয়োজন হয়।

দ্বিতীয় প্রোটোকল ভার্সনের সাপোর্ট এরপরই আসে। 15 জুন 2000 তারিখে OpenBSD 2.7-এর সাথে OpenSSH 2.0 রিলিজ করা হয়।

কেন SSH-2 একটি নতুন প্রোটোকল এবং কেন এটি কেবল একটি ভার্সন আপডেট নয়

SSH-1 এনক্রিপ্ট করা স্ট্রিমের অখণ্ডতা রক্ষার জন্য CRC-32 ব্যবহার করত। এটি মূলত ট্রান্সমিশন ত্রুটি ধরার জন্য তৈরি একটি চেকসাম, কোনো আক্রমণকারীকে ঠেকানোর জন্য নয়। 1998 সালে CORE SDI-এর Ariel Futoransky এবং Emiliano Kargieman দেখান যে এর পরিণাম কী হতে পারে। CBC বা CFB সাইফার মোড এবং CRC-32 চেক ব্যবহার করলে, একজন আক্রমণকারী যদি প্লেইনটেক্সটের মাত্র 16 বাইটও জানে, তবে সে এমন ciphertext ইনজেক্ট করতে পারে যা রিসিভার আসল হিসেবে গ্রহণ করে। এর অর্থ হলো, আক্রমণকারী সার্ভারে কমান্ড চালাতে সক্ষম হয়।

এই ত্রুটিটি প্রোটোকলের মূলে ছিল, তাই সামঞ্জস্য বজায় রেখে এটি সংশোধন করা সম্ভব ছিল না। সফটওয়্যার নির্মাতারা এর পরিবর্তে একটি ডিটেক্টর যুক্ত করে, যা deattack.c নামক ফাইলে কোড হিসেবে থাকত এবং আক্রমণ শনাক্ত করার চেষ্টা করত। 2001 সালের ফেব্রুয়ারিতে দেখা যায় যে, এই ডিটেক্টরের নিজস্ব একটি integer overflow ত্রুটি রয়েছে, যা CVE-2001-0144 নামে পরিচিত। এটি সেই সব সার্ভার ও ক্লায়েন্টের বিরুদ্ধে রিমোট কোড এক্সিকিউশন সম্ভব করে তোলে, যারা এই প্যাচটি ব্যবহার করছিল। যে ডিজাইন মেরামত করা যায় না, তা কেবল প্যাচ সংগ্রহ করে এবং সেই প্যাচগুলো নতুন নতুন বাগ নিয়ে আসে।

SSH-2 প্রোটোকলটি IETF-এর secsh নামক ওয়ার্কিং গ্রুপে তৈরি করা হয় এবং 2006 সালের জানুয়ারিতে RFC হিসেবে প্রকাশিত হয়: RFC 4251-এ আর্কিটেকচার, RFC 4253-এ ট্রান্সপোর্ট লেয়ার, RFC 4252-এ ইউজার অথেন্টিকেশন এবং RFC 4254-এ কানেকশন লেয়ার। লেয়ারগুলোতে বিভক্ত করাটা ছিল সবচেয়ে গুরুত্বপূর্ণ অংশ, কারণ প্রতিটি লেয়ারকে আলাদাভাবে প্রতিস্থাপন করা সম্ভব। পরবর্তী ইতিহাসের বেশিরভাগ অংশই এই প্রতিস্থাপনের প্রক্রিয়া।

দুটি পরিবর্তন বিশেষভাবে উল্লেখযোগ্য। অখণ্ডতা রক্ষার জন্য CRC-32-এর পরিবর্তে HMAC (hash-based message authentication code) ব্যবহার করা হয়, যা একটি শেয়ারড সিক্রেট দিয়ে কি (key) করা থাকে। ফলে যে আক্রমণকারী MAC গণনা করতে পারে না, সে কোনো প্যাকেট জাল করতে পারবে না। এছাড়া কি এগ্রিমেন্টের জন্য Diffie-Hellman পদ্ধতি গ্রহণ করা হয়। SSH-1-এ ক্লায়েন্ট সেশন কি নির্বাচন করত এবং তা সার্ভারের RSA কি দিয়ে এনক্রিপ্ট করে পাঠাত। ফলে কেউ যদি পরবর্তীতে সেই প্রাইভেট কিগুলো পেয়ে যেত, তবে সে রেকর্ড করা সেশন ডিক্রিপ্ট করতে পারত। Diffie-Hellman প্রতিটি সেশনের জন্য একটি নতুন সিক্রেট তৈরি করে যা কখনোই নেটওয়ার্কে পাঠানো হয় না। ফলে এখন ট্রাফিক রেকর্ড করে পরে হোস্ট কি চুরি করলেও কোনো লাভ হয় না। এই বৈশিষ্ট্যটিকে বলা হয় forward secrecy।

SSH-2-এর সাথে SSH-1-এর কোনো ওয়্যার কম্প্যাটিবিলিটি নেই। এই কারণেই ভার্সন নম্বরটি দশমিকের পরিবর্তে পূর্ণসংখ্যায় পরিবর্তন করা হয়েছে।

কেন SSH-1 মেরামত না করে অপসারণ করা হয়েছিল

তিনটি OpenSSH releases জুড়ে এই অপসারণ প্রক্রিয়া সম্পন্ন হয়েছে। 11 আগস্ট 2015-এ মুক্তি পাওয়া 7.0 সংস্করণে কম্পাইল করার সময় ডিফল্টভাবে protocol 1 নিষ্ক্রিয় করা হয়। 19 ডিসেম্বর 2016-এ মুক্তি পাওয়া 7.4 সংস্করণে এর সার্ভার সাপোর্ট সরিয়ে ফেলা হয়। 3 অক্টোবর 2017-এ মুক্তি পাওয়া 7.6 সংস্করণে ক্লায়েন্ট সাইড, এর কনফিগারেশন অপশন এবং ডকুমেন্টেশনসহ সবকিছু মুছে ফেলা হয়।

পুরানো সরঞ্জামের জন্য এটিকে একটি অপশন হিসেবে রেখে দেওয়াটা ব্যবহারকারীদের জন্য সহজ হতো, কিন্তু CRC-32 ডিটেক্টর ব্যাখ্যা করে কেন সেই সিদ্ধান্ত প্রত্যাখ্যান করা হয়েছিল। overflow-টি শুধুমাত্র তখনই পৌঁছানো সম্ভব ছিল যখন protocol 1 কোডটি কম্পাইল করা থাকত, এবং এটি এমন একটি পথে ছিল যা অধিকাংশ অ্যাডমিনিস্ট্রেটর তাদের সিস্টেমে নিষ্ক্রিয় বলে মনে করতেন। যে কোডটি সিস্টেমে থাকে (ships), তা আক্রমণ করা সম্ভব। যে কোডটি মুছে ফেলা হয়েছে, তা আক্রমণ করা অসম্ভব।

কেন প্রথম SSH সংযোগের সময় হোস্ট কি (host key) নিয়ে সতর্কবার্তা দেওয়া হয়

এনক্রিপশন নিশ্চিত করে যে আপনার ট্রাফিক গোপন থাকছে, কিন্তু এটি নিশ্চিত করে না যে অপর প্রান্তে কে আছে। যদি কোনো আক্রমণকারী আপনার এবং সার্ভারের মাঝখানে অবস্থান করে এবং সার্ভারের পরিবর্তে সাড়া দেয়, তবে আপনি আক্রমণকারীর সাথেই একটি নিখুঁত এনক্রিপ্টেড সেশন তৈরি করবেন, যাকে machine-in-the-middle আক্রমণ বলা হয়। SSH এর সমাধান হিসেবে হোস্ট কি (host key) ব্যবহার করে: সার্ভার প্রমাণ করে যে তার কাছে একটি কি-পেয়ারের প্রাইভেট অংশটি আছে এবং ক্লায়েন্ট সেই কি-টিকে তার আগের রেকর্ড করা কি-এর সাথে মিলিয়ে দেখে। আপনি যদি সংযোগের অভ্যন্তরীণ প্রক্রিয়া সম্পর্কে জানতে চান, তবে SSH সংযোগ খোলার সময় কী ঘটে দেখুন।

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

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

yes উত্তর দিলে সেই কি-টি ~/.ssh/known_hosts-এ সংরক্ষিত হয়। পরবর্তী প্রতিটি সংযোগে সংরক্ষিত মানের সাথে তুলনা করা হয় এবং কোনো অমিল পাওয়া গেলে প্রোগ্রামটি তার সবচেয়ে জোরালো সতর্কবার্তা প্রদর্শন করে:

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

প্রথম প্রম্পটটির প্রকৃত অর্থ হলো, প্রোটোকলটি তার একটি দুর্বল মুহূর্ত স্বীকার করছে। Trust on first use বা প্রথম ব্যবহারের ওপর নির্ভরতার অর্থ হলো, প্রথম সংযোগটি ঠিক ততটাই নিরাপদ যতটা নিরাপদ সেই নেটওয়ার্কটি যার মাধ্যমে আপনি সংযোগ করছেন। আপনি এই ঝুঁকি কমাতে পারেন। সংযোগ করার আগে আপনার প্রোভাইডারের কনসোল বা সার্ভারের বিল্ড লগ থেকে ফিঙ্গারপ্রিন্টটি দেখে নিন। এটিকে DNS-এ SSHFP রেকর্ড (RFC 4255) হিসেবে প্রকাশ করুন, তবে এটি কেবল তখনই কার্যকর যদি আপনার DNSSEC থাকে। অথবা আপনার নিজস্ব সার্টিফিকেট অথরিটি (CA) দিয়ে হোস্ট কি সাইন করুন, যাতে ক্লায়েন্টরা প্রতিটি আলাদা কি-এর পরিবর্তে CA-কে বিশ্বাস করে। বাস্তবে অধিকাংশ মানুষ যাচাই না করেই প্রম্পটটি গ্রহণ করে, যা স্বীকার করে নেওয়া ভালো।

কিভাবে পাবলিক কি পাসওয়ার্ডের বিকল্প হয়ে উঠল

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

দ্বিতীয় কারণটি গাণিতিক। পাবলিক অ্যাড্রেসে port 22 খোলা আছে এমন যেকোনো সার্ভারে দিনরাত স্বয়ংক্রিয় লগইন প্রচেষ্টার শিকার হতে হয়, আর পাসওয়ার্ড হলো অনুমানযোগ্য একটি স্ট্রিং। একটি কি ব্যবহারিক অর্থে অনুমান করা অসম্ভব। PasswordAuthentication no সেট করা এই ধরনের সব আক্রমণ বন্ধ করে দেয়, আর এই কারণেই এটি প্রতিটি হার্ডেনিং চেকলিস্টে থাকে। কি জেনারেট এবং রোটেশন করার পদ্ধতি SSH key management basics-এ এবং সার্ভার সাইড সেটিংস hardening SSH on a VPS-এ আলোচনা করা হয়েছে।

কেন SSH অ্যালগরিদমের তালিকা ক্রমাগত পরিবর্তিত হয়

একটি লেয়ারড প্রোটোকল নতুন প্রোটোকল ছাড়াই পুরনো অ্যালগরিদমগুলোকে অবসরে পাঠানোর সুযোগ দেয়। OpenSSH নিয়মিতভাবে এই স্বাধীনতা ব্যবহার করে আসছে এবং এর রিলিজের তারিখগুলো সেই পরিবর্তনের গতি নির্দেশ করে।

Ed25519 2014 সালের 30 জানুয়ারি OpenSSH 6.5-এ যুক্ত হয়। এর সাথে chacha20-poly1305 সাইফার এবং bcrypt দ্বারা সুরক্ষিত প্রাইভেট কি ফরম্যাটও আসে। Ed25519 সিগনেচারগুলো প্রতিটি সিগনেচারের জন্য ডিটারমিনিস্টিক উপায়ে ননস (nonce) তৈরি করে। ফলে সাইন করার সময় দুর্বল র‍্যান্ডম নম্বর জেনারেটর ব্যবহার করলেও প্রাইভেট কি ফাঁস হওয়ার ঝুঁকি থাকে না। বাস্তবে DSA এবং ECDSA প্রাইভেট কিগুলো ঠিক এই কারণেই ফাঁস হয়েছিল।

DSA-এর ক্ষেত্রে উল্টো ঘটনা ঘটেছে। 2015 সালে OpenSSH 7.0 রান-টাইমে ssh-dss হোস্ট এবং ইউজার কিগুলোকে নিষ্ক্রিয় করে দেয়, কারণ এই অ্যালগরিদমটি 160-বিট প্রাইভেট কি এবং SHA-1 এর মধ্যে সীমাবদ্ধ। 2024 সালের 1 জুলাই 9.8 ভার্সনে DSA-কে কম্পাইল-টাইমে নিষ্ক্রিয় করা হয়। 2025 সালের 9 এপ্রিল 10.0 ভার্সনে এটিকে পুরোপুরি সরিয়ে ফেলা হয়, যা প্রকল্পের ভাষায় "2015 সালে শুরু হওয়া অবলুপ্তির প্রক্রিয়া সম্পন্ন করে"। নিষ্ক্রিয় করা থেকে মুছে ফেলা পর্যন্ত সময় লেগেছে দশ বছর।

RSA হারিয়ে যায়নি, তবে এর পুরনো সিগনেচার ফরম্যাটটি বিলুপ্ত হয়েছে। 2021 সালের 26 সেপ্টেম্বর OpenSSH 8.8 ডিফল্টভাবে SHA-1 ব্যবহার করে তৈরি RSA সিগনেচার গ্রহণ করা বন্ধ করে দেয়। রিলিজ নোটে এর কারণ স্পষ্টভাবে উল্লেখ করা হয়েছে: SHA-1 ক্রিপ্টোগ্রাফিকভাবে দুর্বল এবং 50,000 ডলারের কম খরচে এতে চোজেন-প্রিফিক্স কলিশন তৈরি করা সম্ভব। পুরনো কোনো সার্ভারে কানেক্ট করার সময় যদি আপনি কখনো sign_and_send_pubkey: no mutual signature supported এর সম্মুখীন হয়ে থাকেন, তবে সেটি এই পরিবর্তনের কারণেই হয়েছে। আপনার কি (key) ঠিক আছে, কিন্তু অপর প্রান্ত যে সিগনেচার অ্যালগরিদমটি চেয়েছে তা আর গ্রহণযোগ্য নয়।

একই প্রক্রিয়া এখন কি এক্সচেঞ্জের ক্ষেত্রেও চলছে, তবে এবার হুমকির আগেই ব্যবস্থা নেওয়া হচ্ছে। বর্তমানে ক্যাপচার করা ট্রাফিক সংরক্ষণ করে রাখা সম্ভব এবং ভবিষ্যতে শক্তিশালী কোয়ান্টাম কম্পিউটার থাকলে তা ডিক্রিপ্ট করা যেতে পারে। তাই এমন মেশিন আসার আগেই কি এগ্রিমেন্ট পদ্ধতি পরিবর্তন করা জরুরি ছিল। 2022 সালের 8 এপ্রিল OpenSSH 9.0 হাইব্রিড কি এক্সচেঞ্জকে ডিফল্ট করে: sntrup761x25519-sha512@openssh.com একটি পোস্ট-কোয়ান্টাম অ্যালগরিদমের সাথে X25519 এক্সচেঞ্জকে যুক্ত করে। ফলে নতুন অ্যালগরিদমটি যদি আশানুরূপ কাজ না-ও করে, তবুও এর নিরাপত্তা ক্লাসিক্যাল অংশের চেয়ে কম হয় না। 2024 সালের 19 সেপ্টেম্বর OpenSSH 9.9-এ mlkem768x25519-sha256 যুক্ত করা হয়, যা 2024 সালে NIST কর্তৃক স্ট্যান্ডার্ডাইজ করা ML-KEM (মডিউল ল্যাটিস কি এনক্যাপসুলেশন মেকানিজম)-এর ওপর ভিত্তি করে তৈরি। OpenSSH 10.0 এটিকে কি এগ্রিমেন্টের জন্য ডিফল্ট হিসেবে নির্ধারণ করে এবং প্রকল্পের পোস্ট-কোয়ান্টাম পেজ-এ এর কারণ ব্যাখ্যা করা হয়েছে। 2025 সালের 6 অক্টোবর OpenSSH 10.1-এ অপর প্রান্ত যদি এটি সমর্থন না করে তবে সতর্কবার্তা দেখানো শুরু হয়:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

এই সতর্কবার্তাটি ডিফল্টভাবে চালু থাকে এবং এটি ssh_config-এর WarnWeakCrypto অপশন দ্বারা নিয়ন্ত্রিত হয়। বাস্তবে এর অর্থ কী এবং কোনো সার্ভারে এটি দেখা দিলে কী করতে হবে, তা পোস্ট-কোয়ান্টাম SSH কি এক্সচেঞ্জ ডিফল্ট অংশে আলোচনা করা হয়েছে।

আপনার সামনে থাকা সার্ভারের জন্য এই ইতিহাসের তাৎপর্য

আপনি যে কমান্ডটি টাইপ করেন তা 1995 সাল থেকে খুব একটা পরিবর্তিত হয়নি। এর নিচের প্রায় সবকিছুই প্রতিস্থাপিত হয়েছে: ইন্টিগ্রিটি চেক, কি এক্সচেঞ্জ, সিগনেচার অ্যালগরিদম এবং কোডবেস নিজেই। এটি কেবল তখনই সম্ভব হয়েছে কারণ প্রতিটি প্রতিস্থাপনের শেষে ইচ্ছাকৃতভাবে পুরোনো অংশ অপসারণ করা হয়েছে, এবং প্রতিটি অপসারণই কারো না কারো জন্য কোনো না কোনো সমস্যা তৈরি করেছে।

তাই আপনার SSH নিরাপত্তা মূলত আপনার ভার্সনের ওপর নির্ভর করে। ডিফল্ট সেটিংসগুলো নির্ধারণ করে কোন অ্যালগরিদমগুলো অফার করা হবে, কোনগুলো প্রত্যাখ্যান করা হবে এবং আপনি কী কী সতর্কতা দেখতে পাবেন। একটি পুরোনো সার্ভার তার রিলিজের সময় অনুমোদিত সবকিছুই অফার করতে থাকে এবং এটি একটি পুরোনো ক্লায়েন্টের সাথে মানিয়ে নিতে ক্রমাগত নেগোশিয়েশন বা সমঝোতা করতে থাকে। আগস্ট 2026 পর্যন্ত বর্তমান রিলিজ হলো OpenSSH 10.5, যা 11 আগস্ট 2026-এ প্রকাশিত হয়েছে। তিন বছর ধরে কেউ স্পর্শ করেনি এমন একটি মেশিনের ভার্সন এবং বর্তমান ভার্সনের মধ্যে যে পার্থক্য, সেটিই হলো সমস্যার পরিধি। এটি পরীক্ষা করা একটি নতুন VPS-এ প্রথম দশ মিনিটের কাজের অন্তর্ভুক্ত।

FAQ

SSH কে তৈরি করেছিলেন এবং কেন?

হেলসিংকি ইউনিভার্সিটি অফ টেকনোলজির গবেষক Tatu Ylönen 1995 সালে SSH তৈরি করেন। বিশ্ববিদ্যালয়ের নেটওয়ার্কে পাসওয়ার্ড স্নুপিং আক্রমণের পর তিনি এটি তৈরি করেন। তৎকালীন রিমোট লগইন টুল telnet এবং rlogin নেটওয়ার্কের মধ্য দিয়ে পাসওয়ার্ড প্লেইন টেক্সট হিসেবে পাঠাত। ফলে নেটওয়ার্কের কোনো অংশে নজরদারি করলে সহজেই ক্রেডেনশিয়াল চুরি করা যেত। 1995 সালের জুলাই মাসে তিনি এটি ফ্রিতে প্রকাশ করেন। সেই বছরের শেষ নাগাদ 50টি দেশে এর প্রায় 20,000 ব্যবহারকারী ছিল এবং 1995 সালের ডিসেম্বরে তিনি SSH Communications Security প্রতিষ্ঠা করেন।

SSH-1 এবং SSH-2 এর মধ্যে পার্থক্য কী?

এগুলো দুটি ভিন্ন প্রোটোকল এবং এদের মধ্যে কোনো সামঞ্জস্য নেই। SSH-1 একটি মনোলিথিক প্রোটোকল ছিল যা ইন্টিগ্রিটির জন্য CRC-32 ব্যবহার করত এবং সার্ভারের RSA কি (key) দিয়ে এনক্রিপ্ট করা সেশন কি ক্লায়েন্ট পাঠাত। SSH-2 কাজটিকে ট্রান্সপোর্ট লেয়ার, অথেনটিকেশন লেয়ার এবং কানেকশন লেয়ারে (RFC 4251 থেকে 4254, জানুয়ারি 2006) বিভক্ত করে। এটি ইন্টিগ্রিটির জন্য HMAC ব্যবহার করে এবং Diffie-Hellman এর মাধ্যমে সেশন কি তৈরি করে। ফলে পরবর্তীতে হোস্ট কি চুরি হলেও রেকর্ড করা ট্রাফিক গোপন থাকে। OpenSSH থেকে SSH-1 পর্যায়ক্রমে বাদ দেওয়া হয় এবং 2017 সালের অক্টোবরে সংস্করণ 7.6 এর মাধ্যমে এটি পুরোপুরি বন্ধ হয়ে যায়।

কেন OpenSSH মূল SSH ইমপ্লিমেন্টেশনকে প্রতিস্থাপন করল?

মূল SSH-এর উন্নয়ন একটি বাণিজ্যিক পণ্যে পরিণত হয় যার লাইসেন্স ছিল সীমাবদ্ধ। সর্বশেষ অবাধে ব্যবহারযোগ্য রিলিজ ছিল ssh 1.2.12। 1999 সালের শুরুতে Björn Grönvall সেই রিলিজটিকে OSSH হিসেবে পুনরুজ্জীবিত করেন। এরপর OpenBSD টিম OSSH থেকে OpenSSH তৈরি করে, যা 1 ডিসেম্বর 1999 সালে OpenBSD 2.6 এর সাথে মুক্তি পায়। OpenBSD-এর বেস সিস্টেমের জন্য একটি অবাধ লাইসেন্সযুক্ত এবং অডিট করা কোড প্রয়োজন ছিল। এই দুটি বৈশিষ্ট্যের কারণেই অন্য সব অপারেটিং সিস্টেম পোর্টেবল ব্রাঞ্চের মাধ্যমে একই ইমপ্লিমেন্টেশন ব্যবহার করতে পারে।

প্রথমবার কানেক্ট করার সময় SSH কেন হোস্ট কি (host key) সম্পর্কে জিজ্ঞাসা করে?

কারণ ক্লায়েন্ট এর আগে কখনো সেই সার্ভারটি দেখেনি এবং তুলনা করার মতো কোনো কি (key) তার কাছে নেই। শুধুমাত্র এনক্রিপশন দিয়ে একটি সৎ সার্ভার এবং মাঝপথে থাকা কোনো ক্ষতিকারক মেশিনের মধ্যে পার্থক্য করা সম্ভব নয়। তাই SSH কি (key) দিয়ে সার্ভার শনাক্ত করে এবং যা দেখে তা ~/.ssh/known_hosts-এ রেকর্ড করে। প্রথম কানেকশনের সময় চেক করার মতো কোনো সংরক্ষিত মান থাকে না, তাই ক্লায়েন্ট আপনাকে জিজ্ঞাসা করে। প্রোভাইডার কনসোল বা সার্ভার থেকে প্রাপ্ত ফিঙ্গারপ্রিন্টের সাথে এটি মিলিয়ে দেখুন। পরবর্তীতে কোনো REMOTE HOST IDENTIFICATION HAS CHANGED বার্তা দেখলে সেটিকে একটি বাস্তব ঘটনা হিসেবে বিবেচনা করুন যতক্ষণ না আপনি এর কারণ ব্যাখ্যা করতে পারছেন।

আপগ্রেডের পর পুরনো SSH কি (key) কেন কাজ করা বন্ধ করে দেয়?

কারণ OpenSSH একটি নির্ধারিত সময়সূচী অনুযায়ী পুরনো অ্যালগরিদমগুলো বাদ দেয়। DSA (ssh-dss) কি (key) 2015 সালে OpenSSH 7.0-এ ডিফল্টভাবে নিষ্ক্রিয় করা হয় এবং 9 এপ্রিল 2025 সালে OpenSSH 10.0 থেকে পুরোপুরি সরিয়ে ফেলা হয়। RSA কি (key) এখনো কাজ করে, তবে SHA-1 দিয়ে তৈরি সিগনেচার 2021 সালের সেপ্টেম্বরে OpenSSH 8.8-এ ডিফল্টভাবে নিষ্ক্রিয় করা হয়েছে। পুরনো সার্ভারে কানেক্ট করার সময় এটি sign_and_send_pubkey: no mutual signature supported হিসেবে দেখা দেয়। 2014 সালের জানুয়ারি থেকে OpenSSH 6.5-এ উপলব্ধ Ed25519 কি (key) ব্যবহার করলে এই সমস্যাগুলো এড়ানো যায়।