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 সালের শেষ নাগাদ এর ব্যবহারকারীর সংখ্যা পঞ্চাশটি দেশে প্রায় 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 বাইটও জানে, তবে সে এমন সাইফারটেক্সট ইনজেক্ট করতে পারে যা রিসিভার আসল হিসেবে গ্রহণ করে। এর অর্থ হলো, আক্রমণকারী সার্ভারে কমান্ড চালাতে সক্ষম হয়।

এই ত্রুটিটি প্রোটোকলের নকশাতেই ছিল, তাই সামঞ্জস্যতা বজায় রেখে এটি সংশোধন করা সম্ভব ছিল না। সফটওয়্যার নির্মাতারা এর পরিবর্তে একটি ডিটেক্টর যুক্ত করে, যা 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 জুড়ে এই অপসারণ প্রক্রিয়া সম্পন্ন হয়েছে। 2015 সালের 11 আগস্ট 7.0 সংস্করণে কম্পাইল করার সময় ডিফল্টভাবে প্রোটোকল 1 নিষ্ক্রিয় করা হয়। 2016 সালের 19 ডিসেম্বর 7.4 সংস্করণে সার্ভার সাইড থেকে এর সমর্থন সরিয়ে ফেলা হয়। 2017 সালের 3 অক্টোবর 7.6 সংস্করণে ক্লায়েন্ট সাইড, এর কনফিগারেশন অপশন এবং ডকুমেন্টেশনসহ সবকিছু মুছে ফেলা হয়।

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

কেন আপনার প্রথম 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-এর শুরুর দিকের রিলিজগুলো থেকেই পাবলিক কি অথেন্টিকেশন ছিল, কিন্তু এটি সাধারণ অভ্যাসে পরিণত হতে কয়েক বছর সময় লেগেছে। এই মেকানিজমটি অপ্রতিসম (asymmetric): ক্লায়েন্ট একটি চ্যালেঞ্জ সাইন করার মাধ্যমে প্রমাণ করে যে তার কাছে প্রাইভেট কি আছে, এবং প্রাইভেট কি কখনোই ক্লায়েন্ট মেশিন ছেড়ে যায় না। পাসওয়ার্ড ঠিক এর উল্টো কাজ করে। যদিও SSH এনক্রিপ্টেড চ্যানেলের ভেতরে পাসওয়ার্ড বহন করে, তবুও সার্ভার প্রকৃত সিক্রেটটি পেয়ে যায়। ফলে কোনো সার্ভার কম্প্রোমাইজড হলে বা ক্ষতিকারক হলে, সেটি আপনার পাসওয়ার্ডটি অন্য কোথাও ব্যবহারের জন্য সংগ্রহ করে রাখতে পারে।

দ্বিতীয় কারণটি হলো হিসাব। Public address-এ port 22 খোলা থাকা যেকোনো সার্ভারে সারাক্ষণ স্বয়ংক্রিয় login attempt আসে, আর password হলো অনুমান করা যায় এমন একটি string। Key-কে বাস্তবে অনুমান করা যায় না। PasswordAuthentication no সেট করলে এই ধরনের আক্রমণের পুরো শ্রেণিটি বন্ধ হয়। তাই এটি প্রতিটি hardening checklist-এ থাকে। এর ফলে আগে key-এ সমস্যা হলে যে fallback আপনাকে উদ্ধার করত, সেটিও আর থাকে না। তাই আপনি নিজেই lock out হওয়ার আগে Permission denied (publickey) বার্তা দেওয়া একই ধরনের একাধিক ত্রুটি আলাদা করে শনাক্ত করতে শিখুন। Password ছাড়া কাজ করার অর্থ হলো ধীরে ধীরে একাধিক key জমা হওয়া। এক ডজন key ধারণকারী একটি agent সেগুলো একে একে server-এ পাঠায়। Server তার attempt limit-এ পৌঁছে connection বন্ধ করে দিতে পারে। সঠিক key loaded থাকা সত্ত্বেও login কেন Too many authentication failures বার্তায় ব্যর্থ হতে পারে, তার কারণ এখানে ব্যাখ্যা করা হয়েছে। Key তৈরি ও rotation-এর পদ্ধতি SSH key management-এর প্রাথমিক বিষয়গুলো-তে রয়েছে। Server-side settings রয়েছে VPS-এ SSH hardening করা-তে।

কেন 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 USD-এর কম খরচে এতে চোজেন-প্রিফিক্স কলিশন তৈরি করা সম্ভব। পুরনো কোনো সার্ভারে কানেক্ট করার সময় যদি আপনি কখনো sign_and_send_pubkey: no mutual signature supported এর সম্মুখীন হয়ে থাকেন, তবে সেটি এই পরিবর্তনের কারণেই হয়েছে। আপনার কি ঠিক আছে, কিন্তু অপর প্রান্ত যে সিগনেচার অ্যালগরিদমটি চেয়েছে তা আর গ্রহণযোগ্য নয়।

একই প্রক্রিয়া এখন কি এক্সচেঞ্জের ক্ষেত্রেও চলছে, তবে এবার হুমকির আগেই ব্যবস্থা নেওয়া হচ্ছে। বর্তমানে ক্যাপচার করা ট্রাফিক সংরক্ষণ করে রাখা সম্ভব এবং ভবিষ্যতে শক্তিশালী কোয়ান্টাম কম্পিউটার থাকলে তা ডিক্রিপ্ট করা যেতে পারে। তাই এমন মেশিন আসার আগেই কি এগ্রিমেন্ট পরিবর্তন করা জরুরি ছিল। 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 এর মাধ্যমে সেশন কি তৈরি করে, ফলে পরবর্তীতে হোস্ট কি চুরি হলেও রেকর্ড করা ট্রাফিক গোপন থাকে। SSH-1 পর্যায়ক্রমে OpenSSH থেকে সরিয়ে ফেলা হয় এবং 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 কি-এর মাধ্যমে সার্ভার শনাক্ত করে এবং যা দেখে তা ~/.ssh/known_hosts-এ রেকর্ড করে। প্রথম কানেকশনের সময় কোনো সংরক্ষিত ভ্যালু না থাকায় ক্লায়েন্ট আপনাকে জিজ্ঞাসা করে। প্রোভাইডার কনসোল বা সার্ভার থেকে পাওয়া ফিঙ্গারপ্রিন্টের সাথে এটি মিলিয়ে দেখুন এবং পরবর্তীতে কোনো REMOTE HOST IDENTIFICATION HAS CHANGED মেসেজ আসলে সেটিকে একটি বাস্তব ঘটনা হিসেবে বিবেচনা করুন যতক্ষণ না আপনি এর কারণ ব্যাখ্যা করতে পারছেন।

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

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