SSH key ব্যবস্থাপনার মূল বিষয়

SSH কী কীভাবে কাজ করে

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

এই গাইডটি Ubuntu 24.04-এ প্রতিটি অভ্যাস কভার করে, যদিও এখানে বর্ণিত প্রায় সবকিছুই যেকোনো Linux সার্ভার এবং যেকোনো সাম্প্রতিক OpenSSH-এর ক্ষেত্রে প্রযোজ্য।

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

একটি কী তৈরি করুন: ed25519 হলো সঠিক ডিফল্ট

নিজের কম্পিউটারে কমান্ডটি চালান, সার্ভারে নয়:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 কী-এর ধরন নির্ধারণ করে। Ed25519 হলো আধুনিক ডিফল্ট: এই কীগুলো ছোট, দ্রুত, এবং 2014 সাল থেকে প্রতিটি OpenSSH রিলিজে সমর্থিত। শুধুমাত্র তখনই ssh-keygen -t rsa -b 4096-এ ফিরে যান, যখন আপনাকে এমন কোনো পুরোনো ডিভাইসের সাথে সংযোগ করতে হবে যা ed25519 বোঝে না। -C "laptop" একটি মন্তব্য সেট করে। এই মন্তব্যের কোনো ক্রিপ্টোগ্রাফিক কাজ নেই, কিন্তু দুই বছর পর এটি দিয়েই আপনি একটি সার্ভারের authorized_keys ফাইলে এই কীটি চিনতে পারবেন। তাই যে ডিভাইসে কীটি রাখা আছে, সেই ডিভাইসের নাম দিন।

ssh-keygen জিজ্ঞাসা করে কী কোথায় সেভ করা হবে। ডিফল্ট, ~/.ssh/id_ed25519 গ্রহণ করুন। এরপর এটি একটি পাসফ্রেজ চায়। একটি সেট করুন; নিচের পাসফ্রেজ বিভাগে ব্যাখ্যা করা হয়েছে কেন দিনের পর দিন এর জন্য আপনার কোনো খরচ হয় না। আপনি দুটি ফাইল পাবেন: ~/.ssh/id_ed25519 হলো প্রাইভেট কী, এবং ~/.ssh/id_ed25519.pub হলো পাবলিক কী। পাবলিক অংশটি দেখুন:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

এটি একটি লাইন: কী-এর ধরন, কী-এর উপাদান, এবং আপনার মন্তব্য। সেই লাইনটিই আপনার সার্ভারে গিয়ে জমা হয়।

প্রতিটি ডিভাইসের জন্য একটি কী, প্রতিটি সার্ভারের জন্য নয়

সবাই প্রথমে যে প্রশ্নটি করে: আমার কি প্রতিটি সার্ভারের জন্য নতুন কী দরকার? না। আপনি যে প্রতিটি ডিভাইসে টাইপ করেন, তার জন্য একটি কী তৈরি করুন। সেই একটি পাবলিক কী প্রতিটি সার্ভারে রাখুন যেখানে ওই ডিভাইসটির পৌঁছানো দরকার। কীটি ডিভাইসটিকে চিহ্নিত করে। প্রতিটি সার্ভারের authorized_keys ফাইল হলো সেই ডিভাইসগুলোর তালিকা যাদের প্রবেশের অনুমতি আছে।

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

প্রতি ডিভাইসে একটি কী থাকলে, হারানো ল্যাপটপের খরচ হলো প্রতি সার্ভারে এক লাইন। ল্যাপটপের লাইনটি authorized_keys থেকে মুছুন। বাকি প্রতিটি ডিভাইস কাজ চালিয়ে যাবে। -C দিয়ে যে মন্তব্যটি আপনি সেট করেছেন, তা-ই সেই লাইনটিকে সহজে খুঁজে পাওয়ার সুবিধা দেয়।

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

সার্ভারে পাবলিক কী রাখুন

সহজ পথ হলো ssh-copy-id, যা OpenSSH-এর সাথে আসে:

ssh-copy-id matt@10.0.0.10

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

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

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

উদ্ধৃতিচিহ্নের ভেতরে আপনার আসল পাবলিক কী পেস্ট করুন, id_ed25519.pub থেকে পুরো একক লাইনটি। authorized_keys হলো প্রতি লাইনে একটি পাবলিক কী, এবং এটিই সম্পূর্ণ অ্যাক্সেস ডেটাবেস: একটি ডিভাইস যোগ করা মানে একটি লাইন যোগ করা, এবং একটি ডিভাইসের অ্যাক্সেস বাতিল করা মানে একটি লাইন মুছে ফেলা। একটি নতুন সার্ভারে, এই ধাপটি একটি নতুন VPS-এ প্রথম 10 মিনিট-এর অংশ, ঠিক পাসওয়ার্ড লগইন বন্ধ করার আগে।

কী লগইন ব্যর্থ করে এমন অনুমতিগুলি

কী লগইন ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ এটি, এবং ক্লায়েন্টের দিক থেকে এটি নীরবে ব্যর্থ হয়। Ubuntu 24.04-এ sshd ডিফল্টভাবে StrictModes yes সহ চলে, যার অর্থ এটি এমন একটি authorized_keys ফাইল ব্যবহার করতে অস্বীকার করে যা অন্য ব্যবহারকারীরা সম্পাদনা করতে পারে। ফাইল, ~/.ssh ডিরেক্টরি, বা আপনার হোম ডিরেক্টরি যদি আপনার বাইরে অন্য কেউ লিখতে পারে, তবে sshd আপনার কী উপেক্ষা করে এবং পাসওয়ার্ড চাইতে ফিরে যায়, ক্লায়েন্টে কোনো ব্যাখ্যা ছাড়াই। (Ubuntu-এর OpenSSH ঠিক একটি সংকীর্ণ ক্ষেত্রে সহ্য করে: একটি ফাইল আপনার নিজস্ব ব্যক্তিগত গ্রুপ দ্বারা লিখনযোগ্য, যেখানে অন্য কেউ নেই। এর উপর নির্ভর করবেন না; নিচের মোডগুলি বজায় রাখুন।) কারণটি কেবল সার্ভারের লগে দেখা যায়:

sudo grep 'Authentication refused' /var/log/auth.log

rsyslog ছাড়া একটি ন্যূনতম ইমেজে auth.log নেই; একই লাইনটি জার্নালে থাকে: sudo journalctl -u ssh | grep 'Authentication refused'।

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

সমাধান হলো দুটি অনুমতি পরিবর্তন এবং একটি মালিকানা যাচাই, সার্ভারে প্রভাবিত ব্যবহারকারী হিসেবে চালানো:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

মনে রাখার নিয়ম: .ssh ডিরেক্টরিতে 700, এবং এর ভেতরের সবকিছুতে 600। একই সংখ্যাগুলি আপনার নিজের কম্পিউটারেও প্রযোজ্য, কারণ ক্লায়েন্টও যাচাই করে। একটি ব্যক্তিগত কী যদি অন্য ব্যবহারকারীরা পড়তে পারে, তবে ssh সেই কী সরাসরি প্রত্যাখ্যান করে, এবং এবার ত্রুটিটি স্পষ্ট:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 এটি ঠিক করে।

~/.ssh/config: বারবার অপশন টাইপ করা বন্ধ করুন

আপনার নিজের কম্পিউটারে একটি ~/.ssh/config ফাইল প্রতিটি সার্ভারকে একটি ছোট নাম দেয় এবং আপনি বারবার যে অপশনগুলো টাইপ করেন সেগুলো মনে রাখে। এটি 600 পারমিশন দিয়ে তৈরি করুন এবং প্রতিটি সার্ভারের জন্য একটি Host ব্লক যোগ করুন:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

এখন ssh web1 এর জায়গায় ssh -p 22 matt@10.0.0.10 ব্যবহার করা যায়। একই ছোট নাম scp, rsync এবং git-এও কাজ করে, কারণ এগুলো সবই এই ফাইলটি পড়ে। HostName হলো আসল ঠিকানা। User আপনাকে অ্যাকাউন্টের নাম টাইপ করা থেকে বাঁচায়। আর IdentityFile নির্দিষ্ট করে দেয় কোন কী ব্যবহার করতে হবে।

IdentitiesOnly yes এর প্রসঙ্গে একটি বাক্য বলা প্রয়োজন, কারণ এটি একটি বিভ্রান্তিকর ব্যর্থতা ঠিক করে। আপনার এজেন্টে যখন একাধিক কী থাকে, তখন ক্লায়েন্ট সেগুলো একে একে অফার করে। সার্ভার প্রতিটি অফারকে একটি ব্যর্থ চেষ্টা হিসেবে গণনা করে। যথেষ্ট সংখ্যক কী লোড থাকলে সঠিক কীটি চেষ্টা করার আগেই আপনি Received disconnect: Too many authentication failures পেয়ে যান। IdentitiesOnly yes ক্লায়েন্টকে শুধুমাত্র IdentityFile-এ উল্লেখিত কীটি অফার করতে বাধ্য করে, ফলে এই ব্যর্থতা ঘটতে পারে না।

পাসফ্রেজ এবং ssh-agent

পাসফ্রেজ ডিস্কে থাকা প্রাইভেট কী ফাইল এনক্রিপ্ট করে। এটি না থাকলে, ফাইলটি কপি করা যে কেউ সাথে সাথে এটি ব্যবহার করতে পারবে; থাকলে, পাসফ্রেজ অনুমান করা না হওয়া পর্যন্ত চুরি হওয়া ফাইলটি অকেজো। ল্যাপটপের কী-র ক্ষেত্রে এটিই আপনার প্রয়োজনীয় সুরক্ষা, কারণ ল্যাপটপ চুরি হয় এবং ল্যাপটপের ব্যাকআপ ফাঁস হয়।

ব্যবহারিক ক্ষেত্রে পাসফ্রেজের কোনো খরচ নেই, এর কারণ হলো ssh-agent। এজেন্ট আপনার ডিক্রিপ্ট করা কী মেমরিতে ধরে রাখে। তাই আপনি প্রতিটি লগইন সেশনে একবার পাসফ্রেজ লিখেন এবং এর পরের প্রতিটি সংযোগ তাৎক্ষণিক হয়। বেশিরভাগ ডেস্কটপ Linux ডিস্ট্রিবিউশন এবং macOS আপনার জন্য আগে থেকেই একটি এজেন্ট চালায়। নিচের কমান্ড দিয়ে আপনার কী এজেন্টে লোড করুন:

ssh-add ~/.ssh/id_ed25519

ssh-add -l এজেন্টে বর্তমানে থাকা কী-গুলোর তালিকা দেখায়। একটি সতর্কতা: এজেন্ট ফরওয়ার্ডিং (ssh -A) আপনার সংযুক্ত থাকাকালীন রিমোট সার্ভারকে পরবর্তী প্রমাণীকরণের জন্য আপনার এজেন্ট ব্যবহার করতে দেয়। তাই এটি শুধুমাত্র সম্পূর্ণ বিশ্বস্ত সার্ভারের ক্ষেত্রে চালু করুন এবং ডিফল্টভাবে এটি বন্ধ রাখুন।

রোটেশন এবং রিভোকেশন: হারিয়ে যাওয়া ল্যাপটপের ড্রিল

একটি সাধারণ SSH key রিভোক করা মানে হলো সেটি বিদ্যমান এমন প্রতিটি server-এ authorized_keys থেকে সেই key-এর লাইনটি মুছে ফেলা। জানানোর জন্য কোনো certificate authority নেই এবং অপেক্ষা করার কোনো expiry date নেই। লাইনটি মুছে যাওয়ার সাথে সাথে সেই key দিয়ে নতুন login প্রচেষ্টা ব্যর্থ হয়।

এখনই ড্রিলটি চালান, যখন এটি কোনো জরুরি অবস্থা নয়। একটি server বেছে নিন, ~/.ssh/authorized_keys খুলুন, এবং comment দিয়ে key-টি খুঁজুন। একটি editor দিয়ে লাইনটি মুছে ফেলুন, অথবা comment অনুযায়ী ফিল্টার করে বাদ দিন:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

এরপর আপনি এইমাত্র যে ডিভাইসটি রিভোক করেছেন সেখান থেকে নিশ্চিত করুন যে এখন login ব্যর্থ হচ্ছে, এবং অন্য একটি ডিভাইস থেকে নিশ্চিত করুন যে login এখনও কাজ করছে। একটি বিষয় খেয়াল করুন: কোনো key মুছে ফেললে ইতিমধ্যে খোলা থাকা session বন্ধ হয় না, কারণ key শুধুমাত্র login-এর সময় যাচাই করা হয়। আপনি যদি কোনো চুরি হওয়া ডিভাইস রিভোক করেন, তবে server-এ who চেক করুন এবং আপনার পরিচিত নয় এমন কোনো session শেষ করুন।

Rotation হলো ভিন্ন ক্রমে একই কাজ: ডিভাইসে একটি নতুন key তৈরি করুন, সেটি ssh-copy-id দিয়ে ইনস্টল করুন, নিশ্চিত করুন যে নতুন key দিয়ে login হচ্ছে, তারপর পুরোনো লাইনটি মুছুন। যখন কোনো ডিভাইসের মালিক বদলায়, যখন কোনো key প্রকাশিত হওয়ার সম্ভাবনা থাকে, অথবা কেউ একটি টিম ছেড়ে গেলে এটি করুন। দুটি server-এ এটি নিজে করা ঠিক আছে; 20-টির ক্ষেত্রে এটি অটোমেশনের কাজ, এবং একাধিক Linux server পরিচালনা দেখায় কীভাবে একই authorized_keys অবস্থা একটি সম্পূর্ণ ফ্লিটে পুশ করতে হয়।

যা করবেন না

• সব ডিভাইসে একটি প্রাইভেট কী শেয়ার করবেন না। এতে কোনো একটি চুরি হওয়া ডিভাইসের অ্যাক্সেস বাতিল করা অসম্ভব হয়ে যায়, কারণ সব জায়গায় কী প্রতিস্থাপন করতে হয়।

• কোনো git রিপোজিটরিতে প্রাইভেট কী কমিট করবেন না, এমনকি প্রাইভেট রিপোজিটরিতেও নয়। স্বয়ংক্রিয় স্ক্যানার পাবলিক রিপোজিটরি নজরদারি করে এবং পুশ করার কয়েক মিনিটের মধ্যেই লিক হওয়া কী ব্যবহার করার চেষ্টা করে। পরে পাবলিক করা হলে রিপোজিটরির পুরো ইতিহাস লিক হয়ে যায়।

• আপনার ল্যাপটপের প্রাইভেট কী কোনো সার্ভারে আপলোড করবেন না, যাতে সেই সার্ভার অন্য সার্ভারে পৌঁছাতে পারে। সার্ভারে নিজে একটি আলাদা কী তৈরি করুন এবং সেই কী শুধুমাত্র যেখানে প্রয়োজন সেখানেই অনুমোদন করুন।

• প্রাইভেট কী চ্যাট, ইমেল বা টিকিটে পেস্ট করবেন না। পাবলিক কী, অর্থাৎ .pub ফাইল, একমাত্র অংশ যা কখনো শেয়ার করা হয়।

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

FAQ

পাসওয়ার্ড না পাঠিয়ে SSH কী কীভাবে কাজ করে?

সার্ভার আপনার পাবলিক কী ~/.ssh/authorized_keys এ সংরক্ষণ করে। লগইনের সময় সার্ভার একটি চ্যালেঞ্জ পাঠায়। আপনার ক্লায়েন্ট প্রাইভেট কী দিয়ে সেই চ্যালেঞ্জে স্বাক্ষর করে। সার্ভার পাবলিক কী দিয়ে সেই স্বাক্ষর যাচাই করে। প্রাইভেট কী কখনোই আপনার ডিভাইস থেকে বের হয় না। তাই ট্রানজিটে কিছুই আটকানোর থাকে না এবং সার্ভার থেকে চুরি করার মতো পুনরায় ব্যবহারযোগ্য কিছু থাকে না। কোনো সার্ভার ঝুঁকিতে পড়লে কেবল পাবলিক কী ফাঁস হয়। সেগুলো কোথাও লগইন করতে ব্যবহার করা যায় না।

আমার সব সার্ভারের জন্য কি একই SSH কী ব্যবহার করা উচিত?

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

.ssh ডিরেক্টরি এবং authorized_keys-এর অনুমতি কেমন হওয়া উচিত?

~/.ssh এ 700 এবং authorized_keys এ 600 সেট করুন। প্রতিটি প্রাইভেট কী-তেও এটি সেট করুন। মালিকানা থাকবে সেই অ্যাকাউন্টের যেগুলো ব্যবহার করে। sshd ডিফল্টভাবে StrictModes yes এ চলে। তাই আপনার ছাড়া অন্য কেউ ফাইল বা হোম ডিরেক্টরিতে লিখতে পারলে sshd নীরবে আপনার কী উপেক্ষা করে। একমাত্র চিহ্ন হলো সার্ভারের auth লগ বা জার্নালে Authentication refused: bad ownership or modes।

কীভাবে একটি সার্ভার থেকে SSH কী সরাব?

যে অ্যাকাউন্টের জন্য কীটি অনুমোদিত ছিল সেখানে ~/.ssh/authorized_keys থেকে কী-এর লাইনটি মুছুন। কমেন্ট দিয়ে সঠিক লাইন খুঁজুন। কমেন্ট হলো কী উপাদানের পরের লেবেল। সেই কী দিয়ে নতুন লগইন তাৎক্ষণিকভাবে ব্যর্থ হয়। তবে ইতিমধ্যে খোলা সেশনগুলো খোলাই থাকে। তাই ডিভাইসটি চুরি হলে সেই ডিভাইসের চালু সেশনগুলোও শেষ করুন। যে সব সার্ভারে কীটি কপি করা হয়েছিল সেখানে এটি পুনরাবৃত্তি করুন।

আমার SSH কী-তে কি পাসফ্রেজ প্রয়োজন?

ল্যাপটপ বা ডেস্কটপের কী-এর জন্য, হ্যাঁ। পাসফ্রেজ কী ফাইল এনক্রিপ্ট করে। তাই চুরি বা ফাঁস হওয়া কপি একা কোনো কাজে আসে না। ssh-agent মানে আপনি প্রতি সংযোগে নয়, প্রতি সেশনে একবার এটি টাইপ করেন। সার্ভারে আনঅ্যাটেন্ডেড অটোমেশনে ব্যবহৃত কী-এ সাধারণত কোনো পাসফ্রেজ থাকে না। কারণ টাইপ করার জন্য কোনো মানুষ উপস্থিত থাকে না। টার্গেট অ্যাকাউন্ট যা করতে পারে তা সীমিত করে সেগুলো সুরক্ষিত করুন।