SELinux اور firewalld کے ساتھ SSH پورٹ کیسے بدلیں

یہاں SSH پورٹ تبدیل کرنے کے لیے تین مراحل کیوں درکار ہیں

Rocky Linux، AlmaLinux، CentOS Stream یا Fedora پر SSH پورٹ تبدیل کرنے کے لیے صرف ایک ترمیم کافی نہیں ہوتی۔ تین الگ نظام یہ فیصلہ کرتے ہیں کہ نئی پورٹ پر کنکشن کام کرے گا یا نہیں۔ firewalld فیصلہ کرتا ہے کہ packet مشین تک پہنچے گا یا نہیں۔ SELinux فیصلہ کرتا ہے کہ sshd کو اس پورٹ نمبر پر bind کرنے کی اجازت ہے یا نہیں۔ sshd_config فیصلہ کرتا ہے کہ daemon کس پورٹ کی درخواست کرے گا۔ SELinux کا مرحلہ چھوڑنے پر daemon start ہونے سے انکار کر دیتا ہے۔ firewalld کا مرحلہ چھوڑنے پر daemon start ہو جاتا ہے، listening کرتا ہے، لیکن کوئی اس تک پہنچ نہیں سکتا۔

Ubuntu پر یہی کام ایک ترمیم اور restart سے ہو جاتا ہے، کیونکہ Ubuntu، SELinux کے بجائے AppArmor استعمال کرتا ہے اور ایسا کوئی profile فراہم نہیں کرتا جو یہ محدود کرے کہ sshd کن ports پر bind کر سکتا ہے۔ اگر وہاں ufw چل رہا ہو تو آپ ایک rule شامل کرتے ہیں۔ فرق صرف اتنا ہی ہے۔ RHEL family کی fresh install پر firewalld چل رہا ہوتا ہے اور SELinux enforcing حالت میں ہوتا ہے، اور دونوں port numbers کو مدنظر رکھتے ہیں۔

یہ کام اسی ترتیب سے کریں تاکہ ہر مرحلے کے دوران موجودہ session فعال رہے:

1. نئی port کو firewalld میں کھولیں، اور فی الحال port 22 کھلی رہنے دیں۔
2. semanage کے ذریعے نئی port کے لیے SELinux label شامل کریں۔
3. sshd configuration میں port مقرر کریں۔
4. sshd کو restart کریں، پھر پہلا terminal بند کرنے سے پہلے دوسرے terminal سے نئی port پر login کریں۔

شروع کرنے سے پہلے اپنے provider کا web console (VNC یا serial) تلاش کریں اور تصدیق کریں کہ آپ اس کے ذریعے login کر سکتے ہیں۔ اگر تبدیلی میں مسئلہ پیدا ہو جائے تو یہی console دوبارہ رسائی کا ذریعہ ہوگا۔ port تبدیل کرنا ان عام ترین وجوہات میں سے ایک ہے جن کی وجہ سے tenant اپنے اس server سے باہر ہو جاتا ہے جس کے لیے اس نے ابھی ادائیگی کی ہو۔

پہلے semanage انسٹال کریں

semanage وہ ٹول ہے جو SELinux پالیسی کی settings میں ترمیم کرتا ہے، اور Rocky Linux یا AlmaLinux کی minimal installation میں یہ شامل نہیں ہوتا۔ یہ policycoreutils-python-utils میں موجود ہوتا ہے۔

sudo dnf install -y policycoreutils-python-utils

اس package کو انسٹال کرنے سے پہلے command چلانے پر sudo: semanage: command not found ظاہر ہوتا ہے۔ یہی وہ مرحلہ ہے جہاں بہت سے قارئین یہ سمجھتے ہیں کہ SELinux انسٹال نہیں ہے اور یہ step چھوڑ دیتے ہیں۔ SELinux انسٹال ہے۔ صرف management tool موجود نہیں ہے۔ اگر dnf syntax آپ کے لیے نیا ہے تو dnf اور apt commands کے متبادل اسے ان commands سے جوڑتے ہیں جن سے آپ پہلے ہی واقف ہیں۔

ایک پورٹ منتخب کریں اور جانچیں کہ اس پر کوئی سروس موجود نہیں

1024 سے 65535 کے درمیان کوئی بھی دستیاب TCP پورٹ استعمال کی جا سکتی ہے۔ کسی پورٹ کو حتمی طور پر منتخب کرنے سے پہلے دو جانچیں کریں:

sudo ss -tlnp | grep -w 2222
sudo semanage port -l | grep -w 2222

پہلی جانچ سے معلوم ہوتا ہے کہ آیا کوئی process پہلے ہی اس نمبر پر listening کر رہا ہے۔ دوسری جانچ سے معلوم ہوتا ہے کہ آیا SELinux policy نے یہ پورٹ پہلے ہی کسی دوسری service type کے لیے مختص کر رکھی ہے۔ مکمل طور پر دستیاب پورٹ دونوں commands کے لیے کوئی output نہیں دیتی۔ اگر policy نے یہ پورٹ پہلے ہی مختص کر رکھی ہو تو مرحلہ 2 میں semanage port -a، ValueError: Port tcp/2222 already defined کے ساتھ fail ہو جاتا ہے، اور حل یہ ہے کہ کوئی دوسرا نمبر منتخب کیا جائے۔

اس guide میں مثال کے طور پر 2222 استعمال کیا گیا ہے۔ scanner عموماً 22 کے بعد اسی port کو آزماتا ہے، اس لیے حقیقی server پر کم واضح port منتخب کریں۔

مرحلہ 1: firewalld میں port کھولیں

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

--permanent rule کو disk پر موجود zone file میں لکھتا ہے اور چلتے ہوئے firewall کو تبدیل نہیں کرتا۔ --reload disk پر موجود configuration کو چلتے ہوئے firewall میں load کرتا ہے۔ reload چھوڑ دینے سے rule موجود رہتا ہے، لیکن firewalld کے اگلی بار restart ہونے تک کوئی کام نہیں کرتا۔ یہ ان عام وجوہات میں سے ایک ہے جن کی وجہ سے پورا طریقۂ کار بظاہر بلاوجہ ناکام معلوم ہوتا ہے۔

ابھی ssh service entry کو تبدیل نہ کریں۔ یہی entry port 22 کو کھلا رکھتی ہے اور testing کے دوران fallback کے طور پر کام آتی ہے۔

اپنے provider کا control panel بھی چیک کریں۔ بہت سے hosts VPS کے سامنے، operating system سے باہر، network firewall چلاتے ہیں۔ اس لیے firewalld میں کھولا گیا port upstream سطح پر پھر بھی drop ہو سکتا ہے۔ VPS کے لیے firewalld کی بنیادی رہنما میں zones اور runtime اور permanent configuration کے فرق کی وضاحت موجود ہے، اگر یہ model آپ کے لیے نیا ہے۔

مرحلہ 2: SELinux کے لیے port کو label کریں

sudo semanage port -a -t ssh_port_t -p tcp 2222
sudo semanage port -l | grep ssh_port_t

-a نئی port assignment شامل کرتا ہے۔ -t ssh_port_t وہ type ہے جو SSH ports استعمال کرتے ہیں۔ دوسری command ان تمام ports کی فہرست دکھاتی ہے جنہیں اب ssh_port_t شامل کرتا ہے، تاکہ daemon میں تبدیلی کرنے سے پہلے آپ تصدیق کر سکیں کہ آپ کا نمبر شامل ہو گیا ہے۔

SELinux پورٹ کو کیوں بلاک کرتا ہے

SELinux (security-enhanced Linux) سسٹم پر موجود ہر آبجیکٹ کو ایک label دیتا ہے، اور TCP port numbers بھی دوسرے آبجیکٹس کی طرح آبجیکٹس ہیں۔ SSH daemon ایک ایسے domain میں محدود ہو کر چلتا ہے جسے sshd_t کہتے ہیں۔ Policy sshd_t کو ssh_port_t سے label شدہ TCP ports پر bind کرنے کی اجازت دیتی ہے، اور ابتدائی configuration میں یہ label صرف port 22 کے پاس ہوتا ہے۔ Daemon کو 2222 پر bind کرنے کا کہیں تو kernel label چیک کرتا ہے، اس number کو دی گئی generic type تلاش کرتا ہے، اور socket پر name_bind permission دینے سے انکار کر دیتا ہے۔

اسی لیے یہ failure firewall problem جیسا نظر نہیں آتا۔ Kernel اس وقت انکار کر دیتا ہے جب listening socket ابھی موجود بھی نہیں ہوتا، اس لیے sshd error report کر کے exit ہو جاتا ہے۔ Firewall problem اس کے برعکس ہوتی ہے: daemon چل رہا ہوتا ہے اور درست کام کر رہا ہوتا ہے، لیکن packets اندر آتے ہوئے discard ہو جاتے ہیں۔

getenforce بتاتا ہے کہ box کس mode میں ہے۔ Permissive میں denial record ہوتا ہے لیکن enforce نہیں کیا جاتا، اس لیے port change کام کرتی ہوئی دکھائی دیتی ہے، پھر اس دن ناکام ہو جاتی ہے جب کوئی setenforce 1 چلاتا ہے یا box enforcing mode میں reboot ہوتا ہے۔ دونوں صورتوں میں port کو label کریں۔ سرور کے لیے SELinux basics guide modes، contexts اور booleans کی مناسب وضاحت کرتی ہے۔ Ports ہی واحد objects نہیں ہیں جن پر یہ اثر پڑتا ہے۔ یہی policy کسی container کو mounted host directory پڑھنے سے بھی روکتی ہے جب تک اس path کو دوبارہ relabel نہ کیا جائے۔ اسی لیے Rocky Linux یا AlmaLinux پر Docker انسٹال کرنا میں SELinux کا ایک مرحلہ شامل ہوتا ہے، جس کا Ubuntu guides میں کبھی ذکر نہیں ہوتا۔

مرحلہ 3: sshd کی configuration میں port مقرر کریں

Rocky Linux 9 اور 10، AlmaLinux 9 اور 10، اور موجودہ Fedora میں /etc/ssh/sshd_config ایک include line سے شروع ہوتی ہے، اس لیے تبدیلی کے لیے مناسب جگہ drop-in file ہے۔ اس کے بعد package updates آپ کی ترمیم کے ساتھ متصادم نہیں ہوں گی۔

grep -n '^Include' /etc/ssh/sshd_config
echo 'Port 2222' | sudo tee /etc/ssh/sshd_config.d/10-port.conf
sudo sshd -t

اگر grep کو کوئی Include line نہ ملے، جیسا کہ Rocky Linux 8 اور دیگر پرانی images میں ہوتا ہے، تو اس کے بجائے Port 2222 کو براہِ راست /etc/ssh/sshd_config میں شامل کریں۔ sshd -t پوری configuration، بشمول drop-ins، کو parse کرتا ہے اور syntax errors کی اطلاع دیتا ہے۔ restart سے پہلے ہر رپورٹ کردہ مسئلہ درست کریں، کیونکہ جو configuration parse نہ ہو سکے اس کا daemon دوبارہ start نہیں ہوتا۔

Port ایک سے زیادہ مرتبہ ظاہر ہو سکتا ہے، اور sshd درج تمام ports پر listen کرتا ہے۔ پہلے دن Port 22 کو Port 2222 کے ساتھ برقرار رکھنا ایک سادہ حفاظتی انتظام ہے، بشرطیکہ آپ اسے ہٹانا یاد رکھیں۔

کیا آپ کا sshd، socket unit کے ذریعے شروع ہوتا ہے؟

کچھ images، SSH کو طویل عرصے تک چلنے والی service کے بجائے systemd socket activation کے ذریعے شروع کرتی ہیں۔ جہاں یہ طریقہ configured ہو، وہاں systemd listening socket کا انتظام کرتا ہے اور connections کو sshd کے حوالے کرتا ہے۔ اس لیے sshd_config میں موجود Port line مکمل طور پر نظر انداز ہو جاتی ہے۔ کسی بھی چیز کو restart کرنے سے پہلے یہ جانچ لیں:

systemctl is-enabled sshd.socket

enabled جواب کا مطلب ہے کہ port، sshd_config میں نہیں بلکہ socket unit میں set ہے:

sudo systemctl edit sshd.socket

[Socket]
ListenStream=
ListenStream=2222

خالی ListenStream= لازمی ہے۔ drop-ins میں values جمع ہوتی رہتی ہیں۔ اس لیے فہرست صاف کرنے کے لیے پہلے خالی assignment نہ دیا جائے تو socket، 22 کے ساتھ 2222 پر بھی listening کرتا رہے گا۔ اسے sudo systemctl daemon-reload کے ذریعے apply کریں، پھر sudo systemctl restart sshd.socket چلائیں۔ اگر یہ unit آپ کے server پر disabled ہو یا موجود ہی نہ ہو تو یہ section آپ پر لاگو نہیں ہوتا۔

مرحلہ 4: restart کریں، پھر دوسرے terminal سے test کریں

sudo systemctl restart sshd
systemctl status sshd
sudo ss -tlnp | grep sshd

یہ terminal کھلا رکھیں۔ اس سے log out نہ کریں۔ اپنی مشین پر دوسرا terminal کھولیں اور نئے port پر connect کریں:

ssh -p 2222 youruser@203.0.113.10

پہلا session صرف اس وقت بند کریں جب دوسرا login کامیاب ہو جائے۔ اگر یہ کام نہ کرے تو آپ کے پاس اب بھی ایسا shell موجود ہوگا جس سے تمام تبدیلیاں واپس کی جا سکتی ہیں۔ یہی عادت پانچ منٹ کی تبدیلی اور provider console پر پوری دوپہر گزارنے کے درمیان فرق پیدا کرتی ہے۔

Firewall drop یا SELinux denial؟ ان دونوں میں فرق کیسے معلوم کریں

آپ کے laptop سے دونوں failures تقریباً یکساں دکھائی دیتی ہیں۔ Server پر ان کی صورت بالکل مختلف ہوتی ہے۔

• اگر systemctl status sshd unit کو failed دکھائے تو daemon کو اس کا socket کبھی نہیں ملا۔ یہ configuration error یا SELinux denial ہے۔
• اگر unit active ہو اور ss -tlnp دکھائے کہ sshd نئے port پر bound ہے تو daemon درست ہے۔ مسئلہ network path میں ہے: firewalld، provider کا الگ firewall، یا وہ address اور port جس سے آپ connection کی کوشش کر رہے ہیں۔

SELinux کی صورت میں اندازہ لگانے کے بجائے audit record پڑھیں:

sudo ausearch -m AVC -ts recent
sudo journalctl -u sshd -n 50 --no-pager

name_bind denial، class tcp_socket پر comm="sshd" میں process، src= میں port number، اور tcontext= میں اس label کا نام بتاتا ہے جو port پر حقیقتاً موجود ہے۔ آخری field ہی جواب ہے۔ ssh_port_t کے علاوہ کوئی بھی value اس بات کی علامت ہے کہ step 2 آپ کے استعمال کردہ port پر لاگو نہیں ہوا۔ عموماً وجہ number میں typo یا غلط protocol ہوتا ہے۔ اگر آپ چاہتے ہیں کہ sealert record کو جملے میں تبدیل کرے تو setroubleshoot-server install کریں۔

Kernel کی جانب سے bind مسترد ہونے پر sshd خود جو message لکھتا ہے، وہ یوں ہوتا ہے:

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.

1024 سے بڑے port پر Permission denied، جہاں bind کرنے کے لیے root privilege درکار نہیں ہوتا، SELinux کی واضح علامت ہے۔ اسی line میں Address already in use ایک مختلف fault کی نشاندہی کرتا ہے: کوئی دوسرا process اس port کو استعمال کر رہا ہے۔ Client side سے connection refused اور connection timed out میں فرق دونوں network cases کو الگ کرتا ہے، کیونکہ refusal کا مطلب ہے کہ آپ کا packet host تک پہنچا لیکن کوئی process listening نہیں کر رہا تھا، جبکہ timeout کا مطلب ہے کہ کسی نے بھی جواب نہیں دیا۔

port 22 بند کریں اور اپنے clients کو اپ ڈیٹ کریں

نئے port پر کئی logins کامیاب ہو جائیں تو port 22 ہٹا دیں:

sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

port 22 پر SELinux label کو تبدیل نہ کریں۔ یہ base policy سے آتا ہے، اور firewall کے packets اندر آنے سے روکنے کے بعد یہ کوئی access فراہم نہیں کرتا۔

اس کے بعد clients کو درست کریں، کیونکہ ہر وہ tool جو default port فرض کرتا تھا، اب اسے port بتانا ضروری ہے۔ اسے اپنی machine کے ~/.ssh/config میں صرف ایک بار درج کریں، بجائے اس کے کہ ہمیشہ -p لکھتے رہیں:

Host myvps
  HostName 203.0.113.10
  Port 2222
  User youruser

scp، sftp، rsync اور Ansible سب اس file کو پڑھتے ہیں۔ Backup jobs، monitoring checks اور cron scripts جو port 22 کو hardcode کرتے ہیں، ایسا نہیں کرتے۔ اس لیے تبدیلی تازہ ہونے کے دوران ان تمام جگہوں کو تلاش کریں۔

پورٹ تبدیل کرنے سے کیا فائدہ ہوتا ہے اور کیا نہیں ہوتا

اس سے لاگ میں غیر ضروری شور کم ہوتا ہے۔ خودکار scanners مسلسل port 22 پر requests بھیجتے رہتے ہیں، اور اسے تبدیل کرنے سے journal میں ایسی زیادہ تر entries ختم ہو جاتی ہیں۔ اس طرح حقیقی events دیکھنا آسان ہو جاتا ہے۔ یہ کوئی security control نہیں ہے۔ مکمل port range کو scan کرنے والا کوئی بھی scanner آپ کے daemon کو تلاش کر لیتا ہے اور اس کا version banner بھی پڑھ لیتا ہے۔ پورٹ کی تبدیلی کو صرف housekeeping سمجھیں، اور اصل تحفظ key-only authentication میں فراہم کریں۔ اس کے لیے password logins بند کر دیں۔ VPS کے لیے SSH hardening guide میں یہ عمل مرحلہ وار بیان کیا گیا ہے۔

اوپر بیان کردہ تمام اقدامات دونوں بڑے RHEL rebuilds پر یکساں کام کرتے ہیں، کیونکہ دونوں ایک ہی sources سے بنائے گئے ہیں۔ اگر آپ اب بھی دونوں میں انتخاب کر رہے ہیں تو Rocky Linux اور AlmaLinux کا تقابلی جائزہ دیکھیں۔ ان میں سے کسی ایک کو منتخب کرنے کی ضرورت اس لیے پیش آتی ہے کہ CentOS نے 2020 میں یہ کردار چھوڑ دیا تھا۔ اس کی مکمل تفصیل Red Hat سے CentOS، پھر Rocky اور AlmaLinux تک کی داستان میں دی گئی ہے۔ کسی بھی پرانی guide پر عمل کرنے سے پہلے cat /etc/os-release کے ذریعے معلوم کریں کہ آپ کو اصل میں کون سا release دیا گیا ہے۔ Rocky Linux 8 کے لیے لکھی گئی guides اب بھی اچھی درجہ بندی رکھتی ہیں، اور ان کے semanage اور firewall-cmd والے steps درست رہتے ہیں۔ تاہم Rocky 8 میں sshd_config.d include line اور socket unit موجود نہیں ہے، اس لیے ان guides کا sshd والا حصہ موجودہ box سے مطابقت نہیں رکھتا۔

fail2ban کو نئے port کے بارے میں بتانا ضروری ہے

fail2ban base repositories میں شامل نہیں ہے۔ یہ EPEL (enterprise Linux کے لیے اضافی packages) سے آتا ہے:

sudo dnf install -y epel-release
sudo dnf install -y fail2ban fail2ban-firewalld

fail2ban-firewalld subpackage fail2ban کو اپنے bans firewalld کے ذریعے نافذ کرنے دیتا ہے۔ firewalld ruleset کا مالک ہو تو یہی مطلوبہ طریقہ ہے۔

stock sshd jail میں port = ssh مقرر ہوتا ہے، اور یہ نام /etc/services کے ذریعے 22 پر resolve ہوتا ہے۔ تبدیلی کے بعد jail ایسے port کی نگرانی کرے گا جس پر کوئی حملہ نہیں کر رہا۔ نتیجتاً 2222 پر failed logins جمع ہوتے رہیں گے، مگر کوئی ban نہیں ہوگا۔ /etc/fail2ban/jail.local میں port کو عدد کے ذریعے مقرر کریں:

[sshd]
enabled = true
port = 2222
backend = systemd
maxretry = 5
bantime = 3600

backend = systemd failures کو /var/log/secure کے بجائے journal سے پڑھتا ہے۔ یہ minimal install پر زیادہ محفوظ انتخاب ہے، جہاں rsyslog موجود نہ بھی ہو سکتا ہے۔ اسے sudo systemctl enable --now fail2ban کے ساتھ شروع کریں اور sudo fail2ban-client status sshd کے ذریعے jail کی جانچ کریں۔ jail کا syntax وہی ہے جو Ubuntu 24.04 پر fail2ban کے SSH setup میں استعمال ہوا ہے۔ فرق صرف package source اور ban action کا ہے۔

پورٹ تبدیل کرنے سے زیادہ اہم patching ہے

ایسا سرور جس کا SSH port تبدیل کر دیا گیا ہو لیکن چار ماہ سے security updates لاگو نہ ہوئی ہوں، اس سرور سے زیادہ خراب حالت میں ہے جو port 22 پر چل رہا ہو اور ہر رات خودکار طور پر patches نصب کرتا ہو۔ اسی session میں، جب آپ پہلے ہی root ہوں، unattended updates فعال کریں: Rocky Linux اور AlmaLinux پر خودکار dnf updates میں timer اور updates download کرنے یا انہیں لاگو کرنے کے درمیان انتخاب کی وضاحت کی گئی ہے۔ نصب کی گئی update پہلے سے پرانے code پر چلنے والے daemons کو restart نہیں کرتی۔ اس لیے جب openssh-server یا اس سے منسلک کوئی library updates کے batch میں شامل ہو، تو یہ جانچنا کہ کن services کو اب بھی restart یا reboot درکار ہے ایک منٹ صرف کرنے کے قابل ہے۔

FAQ

Rocky Linux پر port تبدیل کرنے کے بعد sshd start کیوں نہیں ہوتا؟

تقریباً ہمیشہ وجہ missing SELinux port label ہوتی ہے۔ sshd، sshd_t domain میں محدود حالت میں چلتا ہے، اور policy اسے صرف ssh_port_t سے label شدہ ports پر bind کرنے کی اجازت دیتی ہے۔ بطور default یہ صرف port 22 ہوتا ہے۔ Kernel bind کی درخواست مسترد کر دیتا ہے، اس لیے daemon listening شروع کرنے کے بجائے exit ہو جاتا ہے، اور journalctl -u sshd میں error: Bind to port 2222 on 0.0.0.0 failed: Permission denied. جیسی لائن درج ہوتی ہے۔ اپنے port number کے ساتھ sudo semanage port -a -t ssh_port_t -p tcp 2222 چلائیں، پھر service restart کریں۔ اگر semanage نہ ملے تو پہلے policycoreutils-python-utils install کریں۔

کیا SELinux permissive mode میں ہو تو بھی semanage درکار ہے؟

جی ہاں۔ permissive mode میں denial record ہوتی ہے اور bind پھر بھی allow ہو جاتا ہے، اس لیے تبدیلی کامیاب دکھائی دیتی ہے۔ لیکن label اب بھی موجود نہیں ہوتی۔ جیسے ہی کوئی setenforce 1 چلاتا ہے، یا host SELINUX=enforcing کے ساتھ /etc/selinux/config میں boot ہوتا ہے، sshd اس port پر start ہونا بند کر دیتا ہے۔ label شامل کرنے کے لیے ایک command کافی ہے، اور اس failure کا امکان ختم ہو جاتا ہے جو بصورت دیگر کئی ہفتوں بعد کسی واضح وجہ کے بغیر سامنے آ سکتی تھی۔

Port labelled ہے اور sshd چل رہا ہے، پھر connection timeout کیوں ہو رہا ہے؟

چلتا ہوا daemon اس بات کی تصدیق کرتا ہے کہ SELinux مطمئن ہے، اس لیے packet اندر آتے ہوئے کہیں drop ہو رہا ہے۔ اپنے port کے لیے sudo firewall-cmd --list-ports چیک کریں، اور تصدیق کریں کہ --permanent rule کے بعد firewall-cmd --reload چلایا تھا، کیونکہ صرف permanent rule بنانے سے running firewall میں تبدیلی لاگو نہیں ہوتی۔ اس کے بعد اپنے host کے control panel میں VPS کے سامنے موجود الگ network firewall چیک کریں۔ لوگ اکثر دوسری جگہ block ہوتے ہیں، اور operating system کے اندر کوئی چیز اس کا ثبوت نہیں دکھائے گی۔

22 کے بجائے کون سا port استعمال کرنا چاہیے؟

1024 سے 65535 کے درمیان کوئی بھی دستیاب TCP port استعمال کریں۔ حقیقی server پر 2222 اور 22222 سے گریز کریں، کیونکہ scanners، 22 کے فوراً بعد، ان ports کو بھی آزماتے ہیں۔ sudo ss -tlnp سے تصدیق کریں کہ number دستیاب ہے، sudo semanage port -l سے دیکھیں کہ SELinux policy نے اسے پہلے سے claim نہیں کیا، اور ایسے port سے گریز کریں جو کسی ایسی service کے لیے مختص ہو جسے آپ بعد میں install کر سکتے ہیں۔ زیادہ بڑا اور مشکل سے یاد رہنے والا number بھی ٹھیک ہے، کیونکہ اسے ~/.ssh/config میں ایک بار درج کرنے کے بعد دوبارہ type نہیں کرنا پڑے گا۔