SSD Nodes Learn 🎉 VPS $5.50/ماہ سے
تعلیمی Matt Connorتحریر: Matt Connor

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

Rocky Linux یا AlmaLinux میں SSH port بدلتے وقت پہلے firewalld rule، پھر SELinux port label، آخر میں sshd_config لگائیں تاکہ موجودہ session برقرار رہے۔

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

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

Ubuntu پر یہی کام ایک ترمیم اور restart سے ہو جاتا ہے، کیونکہ Ubuntu، SELinux کے بجائے AppArmor استعمال کرتا ہے اور ایسا کوئی profile فراہم نہیں کرتا جو sshd کے bind کیے جانے والے ports کو محدود کرے۔ اگر وہاں ufw چل رہا ہو تو ایک rule شامل کریں۔ یہی مکمل فرق ہے۔ RHEL family کی fresh installation میں 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 پالیسی کی ترتیبات میں ترمیم کرتا ہے، اور Rocky Linux یا AlmaLinux کی کم سے کم تنصیب میں یہ شامل نہیں ہوتا۔ یہ policycoreutils-python-utils میں موجود ہے۔

sudo dnf install -y policycoreutils-python-utils

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

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

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

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

پہلا check دکھاتا ہے کہ آیا کوئی process پہلے ہی اس port number پر listen کر رہا ہے۔ دوسرا check دکھاتا ہے کہ آیا SELinux policy نے یہ port کسی دوسری service type کو پہلے ہی assign کیا ہوا ہے۔ اگر port دستیاب ہو تو دونوں commands کوئی output نہیں دیتیں۔ اگر policy نے اسے پہلے ہی claim کیا ہو تو step 2 میں semanage port -a، ValueError: Port tcp/2222 already defined کے ساتھ fail ہو جاتا ہے، اور اس کا حل کوئی دوسرا port number منتخب کرنا ہے۔

اس guide میں 2222 کو بطور مثال استعمال کیا گیا ہے۔ Scanner عموماً 22 کے بعد سب سے پہلے اسی port کو آزماتا ہے، اس لیے حقیقی server پر کم obvious 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 میں لکھتا ہے اور running firewall میں کوئی تبدیلی نہیں کرتا۔ --reload disk پر موجود configuration کو running firewall میں load کرتا ہے۔ reload چھوڑ دینے سے rule موجود رہتا ہے، لیکن اس وقت تک کوئی کام نہیں کرتا جب تک firewalld دوبارہ start نہ ہو۔ یہ ان عام وجوہات میں سے ایک ہے جن کی وجہ سے پورا طریقۂ کار بظاہر بلا وجہ ناکام ہوتا ہے۔

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

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

مرحلہ 2: port کو SELinux کے لیے 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 cover کرتا ہے، تاکہ daemon میں تبدیلی کرنے سے پہلے آپ تصدیق کر سکیں کہ آپ کا نمبر شامل ہو گیا ہے۔

SELinux آخر port کو کیوں block کرتا ہے

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

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

getenforce بتاتا ہے کہ box کس mode میں ہے۔ Permissive پر denial record ہوتا ہے، لیکن enforce نہیں کیا جاتا۔ اس لیے port change کام کرتی دکھائی دیتی ہے، پھر اس دن failure ہو جاتی ہے جب کوئی setenforce 1 چلاتا ہے یا box enforcing mode میں reboot ہوتا ہے۔ Port کو دونوں صورتوں میں label کریں۔ سرور کے لیے SELinux basics guide modes، contexts اور booleans کی مناسب وضاحت کرتی ہے۔

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

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

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 drop-ins سمیت پوری configuration کو parse کرتا ہے اور syntax errors کی اطلاع دیتا ہے۔ restart سے پہلے اس کی بتائی ہوئی ہر خرابی درست کریں، کیونکہ جو configuration parse نہ ہو سکے اس کا daemon دوبارہ start نہیں ہوتا۔

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

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

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

systemctl is-enabled sshd.socket

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

sudo systemctl edit sshd.socket
[Socket]
ListenStream=
ListenStream=2222

خالی ListenStream= ضروری ہے۔ drop-ins میں values جمع ہوتی رہتی ہیں، اس لیے فہرست صاف کرنے کے لیے پہلے خالی assignment نہ دیا جائے تو socket 2222 کے ساتھ ساتھ 22 پر بھی listening جاری رکھتا ہے۔ اسے sudo systemctl daemon-reload کے ذریعے نافذ کریں، پھر 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 کامیاب ہو جائے۔ اگر 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 کی طرف سے connection refused اور connection timed out میں فرق network کے دونوں cases الگ کرتا ہے، کیونکہ refusal کا مطلب ہے کہ آپ کا packet host تک پہنچا لیکن کوئی process listening نہیں کر رہا تھا، جبکہ timeout کا مطلب ہے کہ کسی نے بھی جواب نہیں دیا۔

پورٹ 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 فرض کرتا تھا، اب اسے واضح طور پر بتانا ہوگا۔ اسے اپنی مشین پر ایک بار ~/.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 کرتی ہیں، اسے نہیں پڑھتیں۔ اس لیے تبدیلی تازہ ہونے کے دوران انہیں تلاش کر کے درست کر دیں۔

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

اس سے log میں غیر ضروری شور کم ہوتا ہے۔ خودکار scanners مسلسل port 22 پر حملہ کرتے ہیں۔ اس port سے ہٹنے پر 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 کا تقابلی جائزہ دیکھیں۔ کسی پرانی 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 کا انتظام کرنے والے server پر یہی مطلوبہ طریقہ ہے۔

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

[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 کے ذریعے start کریں اور sudo fail2ban-client status sshd سے jail کا جائزہ لیں۔ jail کا syntax وہی ہے جو Ubuntu 24.04 پر SSH کے لیے fail2ban setup میں استعمال ہوا ہے۔ صرف package source اور ban action مختلف ہیں۔

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

جس سرور کا SSH port تبدیل کر دیا گیا ہو لیکن چار ماہ سے security updates لاگو نہ کی گئی ہوں، اس کی حالت اس سرور سے زیادہ خراب ہے جو port 22 پر چل رہا ہو اور ہر رات خودکار طور پر patch ہو جاتا ہو۔ اسی session میں unattended updates فعال کریں، کیونکہ آپ پہلے ہی root کے طور پر موجود ہیں: Rocky Linux اور AlmaLinux پر automatic dnf updates میں timer اور updates download کرنے یا انہیں لاگو کرنے کے درمیان انتخاب کی وضاحت کی گئی ہے۔

FAQ

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

تقریباً ہمیشہ وجہ SELinux کا missing port label ہوتا ہے۔ sshd، sshd_t domain میں restricted حالت میں چلتا ہے، اور policy اسے صرف ssh_port_t کے label والے ports پر bind ہونے دیتی ہے۔ پہلے سے یہ صرف 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 کی اجازت پھر بھی مل جاتی ہے، اس لیے تبدیلی کامیاب دکھائی دیتی ہے۔ لیکن label اب بھی موجود نہیں ہوتا۔ جب کوئی setenforce 1 چلائے، یا machine /etc/selinux/config میں SELINUX=enforcing کے ساتھ 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 استعمال نہ کریں جو بعد میں install کی جانے والی کسی service کے لیے مختص ہو۔ زیادہ اور یاد رکھنے میں مشکل number بھی مناسب ہے، کیونکہ آپ اسے ~/.ssh/config میں ایک بار لکھیں گے اور دوبارہ type نہیں کریں گے۔