Jag aktiverade ufw och nu ansluter inte SSH. Förlorade jag servern?

Nej. Servern körs fint — du blockerade bara dörren inifrån. Din data är orörd. Öppna webbkonsolen i din kontrollpanel (den loggar in dig utan SSH) och kör `sudo ufw disable`, och du är tillbaka. Ingen ominstallation behövs.

Varför dödade aktiveringen av ufw min SSH?

ufw nekar som standard all inkommande trafik, och om du aktiverade det utan att först tillåta din SSH-port kapas din egen session. Det är den enskilt vanligaste självförvållade utelåsningen. Gör alltid `ufw allow ` före `ufw enable`.

Hur fixar jag ufw om jag inte kan SSH:a in alls?

Använd out-of-band-webbkonsolen (serial console) i din panel — den går inte över SSH eller behöver ens nätverksstacken, så en brandväggsregel kan inte blockera den. Logga in där, sedan `sudo ufw disable` (snabbast) eller `sudo ufw allow ` för att fixa den specifika regeln.

På en NAT-VPS, vilken port tillåter jag i ufw?

Tillåt 22, inte den externa porten. På ett NAT-plan ansluter du på en hög port som 20266, men den vidarebefordras till port 22 inuti VM:en. ufw körs inuti VM:en och ser bara 22. Att tillåta 20266 gör ingenting; tillåt 22.

Är `ufw reset` säkrare än `ufw disable`?

`disable` stänger bara av brandväggen och behåller dina regler — snabbaste vägen tillbaka. `reset` raderar varje regel till standardvärden. Använd `disable` för att återställa, lägg sedan till regler försiktigt igen. Bara `reset` om regeluppsättningen är en röra du vill bli av med.

Utelåst från din VPS av ufw? Kom tillbaka in utan ominstallation

Det finns en initiationsrit för alla som är nya med att köra en egen server: du bestämmer dig för att sätta upp en brandvägg, du skriver några ufw-kommandon, du trycker enable — och din terminal blir tyst. SSH är borta. Du kraschade ingenting, du blev inte hackad. Du låste bara dörren med dig själv utanför.

Det händer bra sysadmins också. Det hände en av våra kunder förra veckan, vilket är varför jag skriver ner detta. De goda nyheterna: det är helt återställbart på under en minut, och du behöver inte ominstallera eller förlora en enda fil. Så här gör du.

En VPS förseglad bakom en brandväggsvägg, med ett glödande konsolfönster som vägen tillbaka in

Vad som faktiskt gick fel

ufw (Uncomplicated Firewall) står som standard på neka all inkommande. I det ögonblick du kör ufw enable släpps allt du inte uttryckligen tillät — inklusive SSH-sessionen du sitter i. Om du glömde att ufw allow din SSH-port först har du kapat din egen anslutning i samma ögonblick regeln träder i kraft.

Det är den klassiska versionen. Det finns två andra varianter som fångar folk:

Du tillät fel port. Skrivfel, eller så tillät du servicepoorten (säg 8080) och glömde 22.
Du tillät 22 men satte sedan en deny-regel högre i listan som skuggar den. ufw är ordningskänslig.

Hur som helst är servern själv fin — körande, disk intakt, din app fortfarande surrande bakom väggen. Det är rent ett nätverksåtkomstproblem. Vilket är precis varför fixen är enkel.

Fel drag: ominstallera

Det första instinktet är ofta "återställ bara servern och börja om." Gör inte det — inte för detta. En ominstallation raderar allt för att få tillbaka en fungerande SSH, när saken som blockerar SSH är ett brandväggskommando du kan ångra på tio sekunder. Du skulle bränna ner huset för att du låste ytterdörren.

Ominstallation är rätt val när du vill ha ett rent blad. För en ufw-utelåsning är det överdrivet.

Rätt drag: webbkonsolen

Varje VPS värd sitt salt ger dig en out-of-band-konsol — en väg in i maskinen som inte rider över SSH eller ens nätverksstacken. På EQVPS är det Console-knappen på din servers sida. Det är en serial console: endast text, direkt ansluten till VM:en som en skärm och tangentbord skulle vara. En brandväggsregel har ingen makt över den, eftersom det inte är nätverkstrafik.

Klicka på den, logga in med dina root-uppgifter (eller avslöja lösenordet i panelen om du inte har det till hands), och du är på boxen — brandvägg eller ingen brandvägg.

Ångra nu skadan. Snabbaste vägen:

sudo ufw disable

Det stänger av brandväggen och behåller dina regler, så att du kan återaktivera den senare när du har fixat misstaget. SSH kommer direkt tillbaka.

Om du hellre inte släpper brandväggen helt, öppna bara porten du missade:

sudo ufw allow 22
sudo ufw status numbered

status numbered-vyn är värd en titt — den visar regelordningen, vilket är där "jag tillät 22 men det blockerar fortfarande"-fallen gömmer sig. Om en deny sitter ovanför din allow, radera den med sudo ufw delete <nummer>.

NAT-fällan de flesta guider missar

Om du är på ett NAT-plan finns en fälla här. Du SSH:ar in på en hög port — något som 20266 — så det naturliga instinktet är ufw allow 20266. Det gör ingenting.

På NAT vidarebefordras den externa porten till port 22 inuti VM:en. ufw körs inuti VM:en och ser alltid bara 22. Så regeln du faktiskt behöver är:

sudo ufw allow 22

Tillåt 20266 och du stirrar på en fortfarande-trasig anslutning och undrar varför. Tillåt 22 och du är inne. Samma idé för vilken tjänst som helst: tillåt porten processen lyssnar på inuti boxen, inte den vidarebefordrade du ansluter till utifrån.

Hur du aldrig gör detta igen

Fixen tar en minut, men att inte behöva den är trevligare. Två vanor:

Tillåt din SSH-port innan du aktiverar. I denna ordning, alltid:

sudo ufw allow 22
sudo ufw enable

Gör det baklänges och du är tillbaka i konsolen.

Håll en andra session öppen medan du ändrar brandväggsregler. Logga in två gånger. Gör dina ändringar i ett fönster; om SSH dör är det andra fönstret fortfarande vid liv för att fixa det. Gammalt trick, räddar dig varje gång.

Och om du sätter upp en ny box täcker vår nya-VPS säkerhetschecklista ufw åt rätt håll, tillsammans med SSH-nycklar och den handfull andra saker som faktiskt spelar roll under de första tio minuterna.

Slutsatsen

En ufw-utelåsning ser skrämmande ut och är nästan ingenting. Servern lämnade aldrig; du behöver bara en dörr som en brandvägg inte kan smälla igen — webbkonsolen — och ett kommando. Håll ufw disable och konsolen i bakfickan, tillåt din port innan du aktiverar nästa gång, och du kommer aldrig svettas över detta igen.