SSH ProxyCommand এবং হোস্ট-ভিত্তিক প্রমাণীকরণ: কোন হোস্ট সই করে?

টার্গেট বাস্টিয়ন থেকে আসা একটি TCP সংযোগ দেখতে পায়, অথচ প্রমাণীকরণ করা SSH ক্লায়েন্ট এখনও ওয়ার্কস্টেশনে চলে।

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

এখানে সহায়কটি বাস্টিয়নে লগইন করে এবং তার SSH সার্ভারকে টার্গেটে একটি অগ্রাহৃত সংযোগ দিতে বলে। ওয়ার্কস্টেশনের বাইরের SSH ক্লায়েন্ট সেই স্ট্রিমের মধ্য দিয়ে টার্গেটের SSH প্রোটোকল বিনিময় করে। বাস্টিয়ন পরিবহন যোগায়; এটি টার্গেটের দিকে SSH ক্লায়েন্ট চালু করেনি।

হোস্ট-ভিত্তিক প্রমাণীকরণে এই পার্থক্যটি গুরুত্বপূর্ণ। OpenSSH-এর ssh-keysign সহায়ক প্রয়োজনীয় স্বাক্ষর তৈরি করতে স্থানীয় হোস্ট কী-তে পৌঁছায়। বাস্টিয়নের নেটওয়ার্ক উৎস ঠিকানা হওয়া ওয়ার্কস্টেশনকে বাস্টিয়নের হোস্ট কী দিয়ে সই করতে বাধ্য করে না।

এটির সঙ্গে তুলনা করুন:

ssh -t bastion ssh target

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

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