Először is, ha az a gép, amelyről a felhasználó belép fel van sorolva a /etc/hosts.equiv-ban vagy a /etc/ssh/shosts.equiv-ban a távoli gépen, és a felhasználói nevek megegyeznek mindkét oldalon, akkor rögtön beengedik.
Másodszor, ha a .rhosts vagy a .shosts fájl ott van a felhasználó home könyvtárában a távoli gépen és tartalmaz egy sort, amely a kliens gép nevét tartalmazza, a felhasználó beléphet. Az authentikációnak (authentication - hitelesítés, amikor bizonyítod, hogy az vagy, akinek mondod magad - a ford. megjegyzése) ezt a formáját általában nem engedélyezi a szerver, mert nem biztonságos.
A második (és elsődleges) lehetőség az authentikációra az rhosts vagy hosts.equiv módszer, RSA-alapú gép-authentikációval kombinálva. Ez azt jelenti, hogy a belépés csak akkor engedélyezett, ha a .rhosts, .shosts, /etc/hosts.equiv, vagy /etc/ssh/shosts.equiv, megengedi, és ezen kívül a kliens gép kulcsát ellenőrizni lehet (lásd a $HOME/.ssh/known_hosts és /etc/ssh/ssh_known_hosts-t a FÁJLOK részben). Ez az authentikációs módszer kizárja az ,,IP spoofing'', ,,DNS spoofing'' és a ,,routing spoofing'' által kihasznált biztonsági lyukakat. [Megjegyzés a rendszergazdáknak: a /etc/hosts.equiv, .rhosts, és az rlogin/rsh protokollok általában eredendően nem biztonságosak és le kell tiltani őket, ha a biztonság fontos szempont.]
Harmadik authentikációs módszerként az ssh támogatja az RSA alapú authentikációt. Az elrendezés a nyilvános kulcsú kriptográfián alapul: vannak olyan titkosítási rendszerek, ahol a titkosítás és visszafejtés különböző kulcsok használatával történik, és a visszafejtéshez használt kulcsot nem lehet a titkosításhoz használt kulcsból kikövetkeztetni. Az RSA egy ilyen rendszer. Az elgondolás az, hogy minden felhasználó készít egy nyilvános/privát kulcspárt authentikációs célokra. A szerver tudja a nyilvános kulcsot, de a privát kulcsot csak a felhasználó ismeri. A $HOME/.ssh/authorized_keys fájl tartalmazza azokat a nyilvános kulcsokat, amelyekkel be lehet lépni. Amikor a felhasználó be akar lépni, az ssh program megmondja a szervernek, hogy melyik kulcspárt akarja authentikációra felhasználni. A szerver ellenőrzi, hogy a kulcs engedélyezve van-e, és ha igen, akkor úgy teszi próbára a felhasználót (pontosabban az általa futtatott ssh programot), hogy egy véletlen számot küld el neki, amit a felhasználó nyilvános kulcsával titkosít. Ezt csak a megfelelő privát kulcs segítségével lehet visszafejteni. Ezután a felhasználó kliense visszafejti a privát kulccsal, így bebizonyítja, hogy ismeri a a privát kulcsot anélkül, hogy azt elküldené a szervernek.
Az ssh automatikusan alkalmazza az RSA authentikációs protokollt. A felhasználó az ssh-keygen(1) futattásával automatikusan létrehozza az ő RSA kulcspárját. Ezzel a privát kulcs a .ssh/identity-be kerül, míg a nyilvános kulcs a .ssh/identity.pub-ba, a felhasználó home könyvtárában. A felhasználónak ezután a saját identity.pub-ját a .ssh/authorized_keys-ba kell másolnia a home könyvtárában a távoli gépen (az authorized_keys fájl megfelelt a hagyományos .rhosts fájlnak, és soronként egy kulcsot tartalmaz, bár a sorok nagyon hosszúak lehetnek). Ezután a felhasználó beléphet, anélkül hogy a jelszavát megadná. Az RSA authentikáció sokkal biztonságosabb mint az rhosts authentikáció.
Az RSA authentikáció egy authentikációs közvetítő (agent) segítségével használható a legkényelmesebben. Lásd az ssh-agent(1)-et további információkért.
Egy negyedik authentikációs módszerként, az ssh támogatja a TIS authentikációs szerveren keresztüli authentikációt. Az elképzelés az, hogy az ssh megkéri a TIS authsrv(8)-et, hogy authentikálja a felhasználót. Előfordulhat, hogy a felhasználói nevek a TIS adatbázisban nem ugyanazok, mint a lokákis gépen, például ha a felhasználó egy smartcard-al vagy Digipass-al authentikálja magát. Ebben az esetben a felhasználói név az adatbázisban általában csak az authentikációs eszköz sorozatszámaként ismert. Az /etc/ssh/sshd_tis.map fájl tartalmazza a lokális felhasználók és a neki megfelelő TIS adatbázis-beli nevek közötti leképezést. Ha ez a fájl nem létezik, vagy a felhasználó nincs benne, akkor az ssh feltételezi, hogy a felhasználói név és a TIS adatbázis-beli név ugyanaz.
Ha a többi authentikációs módszer meghiúsul, az ssh jelszót kér a felhasználótól. A jelszót ellenőrzés céljából elküldi a távoli gépre, azonban mivel minden kommunikáció titkosítvavan, a jelszót nem olvashatja el valaki, aki a hálózaton hallgatózik.
Amikor a felhasználó azonosságát elfogadja a szerver, akkor vagy végrehajtja a megadott parancsot, vagy belép a gépbe, és a felhasználónak egy szokásos shell-t ad a távoli gépen. Minden, a távoli parancsal vagy shell-el történő kommunikáció automatikusan titkosítva lesz.
Ha egy pszeudo-terminál volt allokálva (normális login session), a felhasználó kiléphet a "~." parancs segítségével és felfüggesztheti az ssh-t ,,~Z'' vel.
Az összes forwardolt kapcsolatot ki lehet listázni egy ,,~#''-el, és ha a session a forwardolt X11 vagy TCP/IP kapcsolatok végetérésére várva blokkol, akkor ,,~&'' -el háttérbe lehet küldeni (Ezt nem szabad addig használni, amíg a felhasználó shellje aktív, mert akkor a shell ,,lógni'' fog). Az összes escape-szekvenciát ,,~?'' -el lehet kilistázni.
Egyetlen tilde (~) karaktert ,,~~'' -ként lehet elküldeni (vagy úgy, hogy a tildét a fentiekben nem említett karakter követi). Az escape karakter csak akkor van különleges karakterként interpretálva, ha újsort követ. Az escape karaktert meg lehet változtatni a konfigurációs fájlokban vagy a parancssorban. Ha az ssh nem foglal le egy pszeudo terminált, akkor a session átlátszó lesz, és lehet bináris adatok megbízható átvitelére használni. A legtöbb rendszerben az escape karakter ,,none''-ra (semmire) való állítása a sessiont átlátszóvá teszi akkor is, ha egy tty van használatban.
Egy session akkor ér véget, amikor a parancs végrehajtása vagy a shell a távoli gépen véget ér, és az összes X11 és TCP/IP kapcsolat lezárult. Az ssh a távoli program kilépési értékével (exit status) lép ki. Ha a felhasználó X11-et használ (a DISPLAY környezeti változó be van állítva), az X11 displayhez való kapcsolat automatikusan forwardolódik a távoli géphez, oly módon, hogy minden a shellből (vagy parancsból) indított X11 program a titkosított csatornán jön át, az igazi X szerverrel való kapcsolat pedig a lokális gépről jön létre. A felhasználónak nem kell kézzel beállítania a DISPLAY-t. Az X11 kapcsolatok forwardolásást a parancssoron vagy a konfigurációs fájlokban lehet beállítani.
Az ssh által beállított DISPLAY a szerver gépre mutat, de zérónál nagyobb display számmal. Ez azért van, mert az ssh egy ,,proxy'' X szervert állít fel a szerver gépen a kapcsolatok titkosított csatornán való továbbításához.
Az ssh automatikusan beállítja a szerveren az Xauthority adatokat is. Ehhez egy véletlenszerű authorizációs cookie-t generál, amit a szerveren tárol az Xauthority-ban, ellenőrzi, hogy az összes forwardolt kapcsolat ezzel a cookie-val jön-e, és kicseréli őket az igazi cookie-ra, amikor a kapcsolat megnyílik. Az igazi authentikációs cookie-t soha nem küldi el a szerver gépre, és semmilyen cookie-t nem küld el titkosítás nélkül.
Ha egy felhasználó egy authentikációs közvetítőt (agent) használ, akkor a közvetítőhöz való kapcsolatot automatikusan forwardolja a távoli gépre, hacsak ez nincs letiltva a parancssoron vagy egy konfigurációs fájlban.
Tetszőleges TCP/IP kapcsolatoknak a biztonságos csatornán való forwardolását a parancssoron vagy egy konfigurációs fájlban lehet megadni. A TCP/IP forwardolásnak egy lehetséges alkalmazása egy elektronikus pénztárcához való biztonságos kapcsolódás; egy másik a tűzfalakon való átjutás.
Az ssh automatikusan fenntart és ellenőriz egy adatbázist, amely tartalmazza az összes olyan gép RSA-alapú azonosítását, amellyel valaha is használva volt. Az adatbázis a .ssh/known_hosts-ban van, a felhasználó home könyvtárában. Ezenkívül az ismert gépeket a /etc/ssh/ssh_known_hosts-ban is leellenőrzi. Minden új gép automatikusan hozzáadódik a felhasználó fájljához. Ha egy gép nyilvános kulcsa megváltozik, az ssh figyelmeztet és megtiltja a jelszóval való belépést, nehogy a felhasználó jelszavát egy ,,trójai faló'' lopja el. Ennek a mechanizmusnak egy másik célja a ,,középen a támadó'' (man-in-the-middle attack) megakadályozása, amely egyébként meghiúsítaná a titkosítást. A StrictHostKeyChecking opciót (lásd az alábbiakban) lehet arra használni, hogy megakadályozzuk az olyan gépre való belépést, amelyeknek a kulcsa nem ismert vagy megváltozott.