Tudta, hogy egy frissen telepített Linux VPS-t az online lét első órájában több mint 400 automatizált jelszófeltörési kísérlet érhet? Ez a megdöbbentő adat rávilágít arra, hogy a szakszerűen konfigurált ssh hozzáférés vps-hez nem csupán egy technikai kényelmi funkció, hanem a szervere legfontosabb védelmi vonala a globális botnetekkel szemben. A 2026-os kiberbiztonsági környezetben már nem elég egy erős jelszó; a folyamatos támadások korában tudatos és többrétegű védekezésre van szükség.
Teljesen érthető, ha tart a szerver feltörésétől, vagy ha a parancssori felület elsőre ijesztőnek tűnik, különösen, amikor váratlan “Connection refused” hibákba ütközik. Sokan érzik úgy, hogy a terminál világa túl bonyolult, de a megfelelő ismeretekkel ez a folyamat gyorssá és rutinszerűvé válik. Ebből az útmutatóból megtanulhatja, hogyan csatlakozzon biztonságosan VPS szerveréhez, és hogyan optimalizálja az SSH beállításokat a maximális védelem érdekében. Segítünk, hogy a kezdeti bizonytalanságot magabiztos rendszeradminisztrátori tudássá alakítsa.
Részletesen végigvesszük a modern Ed25519 kulcsalapú hitelesítés beállítását, a legújabb OpenSSH frissítések kezelését és azokat a kritikus biztonsági lépéseket, mint a root bejelentkezés letiltása vagy a Fail2Ban használata. Megmutatjuk, hogyan teheti szerverét gyakorlatilag láthatatlanná a támadók számára, miközben Önnek stabil és zavartalan marad a távoli elérése.
Mi az az SSH hozzáférés és miért elengedhetetlen a VPS kezeléséhez?
Az SSH (Secure Shell) nem csupán egy egyszerű szoftver, hanem a modern szerverüzemeltetés alapköve. Amikor egy Linux VPS előfizetést vásárol, az első dolog, amire szüksége lesz, az az ssh hozzáférés vps-hez. Ez a protokoll teszi lehetővé, hogy a saját számítógépe termináljából úgy irányítsa a távoli szervert, mintha közvetlenül előtte ülne. A titkosított csatorna garantálja, hogy a parancsok és a válaszok érintetlenül és lehallgathatatlanul jussanak célba, bármilyen hálózaton keresztül is csatlakozik.
A Secure Shell protokoll alapértelmezés szerint a 22-es TCP portot használja a kommunikációhoz. Míg a korai hálózati megoldások, mint a Telnet vagy az rsh, titkosítatlanul, sima szövegként küldték át a jelszavakat a hálózaton, az SSH aszimmetrikus kriptográfiát alkalmaz. Ez azt jelenti, hogy még ha egy támadó el is csípi az adatcsomagokat a nyilvános interneten, azok tartalmát nem tudja visszafejteni. Ez a biztonsági szint elengedhetetlen, mivel a VPS szerverek állandóan ki vannak téve az automatizált hálózati szkennereknek. A protokoll nemcsak a titkosságot, hanem az adat integritását is védi, így biztos lehet benne, hogy a parancsai módosítás nélkül érkeznek meg a célállomásra.
SSH vs. FTP: Mikor melyiket használjuk?
Sok kezdő felhasználó az FTP-t (File Transfer Protocol) részesíti előnyben a fájlok feltöltéséhez, de ez komoly biztonsági kockázatot jelenthet. Az SSH részét képező SFTP (SSH File Transfer Protocol) ugyanazt a kényelmet nyújtja, de teljes titkosítás mellett. Bár a cPanel vagy más grafikus fájlkezelők hasznosak az egyszerűbb feladatokhoz, a nagy adatmennyiségek mozgatása vagy a rendszerfájlok szerkesztése során az SSH terminál gyorsabb és precízebb megoldást kínál. A sebesség és biztonság nem zárják ki egymást. A modern titkosítási algoritmusok minimális késleltetéssel dolgoznak, így a fájlkezelés hatékony marad a napi adminisztráció során.
A root felhasználó és a jogosultságok kezelése
A Linux rendszerekben a root a legmagasabb szintű felhasználó. Minden fájlhoz hozzáfér, és bármilyen parancsot végrehajthat korlátozás nélkül. Bár kényelmesnek tűnik közvetlenül rootként bejelentkezni, ez hatalmas kockázatot hordoz magában. Egyetlen elgépelt parancs, például egy rosszul elhelyezett szóköz egy törlési műveletben, helyrehozhatatlan károkat okozhat a teljes fájlrendszerben. A professzionális ssh hozzáférés vps-hez kialakításakor ezért szigorúan a legkisebb jogosultság elvét követjük.
Ez a gyakorlatban azt jelenti, hogy egy korlátozott jogosultságú felhasználóval lépünk be a rendszerbe. Csak akkor használjuk a sudo parancsot, ha adminisztratív feladatot kell végeznünk. A sudo lehetővé teszi a privilegizált műveletek végrehajtását anélkül, hogy véglegesen root jogosultságot adnánk a teljes munkamenetnek. Ez a rétegelt védelem megakadályozza a véletlen hibákat és nehezíti a támadók dolgát is. Ha egy illetéktelen behatoló megszerzi a felhasználói hozzáférést, még mindig szüksége van a sudo jelszóra a rendszer feletti teljes irányításhoz.
Kapcsolódás a VPS szerverhez: Lépésről lépésre útmutató
Mielőtt elindítaná az első munkamenetet, három alapvető adatra lesz szüksége: a szerver IP-címére, egy érvényes felhasználónévre és a hozzá tartozó jelszóra. Ezeket az információkat a szolgáltatója a szerver aktiválásakor küldi el e-mailben, vagy a vezérlőpulton keresztül érheti el őket. A stabil ssh hozzáférés vps-hez alapfeltétele, hogy ezeket az adatokat biztonságos helyen tárolja, és soha ne ossza meg illetéktelenekkel. A csatlakozás folyamata némileg eltér attól függően, hogy milyen operációs rendszert használ a saját gépén, de a logikája mindenhol azonos.
Az első csatlakozáskor egy szokatlan üzenettel fog találkozni: a kliens megjeleníti a szerver “fingerprint” azonosítóját, és megkérdezi, hogy megbízik-e a gépben. Ez a szerver digitális ujjlenyomata. Ne kattintson automatikusan az igenre. Ez a lépés védi meg Önt a “Man-in-the-middle” típusú támadásoktól, ahol egy közbeékelődő fél próbálná ellopni az adatait. Ha egyszer elfogadta az azonosítót, a gép elmenti azt a known_hosts fájlba. Amennyiben a jövőben ez az azonosító váratlanul megváltozik, a rendszer figyelmeztetni fogja a potenciális veszélyre.
Csatlakozás Windows alatt: PuTTY és PowerShell
A Windows felhasználók számára a PuTTY 0.84-es verziója továbbra is a legnépszerűbb választás. A szoftver legnagyobb előnye a “Saved Sessions” funkció, amellyel elmentheti a szerver IP-címét, a portot és az egyéb beállításokat, így később egyetlen kattintással indíthatja a kapcsolatot. Ha modernebb megoldásra vágyik, a Windows Terminal és a beépített PowerShell már natívan támogatja az OpenSSH klienst. Itt nem kell külön szoftvert telepítenie, elég kiadnia a parancsot a terminálban. A jelszavas belépés helyett a professzionális SSH kulcsok beállítása javasolt, amely jelentősen növeli a biztonsági szintet.
Terminál használata Linux és macOS rendszereken
Linux és macOS alatt nincs szükség külső szoftverre, a natív terminál tökéletesen alkalmas a feladatra. A csatlakozáshoz használja az ssh felhasznalonev@ip-cim formátumot. Ha a szerver nem az alapértelmezett 22-es porton figyel, a -p kapcsolóval adhatja meg az újat. A napi munka megkönnyítéséhez érdemes létrehozni egy ~/.ssh/config fájlt. Ebben aliasokat rendelhet a szervereihez, így a hosszú IP-címek helyett elég lesz annyit beírnia: ssh vps-szerverem. Ez a módszer nemcsak gyorsabb, hanem segít elkerülni az elgépeléseket is. A nagy teljesítményű KVM VPS megoldásoknál ez a fajta automatizáció alapvető elvárás a rendszergazdák részéről.
Haladóbb feladatokhoz használhatja az X11 forwarding opciót a -X kapcsolóval, amivel grafikus alkalmazásokat futtathat a szerveren, miközben azok ablaka a saját gépén jelenik meg. Bár a VPS kezelése elsősorban parancssori feladat, bizonyos diagnosztikai eszközöknél ez a funkció rendkívül hasznos lehet. A stabil ssh hozzáférés vps-hez kiépítése után a következő lépés a biztonság megerősítése lesz, hogy szervere ellenálljon a folyamatos külső próbálkozásoknak.
Jelszó alapú vs. SSH kulcsos hitelesítés: Melyiket válasszuk?
A jelszó alapú hitelesítés ma már a leggyengébb láncszem a szerverbiztonságban. Mivel világszerte több mint 22 millió SSH szolgáltatás érhető el az interneten, az automatizált botnetek folyamatosan pásztázzák a hálózatot. Egy gyenge vagy közepes erősségű jelszó percek alatt áldozatul eshet egy brute-force támadásnak. A professzionális ssh hozzáférés vps-hez ezért 2026-ban már elképzelhetetlen kulcsalapú hitelesítés nélkül.
A technológia lényege az aszimmetrikus titkosítás. Generálunk egy kulcspárt, amely egy publikus és egy privát kulcsból áll. A publikus kulcsot a szerveren helyezzük el, ez funkcionál lakatként. A privát kulcsot, tehát magát a kulcsot, szigorúan a saját gépünkön őrizzük. A 2026-os ajánlások alapján az Ed25519 típusú kulcsok használata a standard. Ezek gyorsabbak és biztonságosabbak a korábbi RSA megoldásoknál. Egy ilyen kulcsot gyakorlatilag lehetetlen feltörni a jelenlegi számítási kapacitásokkal. A védelmet tovább fokozhatjuk egy passphrase, vagyis jelmondat megadásával. Ez kritikus plusz réteg. Ha valaki meg is szerzi a privát kulcsfájlt, a jelmondat ismerete nélkül az értéktelen marad számára.
SSH kulcspár generálása és telepítése
Windows környezetben a PuTTYgen 0.84-es verziója a legcélszerűbb eszköz. Itt egyszerűen kiválaszthatjuk az Ed25519 algoritmust, majd az egeret mozgatva generálhatjuk le az egyedi kulcsot. Linux vagy macOS alatt a terminálba írt ssh-keygen -t ed25519 parancs végzi el ugyanezt. A kulcs felmásolása a szerverre az ssh-copy-id user@szerver-ip paranccsal a legegyszerűbb. Ha ez nem érhető el, manuálisan is beilleszthetjük a publikus kulcs tartalmát a szerveren található ~/.ssh/authorized_keys fájlba. Ügyeljen a fájl jogosultságaira; a 600-as érték az elvárt, hogy más felhasználók ne olvashassák azt.
A jelszavas belépés teljes letiltása
Amint meggyőződött róla, hogy a kulcsalapú belépés hibátlanul működik, ideje véglegesen lezárni a hátsó kaput. Ehhez szerkessze a szerveren az /etc/ssh/sshd_config fájlt. Keresse meg a PasswordAuthentication sort, és állítsa az értékét no-ra. Ugyanezt tegye meg a ChallengeResponseAuthentication opcióval is. A módosítás után a sudo systemctl restart ssh paranccsal léptetheti életbe a változásokat. Ez a lépés drasztikusan csökkenti a támadási felületet, hiszen jelszóval többé senki, még Ön sem próbálkozhat. Egy stabil Linux VPS konfigurációja itt válik valóban profivá.
SSH biztonsági beállítások és gyakori hibák elhárítása
A szerver biztonsága nem egy statikus állapot, hanem folyamatos karbantartást igénylő folyamat. Az alapértelmezett 22-es port megváltoztatása gyakori vitatéma a szakemberek körében. Bár ez önmagában csupán látszólagos biztonság, a gyakorlatban drasztikusan csökkenti a log fájlok zaját. Ha az ssh hozzáférés vps-hez egy egyedi, magasabb porton keresztül történik, az automatizált botok többsége egyszerűen átugorja a szervert a szkennelés során, így Önnek kevesebb brute-force próbálkozással kell szembenéznie.
A védekezés következő szintje a Fail2ban telepítése és konfigurálása. Ez az eszköz aktívan figyeli a hitelesítési naplókat, és ha meghatározott számú sikertelen próbálkozást észlel egy adott IP-címről, automatikusan tiltja azt a tűzfalban. Ez a módszer rendkívül hatékony a tömeges támadások ellen. Emellett kritikus, hogy a konfigurációs fájlban kizárólag az SSH Protocol 2 használatát engedélyezze. Az 1-es verzió már régen elavult, és olyan sebezhetőségeket tartalmaz, amelyeket a modern támadóeszközök pillanatok alatt kihasználnak.
Gyakori hibaüzenetek és megoldásaik
A “Connection refused” hiba az egyik legbosszantóbb jelenség. Legtöbbször azt jelenti, hogy az SSH szolgáltatás leállt a szerveren, vagy a tűzfal blokkolja az adott portot. Ha nemrég változtatott portot, ellenőrizze, hogy az új portot engedélyezte-e az UFW vagy iptables szabályok között. A “Permission denied (publickey)” hiba ezzel szemben általában jogosultsági problémára utal. Győződjön meg róla, hogy a szerveren a .ssh mappa 700-as, míg az authorized_keys fájl 600-as jogosultsággal rendelkezik. Ha a “Host key verification failed” üzenetet látja, az általában a szerver újratelepítése után fordul elő. Ilyenkor a saját gépén a ssh-keygen -R [IP-cím] paranccsal törölheti a régi, érvénytelen azonosítót.
Haladó biztonsági lépések
A maximális védelem érdekében korlátozza az SSH elérést fix IP-címekre a tűzfal szintjén. Ha statikus IP-vel rendelkezik, beállíthatja, hogy a szerver csak az Ön hálózatából fogadjon kapcsolatokat. A kétfaktoros hitelesítés (2FA) bevezetése szintén javasolt. A Google Authenticator modul integrálásával még a privát kulcs esetleges ellopása esetén is szükség lesz egy egyszer használatos kódra a belépéshez. Végezetül érdemes az üres jelszavakat tiltani (PermitEmptyPasswords no), és beállítani egy rövid időkorlátot a tétlen munkamenetek lezárására.
Ha professzionális és biztonságos alapokra építené projektjét, válassza a nagy teljesítményű KVM VPS szolgáltatásunkat, ahol a technikai háttér stabilitása garantált.
Maximális kontroll és sebesség: SSH kezelés az aWh KVM VPS szerverein
A biztonságos ssh hozzáférés vps-hez nem csak a szoftveres beállításokon múlik. A mögöttes hardveres infrastruktúra alapvetően meghatározza a felhasználói élményt és a titkosítás hatékonyságát. Az aWh szerverein használt AMD Epyc processzorok dedikált hardveres gyorsítással kezelik a komplex kriptográfiai műveleteket. Ez a technológiai háttér garantálja, hogy a titkosított csatorna fenntartása minimális terhelést jelentsen a rendszernek. Így az összes értékes erőforrás az Ön alkalmazásai és projektjei számára marad szabadon, miközben a kapcsolat stabilitása kifogástalan marad.
A sebesség a terminálban is kritikus tényező. Az NVMe SSD tárolók villámgyors elérést biztosítanak a rendszernaplókhoz és a konfigurációs fájlokhoz, így a parancsok kimenetére soha nem kell várnia. Ha a biztonsági finomhangolás során véletlenül kizárná magát a szerverről a tűzfal beállításai miatt, az aWh ügyfélpanelében elérhető VNC konzol jelent mentőövet. Ezen a felületen keresztül közvetlen, böngésző alapú hozzáférést kap a gépéhez, így bármilyen hibát azonnal javíthat a terminálból. Ha a folyamat során bármikor elakadna, technikai tudásbázisunkkal és szakértő kollégáinkkal segítünk a megoldásban.
Miért válassz aWh VPS-t a projektjeidhez?
A KVM alapú virtualizáció biztosítja, hogy a lefoglalt erőforrásokhoz más felhasználó ne férhessen hozzá. Ez stabil és kiszámítható válaszidőt eredményez minden SSH munkamenet során. A Magyarországon található adatközpontunk rendkívül alacsony késleltetést (latency) kínál a hazai felhasználók számára. A terminálban gépelve nem fog tapasztalni zavaró akadást, a karakterek azonnal megjelennek a képernyőn. Legyen szó egy kisebb tesztkörnyezetről vagy egy nagy forgalmú vállalati rendszerről, a VPS szerver bérlés nálunk rugalmasan és skálázható módon valósul meg.
Automatizáció és jövőállóság
Az aWh infrastruktúrája a jövőálló megoldásokra épül. A stabil ssh hozzáférés vps-hez elengedhetetlen a modern DevOps folyamatok zökkenőmentes automatizálásához. Rendszereinket úgy optimalizáltuk, hogy a távoli parancsvégrehajtás során a legkisebb késleltetéssel dolgozhasson, legyen szó Ansible-ről vagy CI/CD folyamatokról. A több mint 10 éves piaci jelenlétünk és szakmai tapasztalatunk a garancia arra, hogy szerverei mindig elérhetőek és biztonságosak maradnak. Ne érje be kevesebbel, ha a projektjei biztonságáról van szó. Kezdje el a professzionális szerverkezelést még ma nálunk, és kérj ajánlatot VPS szerverre!
Építse fel szervere védelmét és élvezze a maximális sebességet
Az SSH kezelés elsajátítása az első lépés a professzionális szerveradminisztráció felé. Az útmutató legfontosabb tanulsága, hogy 2026-ban a jelszó alapú belépés már nem nyújt elegendő védelmet; a kulcsalapú hitelesítés és a többrétegű biztonsági beállítások alkalmazása alapvető elvárás. A stabil és gyors ssh hozzáférés vps-hez nem csupán a szoftveres konfiguráción, hanem a mögöttes, megbízható hardveres infrastruktúrán is múlik.
Az aWh-nál több mint 10 év szakmai tapasztalattal a hátunk mögött segítjük ügyfeleinket a digitális sikerek elérésében. Garantált KVM erőforrásaink és villámgyors NVMe SSD tárolóink biztosítják, hogy szervere minden körülmények között válaszkész és stabil maradjon. Ne kössön kompromisszumot a biztonság terén, válasszon olyan technológiai partnert, aki a legmodernebb AMD Epyc processzorokkal és szakértő támogatással áll az Ön rendelkezésére.
Fedezd fel nagy teljesítményű AMD Epyc VPS csomagjainkat!
Kezdje el a szerverkezelést magabiztosan, és élvezze a professzionális infrastruktúra adta teljes kontrollt és szabadságot!
Gyakran Ismételt Kérdések az SSH használatával kapcsolatban
Miért kapok “Connection timed out” hibaüzenetet csatlakozáskor?
A “Connection timed out” üzenet általában azt jelzi, hogy a hálózati kérés el sem jutott a szerverig, vagy a szerver nem küldött választ. Ennek leggyakoribb oka, hogy a szerver oldali tűzfal (például UFW vagy iptables) vagy egy köztes hálózati eszköz blokkolja a használt portot. Ellenőrizze, hogy a szerver IP-címe helyes-e, és a gép valóban fut-e.
Ha nemrég változtatta meg az alapértelmezett portot, győződjön meg róla, hogy az új portot engedélyezte a tűzfal szabályai között. Bizonyos vállalati vagy nyilvános hálózatok korlátozhatják a nem szabványos portokon keresztüli kimenő forgalmat, ami szintén okozhat ilyen típusú kapcsolódási hibát.
Milyen portot érdemes választani a 22-es helyett?
Érdemes az 1024 és 65535 közötti tartományból választani egy tetszőleges, korábban nem használt portot. Kerülje az olyan közismert portokat, mint a 8080, a 3306 vagy a 10000, mivel ezeket az automatizált támadószoftverek gyakran ugyanúgy szkennelik, mint a 22-est.
Egy egyedi, magasabb portszám használatával a botnetek brute-force próbálkozásainak jelentős része elkerülhető. Ez nemcsak a biztonságot növeli kismértékben, hanem tisztábbá teszi a naplófájlokat is, így könnyebben észreveheti a valódi, célzott behatolási kísérleteket.
Lehet-e egyszerre több SSH kulcsom is egy szerverhez?
Igen, egy szerverhez tetszőleges számú publikus kulcsot rendelhet hozzá. Ehhez mindössze annyit kell tennie, hogy minden egyes új publikus kulcs tartalmát külön sorba illeszti a szerveren található ~/.ssh/authorized_keys fájlban. A rendszer minden bejelentkezési kísérletnél végignézi a listát, és engedélyezi a belépést, ha a privát kulcs párosítható valamelyik sorral.
Ez a megoldás különösen hasznos, ha több adminisztrátornak kell hozzáférést biztosítani a rendszerhez, vagy ha különböző eszközeiről (például irodai gépről és laptopról) szeretne csatlakozni. Így minden eszközhöz saját kulcspárt rendelhet, ami növeli a biztonságot és a nyomonkövethetőséget.
Hogyan tudok fájlokat másolni SSH-n keresztül?
Fájlok biztonságos másolásához az SCP (Secure Copy) vagy az SFTP (SSH File Transfer Protocol) használata javasolt. A terminálban az scp fajlnev user@ip:/cel/utvonal parancs a leggyorsabb megoldás egyedi fájlok mozgatására. Ez a módszer ugyanazt a titkosított csatornát használja, mint maga az SSH kapcsolat.
Ha kényelmesebb, grafikus felületre van szüksége, használhat olyan klienseket, mint a WinSCP vagy a FileZilla. Ezek a szoftverek az SFTP protokollt alkalmazva lehetővé teszik a fájlok egyszerű drag-and-drop mozgatását, miközben a háttérben az SSH protokoll garantálja az adatátvitel biztonságát és sértetlenségét.
Mi a teendő, ha elhagytam a privát SSH kulcsomat?
Ha elvesztette a privát kulcsát, és a jelszavas belépést korábban letiltotta, az aWh ügyfélpanelén elérhető VNC konzol segítségével kaphat ismét hozzáférést. A konzol közvetlen, böngésző alapú elérést biztosít a szerverhez, ahol bejelentkezve törölheti a régi publikus kulcsot az authorized_keys fájlból, és hozzáadhat egy újonnan generáltat.
A biztonság érdekében az elveszett kulcsot tekintse kompromittáltnak, és azonnal távolítsa el az összes szerverről. Ha a kulcsot passphrase védte, az ad némi haladékot, de a végleges megoldás minden esetben az érintett kulcs visszavonása és egy új kulcspár létrehozása legyen.
Biztonságos-e az SSH használata nyilvános Wi-Fi hálózaton?
Az SSH használata biztonságosnak tekinthető nyilvános hálózatokon is, mert a protokoll az elejétől a végéig titkosítja a kommunikációt. A hálózat üzemeltetője vagy egy esetleges támadó láthatja, hogy Ön egy távoli szerverhez kapcsolódik, de a parancsokat, a válaszokat és a hitelesítési adatokat nem tudja lehallgatni vagy módosítani.
A maximális védelem érdekében ilyen környezetben is javasolt, hogy az ssh hozzáférés vps-hez kulcsalapú hitelesítéssel történjen. Egy erős jelmondat (passphrase) használata a privát kulcshoz további védelmet nyújt, ha valamilyen módon fizikai vagy szoftveres hozzáférést szereznének a saját gépéhez a nyilvános hálózaton keresztül.
Hogyan tudom ellenőrizni, hogy ki lépett be utoljára a szerverre?
A szerverre történt legutóbbi sikeres bejelentkezéseket a last parancs segítségével ellenőrizheti a terminálban. Ez a parancs kiolvassa a rendszer adatbázisából a felhasználóneveket, a forrás IP-címeket, valamint a munkamenetek kezdetét és időtartamát. Ha csak a legutóbbi próbálkozásokra kíváncsi, a last -n 10 parancsot érdemes használni.
A sikertelen belépési kísérletek és a részletesebb biztonsági események az /var/log/auth.log (Debian/Ubuntu) vagy az /var/log/secure (CentOS/RHEL) fájlokban találhatóak. Ezeket a naplókat rendszeresen érdemes átnézni, hogy időben észlelje a gyanús tevékenységeket vagy az ismétlődő támadási kísérleteket.
Szükséges-e állandóan futtatni az SSH klienst a gépemen?
Nem, az SSH klienst csak addig kell futtatnia, amíg aktívan dolgozik a távoli szerveren. Amint befejezte a feladatát és bezárja a terminálablakot vagy kiadja az exit parancsot, a kapcsolat megszakad, és a kliensprogram leáll. A szerver oldalon az SSH démon (sshd) továbbra is futni fog, várva a következő csatlakozást.
Amennyiben olyan hosszú folyamatot indít el, amelynek a kijelentkezés után is futnia kell, használjon olyan eszközöket, mint a screen vagy a tmux. Ezekkel a segédprogramokkal a munkamenet leválasztható (detach), így a parancsok futása akkor sem szakad meg, ha Ön bezárja az SSH klienst a saját számítógépén.