విరిగిన ufw ruleset నుంచి తిరిగి ప్రవేశించడం ఎలా

ముందుగా తిరిగి ప్రవేశించండి

ufw మీ VPS కు ప్రవేశాన్ని నిరోధించినట్లయితే, తిరిగి ప్రవేశించే మార్గం provider console లేదా rescue mode మాత్రమే. నిరోధించే rule అమల్లోకి వచ్చిన తర్వాత SSH ఆధారిత పరిష్కారం ఉండదు. sshd ఆ packet ను చూసేలోపే kernel దాన్ని drop చేస్తుంది. అందువల్ల network ద్వారా login చేయడానికి లేదా సమస్యను సరిచేయడానికి ఏ మార్గమూ ఉండదు. మీ provider యొక్క control panel లో console తెరిచి, ఆ prompt వద్ద login చేసి, ఒక command అమలు చేయండి.

sudo ufw disable

మీకు Firewall stopped and disabled on system startup కనిపించాలి. ఒకటి లేదా రెండు సెకన్లలో కొత్త SSH connections మళ్లీ పనిచేస్తాయి. మీరు configure చేసినది ఏదీ కోల్పోదు: disable kernel నుంచి rules ను unload చేసి, ENABLED=no ను /etc/ufw/ufw.conf లో రాస్తుంది. అయితే మీ rules disk పై /etc/ufw/user.rules లో అలాగే ఉంటాయి. తదుపరి ufw enable కోసం అవి వేచి ఉంటాయి.

Reboot చేసి సమస్య తొలగిపోతుందని ఆశించవద్దు. boot సమయంలో ufw స్వయంగా ప్రారంభమవుతుంది. అందువల్ల ENABLED=yes అంటే అదే ruleset network ప్రారంభమయ్యేలోపే మళ్లీ load అవుతుందని అర్థం. ufw lockout విషయంలో reboot చేయడం వల్ల ఏ మార్పూ ఉండదు.

కన్సోల్‌కు మీ వద్ద లేకపోవచ్చని పాస్‌వర్డ్ అవసరం

వెబ్ కన్సోల్ (VNC లేదా serial) యంత్రానికి అనుసంధానించిన keyboard వంటిది. ఇది network path కాదు. అందువల్ల ఏ firewall rule కూడా దీన్ని block చేయలేదు. అయితే దీనికి local login అవసరం. ఇక్కడే key-only setups విఫలమవుతాయి: మీరు మీ sudo user కోసం ఎప్పుడూ password సెట్ చేయకపోతే, root login locked గా ఉంటే, మీరు సమాధానం ఇవ్వలేని prompt ను కన్సోల్ చూపిస్తుంది. మీ వద్ద ఇంకా SSH ఉన్నప్పుడే ఆ password ను సెట్ చేయండి: sudo passwd yourname. చాలా panels root password ను కూడా reset చేయగలవు. సాధారణంగా దీనికి reboot అవసరం అవుతుంది.

కన్సోల్ ఉపయోగించలేకపోతే, provider యొక్క rescue system లో boot చేయండి. ఇది మీ disk unmounted గా ఉన్న ప్రత్యేక operating system ను నడుపుతుంది. అందువల్ల బయట నుంచి ufw ను ఆఫ్ చేయవచ్చు.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

ముందుగా lsblk ను run చేయండి. root partition ఎల్లప్పుడూ /dev/vda1 గా ఉండదు. సాధారణ system లోకి reboot చేసిన తర్వాత, మీరు స్వయంగా enable చేసే వరకు ufw off గానే ఉంటుంది.

కనిష్ట పునరుద్ధరణ క్రమం

ఈ క్రమంలో పని చేయండి. మొదటి నాలుగు దశలు సురక్షితమైనవి. వాటి తర్వాతి దశ సురక్షితం కాదు.

1. నియమాలను unload చేసి మీ యాక్సెస్‌ను తిరిగి పొందడానికి sudo ufw disable ఉపయోగించండి.
2. మీరు జోడించిన నియమాలను, వాటిని జోడించిన commands రూపంలో చూపించడానికి sudo ufw show added ఉపయోగించండి. ufw inactive గా ఉన్నప్పటికీ ఇది పనిచేస్తుంది; ufw status పనిచేయదు.
3. sshd నిజంగా ఏ port పై listening చేస్తున్నదో నిర్ధారించడానికి sudo sshd -T | grep -i '^port' ఉపయోగించండి. మీరు దాన్ని మార్చకపోతే ఇది port 22 ను చూపిస్తుంది.
4. మీ వాస్తవ port ను ఉపయోగించి sudo ufw allow 22/tcp అమలు చేయండి. తద్వారా తర్వాతి enable మళ్లీ lockout కు దారితీయదు.
5. ముందుగా rollback ను schedule చేసి sudo ufw enable అమలు చేయండి. ఆ విధానం ఈ పేజీలో కింద ఉంది.

ufw reset వాస్తవంగా చేసే పని

ufw reset చివరి మార్గం మాత్రమే; మొదటి చర్య కాదు. ఇది firewall ను నిలిపివేస్తుంది, ప్రతి rules file కు backup తీసుకుంటుంది, అలాగే incoming ను deny చేసి outgoing ను allow చేసే default విధానాలకు తిరిగి మారుస్తుంది. ప్రతి file కు ఒక backup line ను చూపిస్తుంది:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

reset చేసిన తర్వాత మీ వద్ద allow rules ఏవీ ఉండవు. అందువల్ల దీన్ని SSH ద్వారా కాకుండా console నుంచి అమలు చేయండి. మళ్లీ enable చేయడానికి ముందు SSH rule ను జోడించండి. ఆ backups సాధారణ text files గా ఉంటాయి. పాత rules ఎలా ఉన్నాయో sudo grep -n dport /etc/ufw/user.rules.20260813_101500 చూపిస్తుంది. మీరు తొలగించకూడదనుకున్న ruleset ను తిరిగి నిర్మించడానికి ఇదే ఉపయోగపడుతుంది.

ufw తన నియమాలను ఎక్కడ ఉంచుతుంది

ఊహించి గుర్తు తెచ్చుకోవడం కంటే ఫైళ్లను చదవడం మంచిది. మొత్తం స్థితిని ఈ ఐదు paths కలిగి ఉంటాయి:

• /etc/ufw/user.rules మరియు /etc/ufw/user6.rules: మీరు జోడించిన నియమాలు. అవి మూల్యాంకనం చేయబడే క్రమంలో ఉంటాయి.
• /etc/ufw/before.rules మరియు /etc/ufw/after.rules, అలాగే వాటి 6 variants: మీ నియమాల చుట్టూ ufw అమలు చేసే framework. ఇందులో ఇప్పటికే ఏర్పడిన connections కోసం accept నియమం, loopback నియమాలు ఉంటాయి.
• /etc/default/ufw: default policies మరియు IPV6 switch.
• /etc/ufw/ufw.conf: ENABLED మరియు log level.
• /var/log/ufw.log: logging ప్రారంభించిన తర్వాత block చేయబడినవి.

ufw ఒక file ను తిరిగి రాయడానికి ముందు దాని timestamp ఉన్న copy ని సృష్టిస్తుంది. అందువల్ల ls /etc/ufw/ లో user.rules.20260813_101500 వంటి పేర్లు చేరుతాయి. ఇది undo history. మీరు మార్పులను తిరిగి చేయడం ప్రారంభించే ముందు దీన్ని చదవడం ఉపయోగకరం.

డిస్క్‌పై ఉన్నదానికి బదులుగా kernel లో load అయినదాన్ని చూడాలంటే sudo ufw show raw ఉపయోగించండి. లేదా sudo iptables -S మరియు sudo ip6tables -S ఉపయోగించండి. Ubuntu 22.04 మరియు 24.04 లో ఈ commands nft ఆధారిత versions. అందువల్ల sudo nft list ruleset అదే rules ను కొత్త syntax లో ప్రదర్శిస్తుంది.

ufw ప్రారంభించిన తర్వాత నా SSH session ఎందుకు నిలిచిపోయింది?

డిఫాల్ట్ incoming policy deny. మీ SSH port కోసం ఎలాంటి rule లేకుండా ufw ను ప్రారంభిస్తే, ప్రతి కొత్త connection నిలిచిపోతుంది. ufw దీనిపై హెచ్చరిక కూడా ఇస్తుంది: Command may disrupt existing ssh connections. Proceed with operation (y|n)? SSH allow rule అమలులో లేకుండా y కు సమాధానం ఇవ్వడం, ఈ పేజీలో వివరించిన సమస్యకు అత్యంత సాధారణ కారణం.

ఇందులో గందరగోళం కలిగించే విషయం ఆలస్యం. /etc/ufw/before.rules మీ స్వంత rules వర్తించే ముందు ESTABLISHED,RELATED state లోని packets ను అనుమతిస్తుంది. అందువల్ల command అమలు చేసిన అదే session సాధారణంగా కొనసాగుతుంది. తదుపరి connection ఏర్పడినప్పుడు మాత్రమే access నిలిచిపోయిన విషయం తెలుస్తుంది. అది కొన్ని గంటల తర్వాత కూడా జరగవచ్చు. అప్పటికి firewall మార్పుతో దాని సంబంధం స్పష్టంగా కనిపించదు. మొదటి SSH session ను మూసే ముందు ఎల్లప్పుడూ రెండవ SSH session తెరిచి, అది పనిచేస్తోందని నిర్ధారించండి.

apt మరియు DNS policy మార్పు తర్వాత ఎందుకు పనిచేయడం ఆపేశాయి?

sudo ufw default deny outgoing బయటికి వెళ్లే DNS (domain name system) queries మరియు outbound HTTPను నిరోధిస్తుంది. అందువల్ల name resolution విఫలమై, package updates ఆగిపోతాయి. apt update, Temporary failure resolving 'archive.ubuntu.com' ను నివేదిస్తుంది. Inbound SSH మాత్రం పనిచేస్తుంది. దానికి వచ్చే replies ESTABLISHED స్థితిలో ఉండి framework rules ద్వారా అనుమతించబడతాయి. అందువల్ల కారణం firewall అయినప్పటికీ firewall తప్పు కాదనిపిస్తుంది.

మీరు outgoing traffic ను deny చేసే policy కోరుకుంటే, యంత్రానికి వాస్తవంగా అవసరమైన traffic ను అనుమతించండి:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

చివరి rule లేకపోతే clock సమయం తప్పుతుంది. తప్పు సమయం TLS (transport layer security) certificate validation ను విఫలపరుస్తుంది. అందువల్ల curl ports కారణంగా కాకుండా dates కారణంగా విఫలమవడం ప్రారంభిస్తుంది. ఈ లక్షణం policy మార్పు చేసిన కొన్ని రోజుల తర్వాత కనిపిస్తుంది. అందుకే deny outgoing policy ను మీరు monitor చేసే యంత్రాలకే ఉపయోగించాలి; ఒక్కసారి setup చేసి వదిలే యంత్రానికి ఉపయోగించకూడదు.

నా ufw నియమం ఎందుకు ఎప్పుడూ వర్తించదు?

ufw వినియోగదారు నియమాలను క్రమంగా పరిశీలించి, మొదటి సరిపోలిక వద్ద ఆగిపోతుంది. విస్తృతమైన allow తర్వాత జోడించిన deny ఎప్పుడూ అమలు కాదు, ఎందుకంటే ఆ allow నియమమే packet కు నిర్ణయం తీసేసింది. నియమాల క్రమాన్ని సంఖ్యలతో ప్రదర్శించి, అవసరమైన స్థానంలో నియమాన్ని insert చేయండి.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp రాయబడే నియమాలను మాత్రమే ప్రదర్శిస్తుంది. ఇది ఏ మార్పూ చేయదు. నియమం అమలులోకి రాకముందు దాన్ని పరిశీలించడానికి ఇదే సురక్షితమైన విధానం.

Application profiles లో మరో సమస్య ఉంటుంది. sudo ufw allow OpenSSH, /etc/ufw/applications.d/openssh-server లోని profile ను ఉపయోగిస్తుంది. ఆ profile port 22 ను సూచిస్తుంది. sshd port 2222 పై listen చేస్తే, ఏ సేవా ఉపయోగించని port తెరుచుకుంటుంది. ఫలితంగా సరైనదిగా కనిపించే ruleset ఉన్నప్పటికీ మీరు server కు బయటపడవచ్చు. Port మార్చిన తర్వాత ఆ port number ను నేరుగా ఉపయోగించండి. మిగిలిన syntax ను VPS కోసం ufw firewall ప్రాథమికాలు లో వివరించారు.

IPv4 నియమాలు నేను చూస్తున్న విషయాన్ని ఎందుకు వివరించలేకపోతున్నాయి?

ఎందుకంటే మొత్తం network traffic లో సగం IPv4 కాదు. Ubuntu IPV6=yes ను /etc/default/ufw లో అందిస్తుంది. అందువల్ల ufw సమాంతర v6 ruleset ను /etc/ufw/user6.rules లో నిర్వహిస్తుంది. ufw allow from 203.0.113.10 to any port 22 వంటి IPv4 address తో రాసిన నియమం ఎలాంటి v6 నియమాన్ని సృష్టించదు. మీ VPS కు AAAA record ఉంటే client IPv6 కు ప్రాధాన్యం ఇస్తుంది. అప్పుడు మీ connection timeout అవుతుంది, అయితే ufw status లో సరైనదిగా కనిపించే నియమం చూపిస్తుంది. ssh -4 user@host ను ssh -6 user@host తో పోల్చి పరీక్షించండి. మొదటిది పనిచేసి, రెండవది పనిచేయకపోతే, సమస్య v6 ruleset లోని లోటు.

భద్రత పరంగా వ్యతిరేక పరిస్థితి మరింత ప్రమాదకరం. IPV6=no ఉన్నప్పుడు ufw ip6tables ను అసలు నిర్వహించదు. అందువల్ల v6 policy kernel default అయిన ACCEPT గానే ఉంటుంది. మూసివేసినదిగా మీరు భావించిన port దాని IPv6 address పై స్పందిస్తుంది. ఏ ufw command లోనూ అది కనిపించదు. sudo ip6tables -S మరియు ss -tlnp తో తనిఖీ చేయండి. పూర్తి వివరాల కోసం ufw IPv6 ports ను ఎలా నిర్వహిస్తుంది చదవండి.

ufw నిరాకరించినప్పటికీ Docker port ఎందుకు open గా ఉంది?

Docker, nat table లోకి DNAT (destination network address translation) rules రాసి, FORWARD లో తన స్వంత chain ను చేర్చడం ద్వారా port ను publish చేస్తుంది. ufw rules INPUT మార్గంలో ఉంటాయి. Container కు వెళ్లే traffic host కు నేరుగా deliver కాకుండా forward అవుతుంది. అందువల్ల అది మీ deny rule ఉన్న chain కు చేరదు. ufw సక్రియంగా ఉండి అన్నింటినీ నిరాకరిస్తున్నప్పటికీ, docker run -p 5432:5432 ఇంటర్నెట్ నుంచి చేరుకోగలదు.

sudo iptables -t nat -S DOCKER

అత్యంత సరళమైన పరిష్కారం loopback పై publish చేయడం: -p 127.0.0.1:5432:5432 host వైపు binding ను 127.0.0.1 కు పరిమితం చేస్తుంది. అందువల్ల ufw ఏం చెప్పినా బయట నుంచి దాన్ని చేరుకోలేరు. ఆ service public గా అందుబాటులో ఉండాల్సిన సందర్భాల కోసం ufw చుట్టూ Docker ports ను publish చేయడం చూడండి.

నియమాన్ని అమలు చేయడానికి ముందు rollback ను షెడ్యూల్ చేయండి

Firewall మార్పులను సురక్షితంగా నిర్వహించడానికి ఈ అలవాటు చాలా ఉపయోగకరం. ప్రమాదకరమైన మార్పు చేయడానికి ముందు దాన్ని undo చేసే చర్యను షెడ్యూల్ చేయండి. మార్పు వల్ల మీకు యాక్సెస్ నిలిచిపోతే, ఐదు నిమిషాల్లో machine స్వయంగా మునుపటి స్థితికి వస్తుంది. అప్పుడు మీరు console ను తెరవాల్సిన అవసరం ఉండదు.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd Running timer as unit: ufw-rollback.timer ను ప్రింట్ చేస్తుంది. ఇప్పుడు మీ మార్పు చేయండి. ఆ తర్వాత కూడా కొత్త SSH session ను తెరవగలిగితే rollback ను cancel చేయండి:

sudo systemctl stop ufw-rollback.timer

ఆ session ను తెరవలేకపోతే వేచి ఉండండి. ufw స్వయంగా ఆగిపోతుంది. తరువాతి ప్రయత్నంలో connection ఏర్పడుతుంది. సాధారణంగా ఉపయోగించే shutdown -r +5 పద్ధతి ufw తో పనిచేయదు, ఎందుకంటే boot సమయంలో ufw అదే ruleset ను మళ్లీ load చేస్తుంది.

ప్రత్యామ్నాయ ప్రాప్యత మార్గాన్ని సిద్ధంగా ఉంచండి

• అవసరం రాకముందే provider console లోకి ఒకసారి login చేసి, password పనిచేస్తుందో నిర్ధారించండి. ఎప్పుడూ పరీక్షించని console backup కాదు.
• ప్రత్యేక key కలిగిన రెండవ sudo user ను ఉంచండి. ఒక `authorized_keys` file దెబ్బతిన్నా మీ ప్రాప్యత పూర్తిగా నిలిచిపోకూడదు.
• మీ provider panel లో ufw కు వేరుగా network firewall నడుపుతుందో లేదో తనిఖీ చేయండి. అది అదే ports ను block చేస్తుంది, కానీ `ufw status` దాని గురించి ఎప్పుడూ ప్రస్తావించదు.
• ఆ address dynamic అయితే `ufw allow from <your home address>` ను మీ ఏకైక SSH rule గా ఉపయోగించవద్దు. మీ provider దాన్ని రాత్రివేళ మార్చవచ్చు. అప్పుడు మీరు బయటపడతారు.

ఇవన్నీ చేయడానికి అత్యంత అనుకూల సమయం కొత్త server ను సిద్ధం చేస్తున్నప్పుడే. కొత్త VPS పై మొదటి setup పనులతో పాటు కొత్త VPS పై మొదటి పది నిమిషాలు లో ఇవి చేయండి.

Refused లేదా timed out ఏ layer విఫలమైందో తెలియజేస్తాయి

Connection refused అంటే ఒక packet server కు చేరి, ఏదో ఒకటి TCP reset ను తిరిగి పంపిందని అర్థం. Network path సరిగానే ఉంది. కాబట్టి sshd ఆపివేయబడి ఉండవచ్చు లేదా వేరే port పై listening చేస్తుండవచ్చు. సాధారణంగా firewall కారణం కాదు, ఎందుకంటే ufw default గా reject చేయకుండా packets ను drop చేస్తుంది.

Connection timed out అంటే అసలు ఎలాంటి response తిరిగి రాలేదని అర్థం. ఇది drop జరిగినప్పుడు కనిపించే లక్షణం: ufw, provider network firewall లేదా తప్పు address కారణం కావచ్చు. ఈ రెండు errors ను సరిగ్గా అర్థం చేసుకుంటే ఒక గంటపాటు ఊహాగానాలు చేయాల్సిన అవసరం ఉండదు. connection refused మరియు timed out మధ్య తేడా మిగిలిన సందర్భాలను వివరిస్తుంది.

తదుపరి మార్పు చేయడానికి ముందు logging ను ప్రారంభించండి

sudo ufw logging on
sudo tail -f /var/log/ufw.log

నిరోధించబడిన packet ఇలా కనిపిస్తుంది:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

SRC= లో మీ స్వంత address తో ఉన్న DPT=22, మిమ్మల్ని నిరోధిస్తున్నది network లేదా sshd కాదు, ufw అని నిర్ధారిస్తుంది. rsyslog లేని minimal image లో /var/log/ufw.log ఉండదు; అదే lines sudo journalctl -k | grep UFW నుంచి వస్తాయి. ufw తన logging rules కు rate limits అమలు చేస్తుంది. కాబట్టి line కనిపించకపోవడం వల్ల packet అనుమతించబడిందని నిర్ధారించలేం.

మీరు జోడించని నియమాలు కనిపిస్తే

తానుగా మారిన ruleset firewall సమస్య కాదు. దాన్ని root అధికారాలతో ఎవరో రాశారు. ఏ sudo commands నడిచాయో, అవి ఏ account కింద నడిచాయో చూడటానికి sudo grep ufw /var/log/auth.log అమలు చేయండి. ఆ timestamp చుట్టూ జరిగిన logins కోసం తరువాత last అమలు చేయండి. ఆ accounts మీకు తెలిసిన వారితో సరిపోలకపోతే, firewall ను debug చేయడం ఆపి, బదులుగా compromised VPS checklist ప్రకారం పరిశీలించండి. మరొకరు నియంత్రిస్తున్న server పై firewall ను మళ్లీ enable చేయడం సమస్యను మాత్రమే దాచుతుంది.

మళ్లీ సరిగ్గా అమర్చండి

కారణం తెలిసిన తర్వాత, మళ్లీ కనెక్షన్ నిలిచిపోకుండా ufw ను తిరిగి enable చేయండి. మీరు వాస్తవంగా ఉపయోగిస్తున్న SSH port ను allow చేయండి, rollback ను schedule చేయండి, ufw ను enable చేయండి. తరువాత మరో terminal నుంచి పూర్తిగా కొత్త SSH session ప్రారంభించి, అది connect అవుతుందో నిర్ధారించండి. ఆ కొత్త session సక్రియంగా ఉందని నిర్ధారించిన తర్వాత మాత్రమే మీరు ప్రస్తుతం పనిచేస్తున్న session ను close చేయాలి. ఒక రోజు logging ను ఆన్‌లో ఉంచండి. మీరు allow చేయడం మర్చిపోయిన దాన్ని, user.rules చదవడం కంటే log చాలా వేగంగా చూపిస్తుంది.

FAQ

ufw disable నా నియమాలను తొలగిస్తుందా?

లేదు. disable ruleset ను kernel నుంచి unload చేసి, ENABLED=no ను /etc/ufw/ufw.conf లో వ్రాస్తుంది. మీ నియమాలు /etc/ufw/user.rules మరియు /etc/ufw/user6.rules లో ఉంటాయి. Firewall inactive గా ఉన్నప్పటికీ sudo ufw show added వాటిని చూపిస్తుంది. వాటిని clear చేసే command ufw reset. ఇది ముందుగా ప్రతి file కు backup తీసుకుని, Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500' వంటి line ను print చేస్తుంది.

నా VPS ను reboot చేస్తే ufw lockout తొలగిపోతుందా?

లేదు. ufw boot సమయంలో /etc/ufw/ufw.conf లోని ENABLED=yes నుంచి ప్రారంభమవుతుంది. అందువల్ల network ప్రారంభం కాకముందే అదే నియమాలు load అవుతాయి, మీరు మళ్లీ lockout అవుతారు. మీరు ufw ను ఆపిన తర్వాత, లేదా disk ను mount చేసి rescue mode నుంచి ఆ file ను edit చేసిన తర్వాత మాత్రమే reboot సహాయపడుతుంది. Provider console ను ఉపయోగించి అక్కడ sudo ufw disable ను run చేయండి.

ufw port ను deny చేసినప్పటికీ నా Docker container ఎందుకు reachable గా ఉంది?

ప్రతి published port కోసం Docker తన సొంత DNAT మరియు FORWARD rules ను వ్రాస్తుంది. ఆ traffic host కు deliver కాకుండా container కు forward అవుతుంది. అందువల్ల మీ ufw deny rule ఉన్న INPUT chain గుండా అది వెళ్లదు. ఆ port host కోసం మాత్రమే కావాలంటే -p 127.0.0.1:5432:5432 తో loopback పై publish చేయండి. Docker install చేసిన rules ను sudo iptables -t nat -S DOCKER తో పరిశీలించండి.

నా వద్ద console password లేదు, rescue mode కూడా లేదు. నా options ఏమిటి?

మిగిలిన options మీ provider పరిధిలో ఉంటాయి: control panel నుంచి password reset చేయడం, దీనివల్ల సాధారణంగా server reboot అవుతుంది, లేదా disk ను మరో instance కు attach చేసి అక్కడి నుంచి /etc/ufw/ufw.conf ను edit చేయడం. Server ను rebuild చేయడానికి ముందు support ను సంప్రదించండి, ఎందుకంటే rebuild చేస్తే దానిలోని data నశిస్తుంది. తిరిగి login అయిన తర్వాత sudo passwd yourname ను run చేసి, console login ను ఒకసారి test చేయండి. తదుపరి lockout ను పరిష్కరించడానికి 2 minutes మాత్రమే పడేలా ఇది సహాయపడుతుంది.