SSH کیا ہے اور یہ کیسے کام کرتا ہے؟

SSH کیا ہے؟

SSH (secure shell) ایک protocol ہے جس کے ذریعے کسی دوسرے مقام پر موجود computer میں login کیا جاتا ہے اور encrypted connection کے ذریعے اس پر commands چلائی جاتی ہیں۔ آپ جو کچھ type کرتے ہیں وہ remote machine کو بھیجا جاتا ہے، اس کا output واپس آتا ہے، اور درمیان میں network traffic monitor کرنے والا کوئی شخص دونوں کو پڑھ نہیں سکتا۔ rented Linux server کے ساتھ screen اور keyboard منسلک نہیں ہوتے، اس لیے machine استعمال کرنے کا بنیادی طریقہ SSH ہی ہے۔

یہ نام دو چیزوں کے لیے استعمال ہوتا ہے۔ SSH وہ protocol ہے جس کی وضاحت RFC 4251 سے RFC 4254 تک میں کی گئی ہے۔ OpenSSH وہ program ہے جو اسے implement کرتا ہے، اور تقریباً ہر Linux server اور تقریباً ہر laptop پر حقیقتاً یہی چل رہا ہوتا ہے۔ جب کوئی کہتا ہے کہ "SSH کے ذریعے server میں داخل ہوں"، تو اس کا مطلب ہوتا ہے کہ اس کی machine پر موجود client program ssh دوسری طرف موجود server program sshd سے رابطہ کر رہا ہے۔

SSH کو جس مسئلے کے حل کے لیے بنایا گیا تھا

Remote login، SSH سے بہت پہلے موجود تھا۔ Telnet نے port 23 سے ایک plain TCP connection قائم کیا اور ہر byte کو عین اسی طرح بھیجا جیسے اسے ٹائپ کیا گیا تھا۔ کچھ بھی encrypted نہیں تھا، اور اس میں آپ کا password بھی شامل تھا۔ جو شخص network traffic دیکھ سکتا تھا، وہ اسے پڑھ سکتا تھا: خواہ وہ اسی office network پر موجود شخص ہو یا راستے میں موجود کسی router کا operator۔ rlogin family میں بھی یہی کمزوری تھی۔ وہ client machine پر اس کے نام کی بنیاد پر اعتماد کرتی تھی، یعنی network نام کے بارے میں جو کچھ بتائے، اسی پر اعتماد کرتی تھی۔

Tatu Ylönen نے university network پر password sniffing attack کے بعد 1995 میں Helsinki University of Technology میں پہلا SSH لکھا۔ اس design میں Telnet کا مفید حصہ، یعنی آپ کے terminal اور remote shell کے درمیان byte stream، برقرار رکھا گیا۔ اس کے ساتھ وہ دو صلاحیتیں شامل کی گئیں جن کا Telnet میں کوئی حل نہیں تھا: stream کی encryption، اور یہ ثبوت کہ دوسرے سرے پر موجود server وہی ہے جس تک آپ پہنچنا چاہتے تھے۔

اس دوسرے حصے کو آسانی سے نظرانداز کیا جا سکتا ہے، حالانکہ SSH کی بنیادی خصوصیات میں سے آدھی اسی پر مشتمل ہے۔ صرف encryption آپ کو محفوظ نہیں رکھتی۔ درمیان میں موجود machine آپ کا connection قبول کر سکتی ہے، اسے مکمل طور پر encrypt کر سکتی ہے، آپ کی بھیجی ہوئی ہر چیز پڑھ سکتی ہے، اور اسے اصل server تک پہنچا سکتی ہے۔ SSH ہر server کو ایک مستقل شناخت دے کر اس حملے کو روکتا ہے۔ اسے host key کہا جاتا ہے، اور SSH ہر connection پر اس کی جانچ کرتا ہے۔

کلائنٹ اور سرور ماڈل کیسے کام کرتا ہے

دو پروگرام ہوتے ہیں۔ سرور پر sshd مسلسل چلتا رہتا ہے اور connections کا انتظار کرتا ہے۔ آپ کی مشین پر ssh یہ connections بناتا ہے۔ یہ الگ configuration files والے الگ پروگرام ہیں، اور دونوں کو خلط ملط کرنا اس بات کی سب سے عام وجہ ہے کہ کسی ترمیم کا کوئی اثر نہیں ہوتا۔

• سرور /etc/ssh/sshd_config کو پڑھتا ہے۔ یہیں password login بند کیا جاتا ہے اور listening port مقرر کیا جاتا ہے۔
• کلائنٹ پہلے system defaults کے لیے /etc/ssh/ssh_config پڑھتا ہے، پھر ہر host کی اپنی settings کے لیے ~/.ssh/config پڑھتا ہے۔

Debian اور Ubuntu پر service unit کا نام ssh ہے۔ RHEL، Rocky اور Fedora پر اس کا نام sshd ہے۔ Ubuntu کی حالیہ releases میں یہ socket activated حالت میں install ہوتا ہے۔ اس لیے systemctl status ssh inactive (dead) رپورٹ کر سکتا ہے، جبکہ مشین پوری طرح reachable ہو، کیونکہ listening کا کام ssh.socket unit کر رہی ہوتی ہے اور یہ ضرورت کے وقت service شروع کر دیتی ہے۔

کلائنٹ کا OpenSSH ہونا ضروری نہیں۔ Windows پر PuTTY، فون پر Termius، اور editors میں built-in remote support سب اسی sshd سے اسی protocol کے ذریعے بات کرتے ہیں۔ Windows 10 اور 11 میں OpenSSH client بھی شامل ہوتا ہے، اس لیے ssh you@server میں PowerShell کے اندر بغیر کچھ install کیے کام کرتا ہے۔

SSH port 22 کیوں استعمال کرتا ہے؟

Port ایک عدد ہوتا ہے جو kernel کو بتاتا ہے کہ incoming connection کس listening program سے متعلق ہے، اور Linux میں ports ہر service کے لیے اسی طرح کام کرتے ہیں۔ SSH port 22 اس لیے استعمال کرتا ہے کہ IANA نے اسے 1995 میں assign کیا تھا۔ Ylönen نے ایسا غیر استعمال شدہ نمبر مانگا جو ان protocols کے قریب ہو جن کی جگہ SSH کو بنایا گیا تھا: 21 FTP کے لیے تھا، 23 telnet کے لیے، اور 22 غیر استعمال شدہ تھا۔

چونکہ 22 default ہے، اس لیے ہر چیز اسی کو فرض کرتی ہے۔ آپ کا Git remote، backup script اور provider کا control panel سب سے پہلے 22 پر کوشش کرتے ہیں۔ Internet پر موجود ہر automated scanner بھی یہی کرتا ہے۔ Password login enabled نیا server boot ہونے کے چند منٹ میں /var/log/auth.log میں ایسی lines جمع کرنا شروع کر دیتا ہے:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

یہ traffic مسلسل جاری رہتا ہے اور خاص طور پر آپ کو نشانہ نہیں بناتا۔ sshd کو port 2222 پر منتقل کرنے سے ایسی زیادہ تر lines ختم ہو جاتی ہیں، کیونکہ scanners آپ کے server کا مطالعہ کرنے کے بجائے پورے internet کو 22 پر scan کر رہے ہوتے ہیں۔ جو شخص واقعی server کو target کرے، اس کے لیے machine میں داخل ہونا مشکل نہیں ہوتا۔ Port تبدیل کرنے کو صرف noise reduction سمجھیں، اس سے زیادہ کچھ نہیں۔

آپ login کیے بغیر بھی دیکھ سکتے ہیں کہ server کیسے جواب دیتا ہے:

nc 203.0.113.10 22

Ubuntu 24.04 پر یہ output تقریباً SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13 دکھاتا ہے۔ Banner cleartext میں بھیجا جاتا ہے، کیونکہ اس وقت تک encryption قائم نہیں ہوتی اور دونوں فریقوں کو protocol version پر اتفاق کرنا ہوتا ہے۔ Connection بند کرنے کے لیے Ctrl+C دبائیں۔

نیٹ ورک پر کنکشن قائم کرتے وقت کیا ہوتا ہے

ذیل کی ترتیب وہ مراحل دکھاتی ہے جو ایک ssh you@server prompt دکھائی دینے سے پہلے مکمل کرتا ہے۔

1. کلائنٹ hostname کو IP address میں resolve کرتا ہے، پھر port 22 سے TCP connection کھولتا ہے۔
2. دونوں فریق اپنا version banner cleartext میں بھیجتے ہیں۔
3. دونوں فریق اپنے supported algorithms کی فہرستیں بھیجتے ہیں: key exchange، cipher، message authentication اور compression۔ یہ معلومات بھی cleartext میں ہوتی ہیں۔ دونوں فریق جس مضبوط ترین option کو جانتے ہوں، وہ منتخب کیا جاتا ہے۔
4. Key exchange چلتا ہے۔ موجودہ OpenSSH میں عموماً curve25519-sha256 کو ترجیح دی جاتی ہے۔ دونوں endpoints کے پاس آخر میں ایک ہی shared secret ہوتا ہے، لیکن یہ secret کبھی network سے نہیں گزرتا۔ اس لیے پوری گفتگو record کرنے والا شخص بعد میں اسے معلوم نہیں کر سکتا۔
5. server اس exchange کے نتیجے پر اپنی host private key سے signature کرتا ہے۔ آپ کا client اس signature کو اپنی فائل میں موجود host public key کے ساتھ verify کرتا ہے۔ یہی مرحلہ درمیان میں موجود کسی machine کو آپ کے server کی نقالی کرنے سے روکتا ہے۔
6. Encryption شروع ہوتی ہے۔ موجودہ OpenSSH میں chacha20-poly1305@openssh.com default cipher ہے۔
7. اب client آپ کی authentication کرتا ہے، password یا key کے ذریعے۔ آپ کا username اور password encrypted channel کے اندر منتقل ہوتا ہے۔
8. client ایک channel کھولتا ہے اور shell کی درخواست کرتا ہے۔

اس فہرست کی ترتیب ہی telnet سے پورا فرق پیدا کرتی ہے۔ Authentication channel کے encrypted ہونے اور server کی شناخت ثابت ہونے کے بعد ہوتی ہے۔ اس لیے کوئی ایسا لمحہ نہیں آتا جب آپ کا password network پر کھلے عام موجود ہو۔

Network کی نگرانی کرنے والا شخص پھر بھی کچھ معلومات حاصل کر سکتا ہے۔ اسے آپ کا IP address، server کا IP address، port 22، دونوں cleartext version banners، اور ہر packet کے وقت اور تقریباً حجم کا علم ہو جاتا ہے۔ اسے آپ کا username، password، commands یا ان کا output نظر نہیں آتا۔ step 1 میں hostname lookup SSH کا حصہ نہیں ہوتا اور عموماً private بھی نہیں ہوتا، اس لیے وہ DNS query جو آپ کے server name کو resolve کرتی ہے یہ ظاہر کر سکتی ہے کہ آپ کس machine سے connect ہونے والے ہیں، اگرچہ session خود محفوظ رہتا ہے۔

host key اور پہلی connection fingerprint prompt

جب openssh-server install ہوتا ہے تو یہ machine کے لیے host key pairs بناتا ہے اور انہیں /etc/ssh/ میں لکھتا ہے، مثلاً ssh_host_ed25519_key اور ssh_host_ed25519_key.pub۔ private حصہ کبھی server سے باہر نہیں جاتا۔ public حصہ server کی identity ہوتا ہے، اور step 5 میں موجود signature کی اسی کے خلاف تصدیق کی جاتی ہے۔

جب آپ پہلی بار کسی نئے server سے connect کرتے ہیں تو آپ کے client کے پاس موازنہ کرنے کے لیے کچھ نہیں ہوتا، اس لیے وہ آپ سے پوچھتا ہے:

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

fingerprint، host public key کا SHA256 hash ہوتا ہے جو base64 میں دکھایا جاتا ہے، تاکہ اسے بصری طور پر مختصر انداز میں compare کیا جا سکے۔ yes لکھنے سے یہ key آپ کی اپنی machine پر ~/.ssh/known_hosts میں محفوظ ہو جاتی ہے۔ اس address سے ہر بعد کی connection میں server کی پیش کردہ key کا stored key سے موازنہ کیا جاتا ہے۔ دونوں keys match کریں تو کچھ print نہیں ہوتا اور آپ براہِ راست اپنے prompt پر پہنچ جاتے ہیں۔

اس model کو trust on first use کہا جاتا ہے، اور اس کی قیمت کو واضح طور پر سمجھنا ضروری ہے۔ پہلی connection وہ واحد لمحہ ہے جب آپ غیر محفوظ ہوتے ہیں، کیونکہ آپ ایسی key قبول کر رہے ہوتے ہیں جسے آپ نے پہلے کبھی نہیں دیکھا۔ اس خلا کو ختم کرنے کے لیے fingerprint کسی دوسرے ذریعے سے حاصل کریں اور اس کا موازنہ کریں۔ زیادہ تر providers اسے اپنی web console میں دکھائے جانے والے boot output میں print کرتے ہیں، اور آپ اسے server پر بھی print کر سکتے ہیں:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

یہ وہی SHA256: string print کرتا ہے جو prompt میں دکھائی گئی تھی۔ prompt میں [fingerprint] choice اسی مقصد کے لیے موجود ہے: متوقع fingerprint paste کریں، اور client صرف اس وقت جاری رہتا ہے جب وہ server کی پیش کردہ fingerprint سے match کرے۔

Debian اور Ubuntu پر known_hosts by default hashed ہوتا ہے، اس لیے file میں ایسی lines ہوتی ہیں جو readable hostnames کے بجائے |1| سے شروع ہوتی ہیں۔ ایک host کی entry تلاش کرنے کے لیے ssh-keygen -F 203.0.113.10 چلائیں۔

SSH یہ کیوں کہتا ہے کہ host key تبدیل ہو گئی ہے؟

جلد یا بدیر آپ کو متن کی یہ طویل دیوار نظر آئے گی:

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

یہ پیغام Host key verification failed. پر ختم ہوتا ہے، اور client connection سے انکار کر دیتا ہے۔ یہ Password authentication is disabled to avoid man-in-the-middle attacks. بھی دکھاتا ہے، کیونکہ نامعلوم machine پر اپنا password درج کرنا اسی نقصان سے بچانے کے لیے یہ check موجود ہے۔

یہ پیغام ہنگامی صورتِ حال جیسا لگتا ہے، لیکن زیادہ تر وقت ایسا نہیں ہوتا۔ عام وجوہات یہ ہیں:

• آپ نے server کو دوبارہ build یا reinstall کیا، اس لیے sshd نے پہلی boot پر نئی host keys generate کیں۔ یہ سب سے عام وجہ ہے۔
• آپ نے ایک VPS ختم کر کے دوسرا بنایا، اور provider نے نئی machine کو وہی پرانا IP address دے دیا۔
• آپ کسی forward یا load balancer کے ذریعے connect ہو رہے ہیں، جو اب مختلف backend machine تک پہنچا رہا ہے۔
• واقعی کوئی آپ کی connection intercept کر رہا ہے۔

کسی بھی چیز کو clear کرنے سے پہلے طے کریں کہ ان میں سے کون سی وجہ ہے۔ اگر آپ نے machine دس منٹ پہلے reinstall کی ہے تو وجہ واضح ہے۔ اگر آپ کی جانب کچھ تبدیل نہیں ہوا تو رک جائیں اور investigation کریں، کیونکہ یہ warning اسی check کے درست طور پر کام کرنے کی علامت ہے۔ جب آپ مطمئن ہو جائیں، stale entry حذف کر کے دوبارہ connect کریں:

ssh-keygen -R 203.0.113.10

اگلی connection پر fingerprint کا prompt دوبارہ دکھائی دے گا۔ اس موقع پر آپ اسے provider console کے fingerprint سے دوبارہ compare کر سکتے ہیں۔

پاس ورڈ لاگ اِن بمقابلہ key لاگ اِن

Password authentication آپ کا پاس ورڈ پہلے سے encrypted channel کے اندر بھیجتی ہے، اور sshd اسے account database کے خلاف check کرتا ہے، عموماً PAM (pluggable authentication modules) کے ذریعے۔ اس کے لیے کسی تیاری کی ضرورت نہیں ہوتی، اسی لیے provider آپ کو صرف root password کے ساتھ نیا server فراہم کر سکتا ہے۔

کمزوری encryption میں نہیں ہے۔ مسئلہ یہ ہے کہ پاس ورڈ ایک مختصر secret ہوتا ہے، آپ ہر login پر اسے server کو بھیجتے ہیں، اور port 22 پر ایسے machines چوبیس گھنٹے اندازے آزماتے رہتے ہیں جو کبھی نہیں تھکتیں۔

Public key authentication مختلف طریقے سے کام کرتی ہے۔ آپ اپنے machine پر key pair بناتے ہیں۔ اس کا public حصہ server پر آپ کے account کے اندر ~/.ssh/authorized_keys میں رکھا جاتا ہے۔ private حصہ آپ کے laptop پر رہتا ہے اور کبھی transmit نہیں ہوتا۔ Login کرنے کے لیے client ایسے data پر دستخط کرتا ہے جس میں key exchange سے حاصل کردہ session identifier شامل ہوتا ہے، اور server اپنے پاس موجود public key سے اس signature کی تصدیق کرتا ہے۔ چونکہ signed data اسی session کے ساتھ منسلک ہوتا ہے، اس لیے captured signature کسی اور مقصد کے خلاف بے فائدہ رہتا ہے۔

سمت کا خیال رکھیں، کیونکہ اسے الٹا سمجھنا عام اور نقصان دہ ہے: public key server پر جاتی ہے، جبکہ private key آپ کے پاس رہتی ہے۔ Server پر copy کی گئی private key ایسی private key ہے جس پر آپ مزید اعتماد نہیں کر سکتے۔

Key login میں بھی اپنی failure modes ہوتی ہیں۔ sshd اس وقت keys کو نظرانداز کرتا ہے جب file permissions بہت کھلی ہوں، اور server log میں اس کی اطلاع دیتا ہے:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Client آپ کو صرف Permission denied (publickey) بتاتا ہے، جو درجن بھر مختلف وجوہات کے لیے ایک ہی message ہے۔ اس لیے publickey error درست طور پر پڑھنا سیکھ لینا اس سے پہلے مفید ہے کہ آپ خود کو lock out کر دیں۔ Keys بنانے، انہیں passphrase سے محفوظ رکھنے اور agent میں load کرنے کا عملی کام SSH key management میں بیان کیا گیا ہے، جبکہ خود کو server سے باہر کیے بغیر password login بند کرنے کا طریقہ VPS پر SSH کو harden کرنا میں شامل ہے۔

SFTP، scp اور port forwarding اسی connection پر چلتے ہیں

یہ بنیادی تصور SSH کی باقی دنیا کو سمجھنے میں مدد دیتا ہے۔ Authentication ایک encrypted connection کھولتی ہے، اور یہ connection بیک وقت کئی آزاد channels کو منتقل کر سکتی ہے۔ Shell کئی اقسام کے channels میں سے صرف ایک ہے۔

• Remote shell۔ ssh you@server ایک session channel کھولتا ہے اور interactive shell کی درخواست کرتا ہے۔
• Single command۔ ssh you@server uptime ایک channel کھولتا ہے، ایک command چلاتا ہے، output دکھاتا ہے اور بند ہو جاتا ہے۔
• SFTP۔ Client sshd سے اپنا sftp subsystem شروع کرنے کی درخواست کرتا ہے، اور file transfer اسی connection کے اندر چلتی ہے۔ SFTP ایک file transfer protocol ہے جو SSH کے ذریعے چلتا ہے، اور اس کا FTP کے ساتھ کوئی design مشترک نہیں۔ Encryption شامل کیا گیا FTP پروٹوکول FTPS کہلاتا ہے، اور اس کا SFTP سے کوئی تعلق نہیں۔
• scp۔ اسی login کو استعمال کرتے ہوئے files copy کرتا ہے۔ 2022 میں جاری ہونے والے OpenSSH 9.0 کے بعد scp default طور پر اندرونی طور پر SFTP protocol استعمال کرتا ہے۔
• Port forwarding۔ ssh -L 8080:localhost:80 you@server آپ کے laptop پر port 8080 کو encrypted connection کے اندر منتقل کرتے ہوئے server کے port 80 تک رسائی کا راستہ بنا دیتا ہے۔ -R forwarding کو دوسری سمت میں کرتا ہے، جبکہ -D 1080 session کو SOCKS proxy میں تبدیل کر دیتا ہے۔
• Git۔ git@github.com:user/repo.git جیسا remote ایک SSH login ہوتا ہے، جس کے remote side پر shell کے بجائے command handler چلتا ہے۔
• rsync اور Ansible بھی SSH clients ہیں۔ یہ ایک channel کھولتے ہیں، کوئی عمل چلاتے ہیں، اور output واپس پڑھتے ہیں۔

اس فہرست میں شامل ہر چیز ایک ہی port، host key کی ایک ہی جانچ اور وہی credentials استعمال کرتی ہے۔ اسی لیے key authentication کو ایک بار configure کرنا فوراً فائدہ دیتا ہے: ان میں سے ہر tool اسے خود استعمال کرتا ہے۔ اسی وجہ سے وہی ~/.ssh/config file، جو آپ کے logins مختصر کرتی ہے، اس وقت بھی مؤثر رہتی ہے جب آپ ایک laptop سے کئی Linux servers manage کر رہے ہوں۔

SSH کیا نہیں کرتا

• یہ آپ کے server کو secure نہیں بناتا۔ SSH دروازے تک پہنچنے والے راستے کو محفوظ رکھتا ہے۔ دروازہ پھر بھی موجود رہتا ہے، اور لوگ اس کا handle آزمانے کی کوشش کرتے رہیں گے۔ fail2ban کے ذریعے بار بار login attempts کو block کرنا اس حجم کو سنبھالتا ہے، جبکہ صرف key authentication اختیار کرنے سے وہ چیز ختم ہو جاتی ہے جس کا وہ اندازہ لگا رہے ہوتے ہیں۔
• یہ آپ کو اپنی machine سے محفوظ نہیں رکھتا۔ جس شخص کو آپ کے laptop تک access حاصل ہو، اس کے پاس آپ کی private key اور loaded agent دونوں ہوتے ہیں۔
• یہ اس حقیقت کو مخفی نہیں کرتا کہ آپ SSH استعمال کر رہے ہیں۔ port number اور cleartext version banner اس کا اعلان کرتے ہیں۔
• یہ connection قائم ہونے سے پہلے ہونے والے مراحل کا احاطہ نہیں کرتا۔ name lookup پہلے ہوتا ہے، اور یہ فیصلہ بھی کہ کس address پر اعتماد کرنا ہے۔

اب یہاں سے آگے کیا کریں

اگر اس وقت provider console میں نیا server کھلا ہوا ہے تو مفید ترتیب پہلے سے طے ہے۔ اندر جائیں، ایک عام user بنائیں، اپنی key install کریں، پھر آسان راستے بند کر دیں۔ نئے VPS کے پہلے دس منٹ اس ترتیب کو ابتدا سے آخر تک بیان کرتا ہے، جبکہ VPS حقیقت میں کیا ہے اس machine کی بنیادی وضاحت دیتا ہے، اگر یہ اصطلاحات ابھی نئی ہیں۔ اس کے بعد keys اور hardening وہ دو مضامین ہیں جنہیں اسی ترتیب سے پڑھنا چاہیے۔

FAQ

SSH سے کیا مراد ہے؟

SSH سے مراد secure shell ہے۔ یہ remote computer میں login کرنے اور encrypted connection کے ذریعے اس پر commands چلانے کا protocol ہے، جس کی تعریف RFC 4251 سے RFC 4254 تک کی گئی ہے۔ OpenSSH وہ implementation ہے جسے تقریباً ہر کوئی استعمال کرتا ہے: آپ کی machine پر ssh client، اور remote machine پر sshd server۔ اس نے telnet کی جگہ لی، جو passwords سمیت تمام data network پر plain text میں بھیجتا تھا۔

SSH port 22 کیوں استعمال کرتا ہے؟

IANA نے 1995 میں SSH کے لیے port 22 مقرر کیا، جو FTP کے port 21 اور telnet کے port 23 کے ساتھ ہے؛ یہ وہی protocols تھے جن کی جگہ SSH کو بنایا گیا تھا۔ کوئی چیز اس number کو لازمی نہیں بناتی: /etc/ssh/sshd_config میں Port اسے server پر تبدیل کرتا ہے، اور ssh -p client پر دوسرا port منتخب کرتا ہے۔ چونکہ 22 default ہے، automated scanners مسلسل اس پر دستک دیتے رہتے ہیں۔ اسی لیے نئے server کی /var/log/auth.log Failed password for invalid user lines سے مسلسل بھر جاتی ہے۔ Port تبدیل کرنے سے یہ noise کم ہوتی ہے، لیکن حقیقی protection نہیں ملتی۔

جب SSH host key تبدیل ہونے کی warning دے تو کیا کرنا چاہیے؟

کچھ بھی clear کرنے سے پہلے وجہ معلوم کریں۔ عام طور پر وجہ بے ضرر ہوتی ہے: server دوبارہ build کیا گیا، اس لیے sshd نے نئی host keys بنائیں، یا کسی نئی machine کو پرانا IP address دے دیا گیا۔ اگر آپ جانتے ہیں کہ machine دوبارہ build کی گئی ہے تو ssh-keygen -R <host> چلائیں تاکہ محفوظ شدہ key حذف ہو جائے۔ پھر دوبارہ connect کریں اور دکھائے جانے والے fingerprint کا اپنے provider console میں موجود fingerprint سے تقابل کریں۔ اگر آپ کی طرف کچھ تبدیل نہیں ہوا تو connect نہ کریں اور password درج نہ کریں۔ OpenSSH اسی وجہ سے اس حالت میں password authentication پہلے ہی مسترد کر دیتا ہے۔

کیا SFTP اور scp، SSH سے مختلف ہیں؟

یہ SSH کے اوپر چلتے ہیں۔ Authentication مکمل ہونے کے بعد SSH connection کئی channels منتقل کر سکتی ہے، اور shell ان میں سے صرف ایک ہے۔ SFTP ایک file transfer protocol ہے جو اسی connection پر sshd کے sftp subsystem کو استعمال کرتا ہے، اور scp نے OpenSSH 9.0 سے اندرونی طور پر SFTP protocol استعمال کیا ہے۔ Port forwarding اور Git over SSH بھی اسی connection کے channels ہیں۔ یہ سب ایک ہی port، ایک ہی host key check اور ایک ہی login استعمال کرتے ہیں۔ یاد رکھیں کہ SFTP، encryption شامل کیا ہوا FTP نہیں ہے؛ اسے FTPS کہتے ہیں اور یہ الگ protocol ہے۔

کیا key authentication واقعی password سے بہتر ہے؟

ہاں، ہر ایسے server کے لیے جو internet سے قابل رسائی ہو۔ Password ایک مختصر secret ہے جو آپ ہر login پر server کو دیتے ہیں، اور automated clients مسلسل port 22 کو guess کرتے رہتے ہیں۔ Key pair کے ساتھ private half آپ کی machine سے باہر نہیں جاتا۔ Client موجودہ session سے منسلک data پر دستخط کرتا ہے، اور server اس signature کو ~/.ssh/authorized_keys میں موجود public key کے مقابل چیک کرتا ہے۔ ریکارڈ کیا گیا signature کسی دوسرے server کے خلاف دوبارہ استعمال نہیں کیا جا سکتا۔ Private key کو passphrase سے محفوظ کریں، کیونکہ بغیر passphrase والی key file اس ہر شخص کے لیے login کی فعال credential ہے جو اسے copy کر لے۔