টিমের সঙ্গে নিরাপদে SSH কী ও সার্টিফিকেট শেয়ার করার উপায়

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

কিন্তু এই একটি অনুরোধ থেকেই শুরু হতে পারে গুরুতর কোনো নিরাপত্তা-ঘটনা।

SSH কী শেয়ার করা কেন বিশেষভাবে বিপজ্জনক

SSH কী সাধারণ পাসওয়ার্ডের মতো নয়। এটি দিয়ে একটি সার্ভারে সম্পূর্ণ প্রবেশাধিকার পাওয়া যায়।

বিষয়	পাসওয়ার্ড	SSH কী
পরিধি	নির্দিষ্ট একটি অ্যাকাউন্ট	পুরো সার্ভার
লিক হলে ক্ষতি	শুধু ওই অ্যাকাউন্ট	সার্ভারের সব ডেটা
রোটেশন কতটা সহজ	সঙ্গে সঙ্গে বদলানো যায়	নতুন কী তৈরি + সব সার্ভারে আপডেট
2FA সুবিধা	আছে	কী নিজেই অথেন্টিকেশন

একটি SSH কী লিক হলে সার্ভারের প্রতিটি ফাইল, প্রতিটি ডেটাবেস, কোডের প্রতিটি অংশ উন্মুক্ত হয়ে পড়ে। একটিমাত্র পাসওয়ার্ড লিকের সঙ্গে এর মৌলিক পার্থক্য এখানেই।

কখন টিমকে SSH কী শেয়ার করতে হয়

বাস্তবে শেয়ার করার বৈধ কারণও আছে।

• শেয়ার্ড সার্ভার অ্যাক্সেস: পুরো টিমের দরকার এমন স্টেজিং বা প্রোডাকশন সার্ভার
• ডিপ্লয় কী: CI/CD পাইপলাইনে ব্যবহৃত কী
• SSL সার্টিফিকেট: দায়িত্ব হাতবদল হলে সার্টিফিকেট নবায়ন
• API সিক্রেট: থার্ড-পার্টি ইন্টিগ্রেশনের অথেন্টিকেশন ক্রেডেনশিয়াল
• ডেটাবেস ক্রেডেনশিয়াল: জরুরি ইনসিডেন্ট মোকাবিলা

শেয়ার করার বিপজ্জনক পদ্ধতি

১. Slack বা Discord DM

কোনো সার্ভিসই এন্ড-টু-এন্ড এনক্রিপশন ব্যবহার করে না, আর ডিফল্টভাবে চ্যাট হিস্ট্রি তাদের সার্ভারে দীর্ঘ সময় রাখা থাকে। কথোপকথনে থাকা যে কেউ "ssh" বা "key" লিখে সার্চ করলেই আগে শেয়ার করা কী খুঁজে পেতে পারেন। কোনো কর্মী চলে গেলে তাঁর অ্যাকাউন্ট নিষ্ক্রিয় করা যায়, কিন্তু তিনি যেসব কী পেয়েছেন ও পাঠিয়েছেন সেগুলো ওয়ার্কস্পেসের হিস্ট্রিতে থেকেই যায়।

২. ইমেইল

মেইল সার্ভারে স্থায়ীভাবে আর্কাইভ হয়ে থাকে, আর একবার ফরোয়ার্ড হয়ে গেলে কোনো নিয়ন্ত্রণ থাকে না। একটিমাত্র মেইল সার্ভার বেহাত হলেই এ পর্যন্ত পাঠানো প্রতিটি কী উন্মুক্ত হয়ে যায়।

৩. শেয়ার্ড Google Drive বা Notion

সূক্ষ্মভাবে অ্যাক্সেস নিয়ন্ত্রণ করা কঠিন। ফাইল সিঙ্ক হলে ডিভাইসে লোকাল কপি থেকে যায়। কেউ টিম ছেড়ে গেলে সব কপি ফিরিয়ে নেওয়া কার্যত অসম্ভব।

৪. Git রিপোজিটরিতে কমিট করা

সবচেয়ে বিপজ্জনক পদ্ধতি। Git হিস্ট্রিতে কী চিরকাল থেকে যায়। মুছে ফেলা ফাইলও হিস্ট্রি থেকে উদ্ধার করা যায়। রিপোজিটরি পাবলিক হলে কী-টি সারা বিশ্বের সামনে উন্মুক্ত হয়ে পড়ে।

নিরাপদে শেয়ার করার পদ্ধতি

পদ্ধতি ১: LOCK.PUB গোপন মেমো (একবারের হস্তান্তরের জন্য সেরা)

একটি কী একবার পৌঁছে দিতে হলে এটিই সবচেয়ে ব্যবহারিক সমাধান।

1. Create a secret memo on LOCK.PUB
2. Paste the SSH key or certificate content
3. Set a strong password
4. Set the shortest expiration possible (1-4 hours)
5. Send the link via Slack, share the password by phone
6. After the recipient saves the key locally, the link expires

সুবিধা:

• কী-টি কোনো স্থায়ী সার্ভারে প্লেইনটেক্সট হিসেবে সংরক্ষিত হয় না
• মেয়াদ (Pro) শেষ হলে আর খোলা যায় না
• চ্যাট হিস্ট্রিতে কী-এর প্লেইনটেক্সট পড়ে থাকে না

পদ্ধতি ২: সিক্রেট ম্যানেজার (বড় টিমের জন্য)

HashiCorp Vault, AWS Secrets Manager বা Google Secret Manager-এর মতো নিবেদিত টুল ব্যবহার করুন।

• অ্যাক্সেস নিয়ন্ত্রণ ও অডিট লগ অন্তর্ভুক্ত
• স্বয়ংক্রিয় কী রোটেশন সম্ভব
• খরচ আর সেটআপের জটিলতা এর অসুবিধা

পদ্ধতি ৩: SSH সার্টিফিকেট অথরিটি (দীর্ঘমেয়াদি সমাধান)

শেয়ার করা কী-এর বদলে একটি SSH CA চালান, যা প্রত্যেক ব্যবহারকারীকে আলাদা সার্টিফিকেট ইস্যু করে।

• কী শেয়ার করার প্রয়োজনই পুরোপুরি দূর হয়
• ব্যবহারকারী-ভিত্তিক অ্যাক্সেস ব্যবস্থাপনা
• শুরুতে সেটআপের খরচ বেশি

পদ্ধতি ৪: প্রত্যেকের জন্য আলাদা কী (সবচেয়ে বেশি প্রস্তাবিত)

সম্ভব হলে পুরো টিমে একটি কী শেয়ার না করে প্রত্যেককে আলাদা কী ইস্যু করুন।

Principle: Shared key < Individual keys
Shared key leaked → Entire team affected
Individual key leaked → Only that user affected

শেয়ার করতেই হলে যে চেকলিস্ট মানবেন

প্রত্যেককে আলাদা কী দেওয়া সম্ভব না হলে এবং শেয়ার করা অনিবার্য হলে এই চেকলিস্ট মেনে চলুন।

হস্তান্তরের আগে

• কী-টির অনুমতির পরিধি কি ন্যূনতম পর্যায়ে সেট করেছেন?
• রিড-অনলি কী দিয়েই কি কাজ চলবে?
• IP সীমাবদ্ধতা প্রয়োগ করা যায় কি?

হস্তান্তরের সময়

• কী আর পাসওয়ার্ড কি আলাদা আলাদা চ্যানেলে পাঠাচ্ছেন?
• বাস্তবে যতটা কম রাখা যায়, ততটা কম মেয়াদ কি সেট করেছেন?
• প্রাপক নিশ্চিত করার পর প্রেরক কি মূল কপিটি মুছে ফেলতে পারবেন?

হস্তান্তরের পরে

• প্রাপক কী-টি নিরাপদে সংরক্ষণ করেছেন কি না, নিশ্চিত হোন
• শেয়ার করা লিংক/মেমোর মেয়াদ শেষ হয়েছে কি না, যাচাই করুন
• কী ব্যবহারের লগ নজরে রাখুন

কী রোটেশনের সময়সূচি

নিয়মিত কী রোটেট করলে কোনো কী বেহাত হলেও সেটি যত দিন কাজ করবে, সেই সময়সীমা সীমিত থাকে।

কী-এর ধরন	প্রস্তাবিত রোটেশন
প্রোডাকশন সার্ভারের কী	৯০ দিন
ডিপ্লয় কী	৯০ দিন
SSL সার্টিফিকেট	প্রতিবার নবায়নের সময়
API সিক্রেট	৯০ দিন
ডেভেলপমেন্ট/স্টেজিং কী	১৮০ দিন

DevOps টিমের জন্য নিরাপত্তা চেকলিস্ট

• সব সার্ভারে কি প্রত্যেকের আলাদা SSH কী ব্যবহার করা হয়?
• শেয়ার্ড কী থাকলে IP সীমাবদ্ধতা কনফিগার করা আছে কি?
• চাকরি ছেড়ে যাওয়া কর্মীদের কী সঙ্গে সঙ্গে নিষ্ক্রিয় করা হয় কি?
• কী রোটেশনের কোনো সময়সূচি চালু আছে কি?
• কখনো কি কোনো SSH কী Git রিপোজিটরিতে কমিট হয়েছে?
• চ্যাট হিস্ট্রিতে কি কোনো কী প্লেইনটেক্সট হিসেবে পড়ে আছে?
• গোপন তথ্য হস্তান্তরে কি এমন চ্যানেল ব্যবহার করা হয়, যার মেয়াদ ফুরিয়ে যায়?

সারাংশ

SSH কী আর সার্টিফিকেট সার্ভার নিরাপত্তার মেরুদণ্ড। এগুলো Slack DM বা ইমেইলে পাঠানো মানে বাড়ির চাবি পাবলিক নোটিশ বোর্ডে পিন দিয়ে ঝুলিয়ে রাখা। সম্ভব হলে প্রত্যেককে আলাদা কী দিন। শেয়ার করা অনিবার্য হলে যত কম সম্ভব মেয়াদের একটি গোপন মেমো ব্যবহার করুন।

নিরাপদে SSH কী পৌঁছে দিতে এখনই একটি গোপন মেমো তৈরি করুন।

গোপন মেমো তৈরি করুন