Die "veilige dop" SSH is 'n netwerkprotokol om 'n veilige verbinding tussen gashere te vestig, standaard op poort 22 (wat beter is om te verander). SSH-kliënte en SSH-bedieners is beskikbaar vir die meeste bedryfstelsels. Byna enige ander netwerkprotokol werk binne SSH, dit wil sê, jy kan op 'n afstand op 'n ander rekenaar werk, 'n oudiostroom of video oor 'n geënkripteerde kanaal oordra, ens. Buitendien, deur 'n SOCKS-instaanbediener op 'n afgeleë gasheer jy kan reeds namens hierdie afgeleë gasheer aan ander gashere koppel.

Stawing is deur wagwoord, maar ontwikkelaars en stelseladministrateurs gebruik tradisioneel SSH-sleutels. Die probleem is dat die geheime sleutel gesteel kan word. Die byvoeging van 'n wagwoordfrase beskerm teoreties teen diefstal van die geheime sleutel, maar in die praktyk, wanneer sleutels aangestuur en gekas word, kan steeds sonder bevestiging gebruik word. Twee-faktor-verifikasie los hierdie probleem op.

Hoe om twee-faktor-verifikasie te implementeer

Ontwikkelaars van Honeycomb het onlangs gepubliseer gedetailleerde instruksieshoe om die toepaslike infrastruktuur op die kliënt en bediener te implementeer.

Die instruksie neem aan dat jy 'n basiese gasheer het wat oop is vir die internet (bastion). Jy wil aan hierdie gasheer koppel vanaf skootrekenaars of rekenaars oor die internet, en toegang tot alle ander toestelle wat daaragter is. 2FA verseker dat 'n aanvaller nie dieselfde kan doen nie, selfs al kry hy toegang tot jou skootrekenaar, byvoorbeeld deur wanware te installeer.

Die eerste opsie is OTP

OTP - eenmalige digitale wagwoorde, wat in hierdie geval gebruik sal word vir SSH-verifikasie saam met die sleutel. Die ontwikkelaars skryf dat dit nie ideaal is nie, want 'n aanvaller kan 'n vals bastion oprig, jou OTP onderskep en dit gebruik. Maar dis beter as niks.

In hierdie geval word die volgende reëls na die Chef-konfigurasie aan die bedienerkant geskryf:

• metadata.rb
• attributes/default.rb (van attributes.rb)
• files/sshd
• recipes/default.rb (kopie van recipe.rb)
• templates/default/users.oath.erb

Enige OTP-toepassing is aan die kliëntkant geïnstalleer: Google Authenticator, Authy, Duo, Lastpass, brew install oath-toolkit of apt install oathtool openssl, dan word 'n ewekansige base16-string (sleutel) gegenereer. Dit word omgeskakel na die Base32-formaat wat deur mobiele waarmerkers gebruik word en direk in die toepassing ingevoer word.

As gevolg hiervan kan u aan die bastion koppel en seker maak dat dit nou nie net 'n wagwoordfrase benodig nie, maar ook 'n OTP-kode vir verifikasie:

➜ ssh -A bastion
Enter passphrase for key '[snip]': 
One-time password (OATH) for '[user]': 
Welcome to Ubuntu 18.04.1 LTS...

Die tweede opsie is hardeware-verifikasie

In hierdie geval hoef die gebruiker nie elke keer die OTP-kode in te voer nie, aangesien die tweede faktor die hardeware-toestel of biometrie is.

Hier is die Chef-konfigurasie 'n bietjie meer ingewikkeld, en die konfigurasie van kliënte hang af van die bedryfstelsel. Maar nadat al die stappe voltooi is, kan kliënte op MacOS verifikasie in SSH bevestig deur 'n wagwoordfrase te gebruik en 'n vinger op die sensor toe te pas (tweede faktor).

iOS- en Android-eienaars bevestig aanmelding deur een knoppie op jou slimfoon te druk. Dit is 'n spesiale tegnologie van Krypt.co wat selfs veiliger is as OTP.

Op Linux/ChromeOS is daar 'n opsie om met YubiKey USB-tokens te werk. Natuurlik kan 'n aanvaller jou teken steel, maar hy ken steeds nie die wagwoordfrase nie.

Bron: will.com