Hem > Guider, Linux > Lösningar för SSH anslutning bakom NAT utan timeout!

Lösningar för SSH anslutning bakom NAT utan timeout!

Jag använder nästan dagligen SSH för allt från enkel fjärrstyrning av Linux-serverar för administration och underhåll, till att köra tunnel genom brandväggar. Om man går tillbaks ett par år hade jag ett irriterad problem som förs terminalfönstret efter ett par minuter inaktivitet på en SSH session. Detta berodde inte oftast på att jag hade dålig uppkoppling, utan det uppstår när en SSH anslutning får timeout eller dödas av någon anledning. Den vanligaste orsaken är oftast brandväggens NAT-funktion som kopplar ned anslutningar om ingen trafik har skickas inom en viss tid. Oftast är det efter 10-15 minuter, detta trots att enligt standard (RFC 5382 – NAT Behavioral Requirements for TCP) ska vara minst 2 timmar och 4 minuter. Varför detta inte uppfylls av vissa NAT-routrar kan ha flera orsaker. En anledning kan vara att brandväggen har brist på minne och genom olika åtgärder försöker frigöra minne, bland annat avsluta inaktiva uppkopplingar så som SSH anslutning i förtid.

Oavsett varför NAT beter sig som den gör är det faktum att det händer. Om man har en router eller brandvägg som har detta beteende finns det flera sätt att lösa problemet. Jag har listat tre stycket.

Lösning 1 – Ändra brandväggens beteende

Denna lösning är rätt uppenbar, vet man var problemet uppstår går man dit för att fixa det. Det enda som man behöver göra är att antingen öka timeouten eller inaktivera NAT.

Det finns två problem med denna tillvägagångssätt; Först och främst, är det en leverantörs brandvägg som man inte kommer åt inställningarna så är man rätt körd. Chansen att kunna påverka leverantörens brandvägg får ses som minimal. Titta istället på dem två andra lösningarna

Det andra problemet är även om du har full kontroll över exempelvis routern som finns i hemmet så är oftast fallet att man inte kan göra något. Routrar gjorda för hemanvändare går oftast (om inte aldrig) varken ställa in timeouten eller göra andra tweekar. Enda möjligheten är att stäng av NAT och gå in i bryggläge. Dock medför det mer problem än vad det löser, eftersom den släpper igenom all trafik utan inverkan från brandväggen. Dessutom får man bara en IP-adress från internetleverantören kan bara en dator surfa mot internet. Även om mot förmodan kan ändra inställningarna kan routern rent av inte kraftfull nog att ta hand om trafiken.

Vill man ha brandvägg och möjlighet dela på en extern IP-adress måste man koppla in en ny router som ersätter eller komplimenterar den gamla routern. Dock säger det sig själv om man inte har en bra router att koppla på löser det inte problemet. En ny router som löser problemet kostar en slant.

Har man bara problem med SSH anslutning som får timeout skulle jag rekommendera att titta på de andra lösningarna nedan. Men om man har generellt inte friskt nätverk och om det finns annat än SSH som spökar kan det vara värt att satsa på en ny router. Har man fått router/modem från internetleverantören är det säkrast att brygga det för sedan koppla in från en LAN-port på modemet till WAN-porten på den nya routern. Även med en ny router är det värt att ta en titt på resterande lösningar.

Lösning 2 – Server håller SSH anslutning vid liv

Om man inte kan hindra NAT-brandväggen att koppla ned en inaktiv SSH anslutning, då får man istället lura NAT att anslutningen är aktiv. Ett enkelt sätt är att skicka paket tillräckligt ofta för att brandväggen ska uppfatta som en aktiv SSH-anslutning. SSH-servern har en inbyggd funktion för att skicka null-paket (tomt paket) i ett intervall som man önskar. För att kunna använda denna lösning kräver det att man har root-access. Om man inte har det titta lösningen nedan. Denna Lösning utgår från en Linux SSH-server, men samma princip gäller om man har SSH-server på en Mac och andra plattformar.

Första steget är att öppna SSH-config filen:

sudo nano /etc/ssh/sshd_config

Lägg till följande inställningar längst ned i filen:

KeepAlive yes
ClientAliveInterval 60

KeepAlive är självförklarande, ClientAliveInterval ser dock till att skicka ett null-paket från servern till klienten inom ett visst tidsintervall som man anger i sekunder. I detta fall skickas ett nytt paket var 60:e sekund, med andra ord en gång i minuten. Om man vill kan man justera tiden om man vill skicka paket oftare eller mer sällan, men en gång i minuten bör passa för de flesta.

Starta om sedan SSH-servern, vilket man oftast gör med följande kommando:

sudo /etc/init.d/ssh restart

Nu kan man prova logga in med SSH och testa om det blir timeout.

Fördelen med metoden är om det är många klienter som ansluter sig till en server går det sannolikt snabbare att göra ändringen på servern än att göra motsvarande ändring hos klienten. Nackdelen är att om man har många servrar kan detta vara tidskrävande, därför kan det vara bra idé att titta på nästa lösning.

Lösning 3 – Klienten håller SSH anslutning vid liv

Sitter man vid ett fåtal klienter men loggar in på många servrar så skulle jag rekommendera denna lösnig. Till skillnad mot föregående lösning behöver man inte root-access utan det räcker tillgång till hem-mappen på en Linux eller Mac dator. Varje plattform har lite olika tillvägagångssätt för att lösa detta.

Linux

På klienten, öppna en terminal och kör följande:

mkdir ~/.ssh; chmod 700 ~/.ssh; gedit ~/.ssh/config

Väl inne i filen lägg till följande i början av filen:

Host *
ServerAliveInterval 60

Spara och stäng ned filen. Nu kan man prova logga in med SSH och testa om det blir timeout.

Mac

På klienten, öppna en terminal (Program -> Programverktyg -> Terminal) och kör följande:

mkdir ~/.ssh; chmod 700 ~/.ssh; touch ~/.ssh/config; open -e ~/.ssh/config

Väl inne i filen lägg till följande i början av filen:

Host *
ServerAliveInterval 60

Spara och stäng ned filen. Nu kan man prova logga in med SSH och testa om det blir timeout.

Notering för alla lösningarna

Oavsett om man väljer en eller flera lösningar ovan kommer dem att fungera oberoende av varandra. Lösning 2 och 3 är en bra kombination för om man både har många servrar och klienter. Speciellt om det är en mix av servrar som har root-access till och till de som inte har root-access. Dock är det värt att nämna det finns ingen lösning ovan som löser SSH uppkopplingen fryser eller skriver ut ”Broken pipe” på grund av förlorad SSH anslutning. Exempelvis när man är ansluten till mobilt bredband samtidigt som man är i rörelse. Det finns ett antal sätt att lösa detta på med kombination av tekniker så som autossh.

Mosh, bästa som hänt SSH sedan version 2.0?

Ett nystartat projekt vid namn Mosh (mobile shell) som är ett mycket intressant. Tanken är med ny teknik ska kunna lösa de många av de problem som finns för SSH idag. Det är specifikt designat för att fungera på instabila uppkopplingar så som mobilt bredband. Teknisk demo:

Anledningen till jag inte tar upp Mosh som en lösning är av flera själ. Ett är att projektet är mycket ungt, första kommit gjordes  december 2010 enligt projektet på Github. Sedan, som det nämndes i videon, finns det ett par saker som behöver slipas på som exempelvis hur den beter sig mot brandväggar.

När projektet har mognat ytterligare är det inte omöjligt jag kommer göra separat artikel.

Frågor och feedback

Jag skulle uppskatta om jag fick feedback på denna artikel. Hjälpte detta dig? Är det något som är oklart? Några frågor? Tveka inte använda att kommentera till detta inlägg. Även om jag föredrar kommentarer går det bra kontakta mig via mail om det känns mer bekvämt för dig. Fyll i bara formuläret under kontakta mig.

Categories: Guider, Linux Taggar: , , ,
  1. Inga kommentarer än.
  1. Inga trackbacks än.