SSH: transport, identiteter og sikker administrasjon

Secure Shell er en protokollfamilie for sikker fjerntilgang over et usikkert nettverk. SSH kombinerer tre oppgaver: Det etablerer en kryptert og integritetsbeskyttet transport, autentiserer først serveren og deretter brukeren eller arbeidsbelastningen, og multiplekser til slutt sheller, enkeltkommandoer, subsystemer og videresendinger som separate kanaler. Denne rekkefølgen er avgjørende for administratorer: En sterk brukernøkkel beskytter ikke dersom klienten tilbyr den til en ikke-verifisert server.

SSH er både protokoll og kontrollplan. En tilgang kan muliggjøre root-kommandoer, filoverføring, databasetunneler, agenttilgang og hoppveier inn i interne nettverk. Sikkerhetsvurderingen må derfor ikke stoppe ved lytterporten eller ved PasswordAuthentication no. Distribusjon av verts­nøkler, effektiv Match-policy, nøkkelopprinnelse, principals, videresendingsrettigheter, kildevei, sesjonslogging og gjenoppretting av tillitsankere hører til samme system.

Forklaringen følger en SSH-forbindelse fra TCP og versjonsutveksling via nøkkelutveksling og vertskontroll til brukerinnlogging og kanal. Videresendinger, nøkkeldrift, sertifikater og diagnostikk bygger på dette.

SSH bygger en autentisert, kryptert transport fra en usikker nettverksforbindelse, med separate kanaler for shell, kommandoer, filoverføring eller tunneler. Artikkelen følger nettopp denne rekkefølgen: serveridentitet, nøkkelutveksling, brukerinnlogging, kanaler og drift.

Protokollarkitektur

RFC 4251 deler SSH-2 inn i tre protokoller:

1. Transport Layer Protocol: Versjonsutveksling, algoritmeforhandling, Key Exchange, serverautentisering, kryptering og integritet.
2. User Authentication Protocol: Autentisering av en klientbruker mot serveren over den beskyttede transporten.
3. Connection Protocol: Multipleksing av logiske kanaler for sesjoner, portvideresending og andre tjenester.

Lagene kjører over en pålitelig bytestrøm, vanligvis TCP. TCP-port 22 er registrert hos IANA som ssh; reverse-proxyer, portvideresendinger og bastioner kan endre den faktiske veien (RFC 4251 – SSH-protokollarkitektur, IANA-registeret for tjenestenavn og portnumre).

Versjonsutveksling og algoritmeforhandling

Klient og server sender først identifikasjonsstrenger som SSH-2.0-.... Deretter utveksler de SSH_MSG_KEXINIT med ordnede lister for Key Exchange, verts­nøkkelalgoritme, kryptering i begge retninger, MAC, komprimering og språk. Det første felles alternativet i hver kategori velges. Algoritmelister er derfor policy og kompatibilitetsavtale, ikke bare en implementasjonsdetalj (RFC 4253 – SSH Transport Layer Protocol).

RFC 9142 oppdaterer anbefalingene for SSH-algoritmer. Den skiller mellom MUST, SHOULD, MAY, SHOULD NOT og MUST NOT for implementasjoner; en produksjonspolicy tar i tillegg hensyn til compliance, klientpark, maskinvare og migreringsvei (RFC 9142 – Key Exchange Method Recommendations for SSH).

Konfigurasjonslinjer som fastlåser en egen, rigid chifferliste, blir utdaterte. OpenSSH kan vise sine støttede algoritmer med ssh -Q og vise effektivt oppløst klient- eller serverkonfigurasjon. Driftsansvarlige fjerner kjente eldre metoder målrettet, men beholder en testet kompatibilitetsvei for apparater.

Key Exchange og sesjonsnøkler

Key Exchange genererer en felles hemmelighet og en utvekslingshash uten å sende sesjonsnøkkelen over nettet. Hashen binder identifikasjonsstrenger, KEXINIT-meldinger, serverens verts­nøkkel og algoritmespesifikke efemere verdier. Serveren signerer utvekslingshashen med verts­nøkkelen; klienten verifiserer dermed serveridentitet og nøkkelutveksling samlet (RFC 4253).

Moderne metoder bruker efemere Diffie-Hellman-varianter og gir Forward Secrecy for sesjonsnøkler. SSH kan rekeye under en forbindelse, for eksempel etter datamengde eller tid. Rekey og Connection Channels deler samme transport; problemer fremstår derfor som frys eller frakobling av tilsynelatende aktive sesjoner.

RFC 8308 definerer en generisk utvidelsesforhandling. OpenSSH bruker utvidelser blant annet for å kunngjøre serversignaturalgoritmer eller verts­nøkkeloppdateringer (RFC 8308 – Extension Negotiation in SSH). Strict Key Exchange beskytter den innledende sekvensen bedre mot uventede meldinger og ble standardisert etter Terrapin-analysen (RFC 9519 – Strict Key Exchange in SSH).

Etter valg av versjon og algoritmer må klienten først gjenkjenne serveren. Først når verts­nøkkelen er akseptert, gir den etterfølgende brukerinnloggingen mening.

Vertsnøkler: serveridentitet før brukeridentitet

Verts­nøkkelen identifiserer serveren eller en kontrollert servergruppe. Ved første kontakt har en klient uten forhåndsdistribuert tillitsanker ikke noe kryptografisk grunnlag for å vurdere det viste fingeravtrykket. «Accept new» automatiserer pinning for nye verter, men løser ikke sikker førstegangsdistribusjon.

OpenSSH lagrer kjente nøkler og markører i known_hosts. En endret nøkkel kan bety legitim rotasjon, nyinstallasjon, endret lastbalanseringspool eller et angrep. Advarselen «løses» ikke ved å slette linjen blindt; den nye nøkkelen kontrolleres via en uavhengig kilde og årsaken dokumenteres (ssh(1) – verifisering av verts­nøkkel, sshd(8)).

Tillitsmodeller for vertsidentitet

RFC 4255 definerer SSHFP-poster; uten DNSSEC kan de bare være en indikasjon, ikke et selvstendig tillitsanker (RFC 4255 – SSHFP Resource Records). OpenSSH-sertifikater binder offentlig nøkkel, serienummer, type, principals, gyldighet, Critical Options og Extensions med en CA-signatur (IETF-utkast – OpenSSH Certificate Format).

Resolve-DnsName og dig leser DNS; ssh-keyscan samler tilbudte nøkler, men autentiserer dem ikke. ssh-keygen beregner fingeravtrykk og søker i known_hosts. Kandidater tas først i bruk etter uavhengig verifisering.

Livssyklus og rotasjon for verts­nøkler

En server kan ha flere verts­nøkler for forskjellige algoritmer. Private verts­nøkler ligger bare på servere eller kontrollerte lastbalanseringskomponenter; sikkerhetskopier og kloner må ikke føre til utilsiktet delt identitet. Ved autoskalering passer en Host-CA ofte bedre enn kopierte private verts­nøkler.

En rotasjon omfatter:

1. å opprette og beskytte ny nøkkel eller nytt vertssertifikat;
2. å tilby den parallelt og distribuere fingeravtrykk/CA-tillit;
3. å kontrollere faktisk klientkompatibilitet og vertsprincipal;
4. å fjerne gammel nøkkel kontrollert;
5. å oppdatere inventar, tilbakekalling og Break Glass-dokumentasjon.

OpenSSH kan kunngjøre ekstra verts­nøkler etter vellykket autentisering via UpdateHostKeys. Dette forenkler rotasjon, men forutsetter at den eksisterende vertstilliten allerede er korrekt (ssh_config(5)).

Med beskyttet transport og bekreftet server begynner bruker- eller maskininnloggingen. Passord, offentlig nøkkel, sertifikat og andre metoder har ulike drifts- og gjenopprettingskrav.

User Authentication Protocol

Etter transporten ber klienten om tjenesten ssh-userauth. RFC 4252 definerer metodene publickey, password, hostbased og none; Keyboard-Interactive er spesifisert i RFC 4256. Serveren kan kreve ytterligere autentisering og oppgir tillatte neste metoder (RFC 4252 – SSH Authentication Protocol, RFC 4256 – Keyboard Interactive Authentication).

Autentiseringsmetode og autorisasjon er adskilt. En gyldig offentlig nøkkel kan tilordnes en konto via authorized_keys, katalogtjeneste, AuthorizedKeysCommand, sertifikatprincipals eller PAM. Deretter bestemmer Unix-rettigheter, sudo, SELinux/AppArmor, Windows-token og applikasjonspolicy de effektive rettighetene.

OpenSSH AuthenticationMethods kan tvinge kombinasjoner som publickey,keyboard-interactive:pam. Om dette er to uavhengige faktorer, avhenger av legitimasjonskilder og enhetsbinding. To metoder som begge kommer fra samme kompromitterte laptopagent, gir mindre uavhengighet enn syntaksen antyder (sshd_config(5)).

Public-key-metoder og nøkkeltyper

Ved autentisering med offentlig nøkkel sender klienten en signatur over sesjonsidentifikator og autentiseringsforespørsel; den private nøkkelen forlater ikke klienten. Serveren kontrollerer offentlig nøkkel, signatur og autorisasjon. RFC 8332 definerer RSA-signaturer med SHA-2 for SSH; nøkkeltypen ssh-rsa betegner historisk også SHA-1-signatursemantikk og må ikke likestilles med enhver bruk av en RSA-nøkkel (RFC 8332 – RSA Keys with SHA-2 Signatures).

RFC 8709 standardiserer Ed25519 og Ed448 for SSH. OpenSSH støtter i tillegg FIDO/U2F-baserte sk--nøkler, der den private nøkkelen er bundet til en sikkerhetsnøkkel og valgfritt krever brukertilstedeværelse eller -verifisering (RFC 8709 – Ed25519 and Ed448 for SSH, OpenSSH FIDO/U2F-støtte).

Valget følger klient-/serverkompatibilitet og trusselmodell. Nøkkellengde alene avgjør ikke sikkerheten: privat lagring, passfrase, agenttilgang, gyldighet, principal, tilbakekalling og autorisasjonsalternativer er like viktige.

ssh-add administrerer identiteter i agenten og kan teste signeringsevnen til en offentlig nøkkel. Get-Service viser Windows-agenttjenesten. Private nøkkelfiler og agentsockets får minimale ACL-er; eksemplene oppretter ingen sentrale CA- eller verts­nøkler.

authorized_keys som policyobjekt

En linje i authorized_keys kan ha alternativer foran nøkkelen. from=, command=, restrict, no-port-forwarding, no-agent-forwarding, no-X11-forwarding, no-pty, permitopen= og environment= begrenser bruken. restrict setter en defensiv pakke med alternativer; eksplisitte tillatelser kan følge (sshd(8) – AUTHORIZED_KEYS FILE FORMAT).

En nøkkel for sikkerhetskopiering eller distribusjon får ikke generell shelltilgang. Den bindes til kildenettverk, tvunget kommando og nødvendige videresendingsmål. Wrappere validerer argumenter som strukturert inndata og bruker ikke ukontrollert shellkonkatenering.

authorized_keys er distribuert konfigurasjon. Inventaret omfatter fingeravtrykk, eier, formål, målkontoer, kilde, utløp, siste bruk og tilbakekalling. Foreldreløse nøkler er langlivede legitimasjoner uten sentral oversikt.

OpenSSH-sertifikater og principals

OpenSSH-sertifikater er ikke X.509-sertifikater. En SSH-CA signerer en offentlig nøkkel med serienummer, Key ID, type, principals og gyldighetsvindu. Brukersertifikater autentiserer brukere mot servere; vertssertifikater autentiserer servere mot klienter. Critical Options må forstås, ellers avvises sertifikatet; Extensions gir funksjoner som PTY eller videresending (IETF-utkast – OpenSSH Certificate Format).

Sertifikater forkorter levetiden for legitimasjon og sentraliserer utstedelse, men eliminerer ikke autorisasjon. Servere angir med TrustedUserCAKeys og Authorized Principals hvilken CA og hvilke principals som gjelder for hvilken konto. Klienter binder en Host-CA i known_hosts til navnemønstre med @cert-authority.

grep og Select-String filtrerer bare den effektive klientkonfigurasjonen. Feilsøkingsutdata fra ssh -vvv kan inneholde brukernavn, stier, målinfrastruktur og tilbudte fingeravtrykk og behandles som sensitivt diagnoseartefakt.

ssh-agent og Agent Forwarding

En agent holder private nøkler eller signeringshåndtak opplåst og svarer på signeringsforespørsler via en lokal socket. Prosesser med tilgang til denne socketen kan misbruke agenten uten å eksportere den private nøkkelen. Passfrase og maskinvarenøkkel begrenser derfor ikke enhver kompromittering av agenten.

Agent Forwarding videresender agentkanalen til en ekstern vert. Root eller en kompromittert prosess på denne verten kan sende signeringsforespørsler under sesjonen. OpenSSH advarer uttrykkelig mot denne risikoen; ProxyJump transporterer forbindelsen gjennom en bastion uten å gjøre agentsocketen tilgjengelig der (ssh(1) – -A og -J).

Når et mål bare er tilgjengelig via en Jump Host, foretrekkes følgende modeller:

• ProxyJump/ProxyCommand uten lagring av legitimasjon på bastionen;
• kortlivede SSH-sertifikater med målspesifikke principals;
• separat nøkkel per tillitsdomene;
• kontrollert sesjonsmegling med revisjon dersom interaktivitet må formidles sentralt.

Etter vellykket innlogging åpner SSH logiske kanaler innenfor samme forbindelse. Shell, enkeltkommando, SFTP og portvideresending deler dermed transport og identitet, men forblir separate operasjoner.

Connection Protocol og kanaler

Etter vellykket autentisering åpner SSH logiske kanaler. RFC 4254 definerer windowing, kanaldata, forespørsler og typer. En sesjon kan be om en PTY, et shell, en enkelt exec-kommando eller et subsystem som SFTP. TCP-videresending åpner direct-tcpip- eller forwarded-tcpip-kanaler (RFC 4254 – SSH Connection Protocol).

Multipleksing lar flere klientforbindelser dele en eksisterende transport. Det reduserer KEX- og autentiseringskostnader, men øker virkningen av en kompromittert kontrollsocket. ControlPath, rettigheter, persistens og målbinding settes eksplisitt.

Keepalives har ulike nivåer: TCPKeepAlive kontrollerer TCP-veien, ServerAliveInterval/ClientAliveInterval bruker SSH-meldinger. De forhindrer ikke applikasjonsheng og kan avslutte sesjoner ved korte nettverksavbrudd dersom verdiene er aggressive.

Portvideresending og tillitsgrenser

Lokal videresending (-L) åpner en lytter på klientsiden og kobler fra servernettverket til målet. Ekstern videresending (-R) åpner en lytter på server- eller motsatt side. Dynamisk videresending (-D) tilbyr en SOCKS-proxy. Unix-socket-/Streamlocal-videresending supplerer TCP.

Videresending kan omgå segmentering. En bruker uten shellprivilegier kan likevel nå interne administrasjonsgrensesnitt eller databaser via en tillatt videresending. Servere styrer dette med AllowTcpForwarding, PermitOpen, PermitListen, GatewayPorts, Match-blokker og Authorized-Key-alternativer (sshd_config(5)).

Test-NetConnection og nc kontrollerer TCP-veien til bastionen. Get-NetTCPConnection og ss bekrefter den lokale lytteren. -N-tunnelen kjører ingen ekstern kommando; autorisasjon og mål-TLS forblir selvstendige grenser.

SFTP, SCP og filrettigheter

SFTP er en binær filoverføringsprotokoll som vanligvis kjører som SSH-subsystem. Det er ikke FTP over SSH. OpenSSH kan kjøre internal-sftp uten ekstern SFTP-serverbinærfil og begrense til filoverføring med ChrootDirectory pluss ForceCommand internal-sftp (sftp(1), sftp-server(8)).

scp-CLI-en brukte historisk den SCP/RCP-lignende eksterne protokollen og bruker i moderne OpenSSH-linjer SFTP som standard; -O tvinger eldre protokoll. Wildcards, ekstern shellbehandling og serverkompatibilitet varierer (scp(1)). Runbooks angir derfor CLI, protokollmodus og ønskede filmetadata eksplisitt.

Autorisasjon for filoverføring omfatter Chroot-eierskap, målbaner, UID/GID eller Windows-ACL-er, Umask, symlenker, kvote og atomisk plassering. Opplasting til en e-post- eller automatiseringskatalog trenger ofte en karantene-/omdøpingsgrense i stedet for direkte behandling av delvis skrevne filer.

Serversidepolicy og Match-blokker

sshd_config evalueres ovenfra og ned; for hvert nøkkelord gjelder i utgangspunktet den første mottatte verdien. Match endrer virkeområdet etter bruker, gruppe, vert, adresse, LocalAddress, LocalPort eller RDomain. Include-filer, distribusjonsstandarder og kommandolinjealternativer kan supplere den synlige hovedfilen (sshd_config(5)).

En robust basislinje fastsetter:

• tillatte brukere/grupper og kildenettverk;
• nødvendige autentiseringsmetoder og Break Glass-unntak;
• root-/administratoradgang og privilege escalation;
• videresending, agent, X11, PTY og subsystemer;
• MaxAuthTries, LoginGraceTime, sesjons-/startgrenser og keepalives;
• verts­nøkler, algoritmer og rekey;
• AuthorizedKeys-/Principals-kilder;
• logging, banner og miljøforutsetning;
• Match-spesifikke avvik.

Generelle «herdingslister» kan stenge ute apparater eller være virkningsløse dersom en senere akseptert Match-verdi gjelder annerledes. Det avgjørende er den effektive konfigurasjonen for en konkret forbindelse.

sshd -t validerer syntaks og nøkler, sshd -T -C viser effektiv konfigurasjon for testparametere (sshd(8)). Get-WinEvent og journalctl leser plattformloggene. En vellykket reload og en annen testet administratorsesjon skal gå forut for at den eksisterende sesjonen lukkes.

Brute force, rate limits og nettverksgrenser

Internet-eksponerte SSH-tjenester mottar automatiserte innloggingsforsøk. Kildefirewall, VPN/Zero-Trust-tilgang, bastion, AllowUsers/AllowGroups, sterk autentisering og kort levetid for legitimasjon reduserer angrepsflaten. En annen port reduserer loggstøy, men endrer verken autentisering eller sårbarhet.

Perimeterblokkeringsverktøy kan bremse gjentatte forsøk; de behandler upålitelige loggdata og trenger egne regler for allowlist, IPv6, NAT, lockout og recovery. OpenSSH MaxStartups begrenser ikke-autentiserte parallelle forbindelser probabilistisk, PerSourceMaxStartups og PerSourcePenalties kan ta hensyn til kildeadferd. Kapasitet og DoS-risiko testes under reelle proxy-/NAT-forhold (sshd_config(5)).

Logging, revisjon og sesjonsbevis

SSH-logger dokumenterer vanligvis forbindelseskilde, bruker, autentiseringsmetode/fingeravtrykk, sesjonsstart/-slutt og utvalgte subsystemhendelser. De inneholder ikke automatisk hver utførte shellkommando. Shellhistorikk er brukerkontrollert og ikke en manipulasjonssikret revisjon.

For privilegert administrasjon korreleres:

• kildeidentitet, enhet og tilgangsbeslutning før SSH;
• bastion-/proxyhopp og målvert;
• klientens avgjørelse for verts­nøkkel/CA;
• brukerprincipal, autentiseringsmetode, nøkkelfingeravtrykk eller sertifikatserie;
• sesjons-/kanaltype, start, slutt og exitstatus;
• sudo-/Windows-privilegiehendelser og revisjon av målsystemet;
• filoverføringsbane, hash eller endringssak ved sensitive distribusjoner.

Sesjonsopptak endrer personvern, hemmelighetsinnsamling og driftsrisiko. Passord, tokener, e-postinnhold og private nøkler må ikke havne ukontrollert i transkripsjoner. Oppbevaring, tilgang og manipulasjonsbeskyttelse defineres før aktivering.

Windows OpenSSH

Microsoft tilbyr OpenSSH Client og Server som Windows-funksjoner. Serveren bruker tjenesten sshd, konfigurasjonen under %ProgramData%\ssh\sshd_config, Windows-kontoer og ACL-er; logger kan vises i kanalen OpenSSH/Operational (Microsoft Learn – OpenSSH-oversikt, Microsoft Learn – OpenSSH Server-konfigurasjon).

Administratornøkler i Windows kan, avhengig av konfigurasjonen, ligge i en sentral administrators_authorized_keys-fil med strenge ACL-er. Shell, subsystemer, DefaultShell-registerverdien og baneoppløsning skiller seg fra Unix. En portabel klientkommando betyr ikke identisk serverautorisasjon.

Sikkerhetskopiering, gjenoppretting og Break Glass

SSH-recovery omfatter ikke bare sshd_config:

• verts­nøkler eller Host-CA med beskyttede private nøkler;
• User-CA, sertifikatutsteder, principals og tilbakekallingslister;
• Authorized Keys/Commands og deres kilde i katalog-/konfigurasjonsstyring;
• serverpolicy, Include-filer, PAM/SSSD/AD- og MFA-avhengigheter;
• firewall, bastion, DNS/SSHFP og tidskilde;
• Break Glass-konto med offline-verifisert legitimasjon;
• out-of-band-konsoll dersom nettverks-SSH svikter;
• revisjonslogger og nøkkel-/sertifikatinventar.

Gjenoppretting av den samme private verts­nøkkelen bevarer serveridentiteten, men kan være farlig etter kompromittering. Recovery velger derfor mellom kontinuitet og ny enrollment med rotasjon. En gjenopprettingstest bruker en isolert måladresse og kontrollerer vertsprincipal, autentiseringsmetoder, Match-policy, privilege escalation og loggkorrelasjon.

Diagnostikken leser forbindelsesoppsettet i rekkefølge: TCP, versjonsutveksling, Key Exchange, verts­nøkkel, brukerautentisering og kanalåpning.

Diagnostikk etter protokollfase

SSH forløper i klare faser. Den som først fastslår om TCP, nøkkelutveksling, vertskontroll, brukerinnlogging eller kanal er berørt, unngår målrettingsløse endringer i nøkler og serverkonfigurasjon.

En Permission denied (publickey) ligger etter vellykket transport og vertstillit. En timeout før banneret er ikke et nøkkelproblem. Faseorientert diagnostikk hindrer at legitimasjon eller algoritmelister endres uten bevis.

Teknisk historie

Tatu Ylönen utviklet den opprinnelige SSH i 1995 som erstatning for ukrypterte verktøy for fjerntilgang og filoverføring. SSH-1 og SSH-2 var grunnleggende forskjellige; IETF SECSH Working Group standardiserte senere SSH-2-arkitekturen i RFC 4251 til 4254 (OpenSSH – History, RFC 4251).

OpenSSH oppstod i OpenBSD-prosjektet fra fri SSH-kode og ble portert til andre operativsystemer. Det samlet klient, server, nøkkelverktøy, agent, SCP og SFTP og preget mange de facto-utvidelser som eget sertifikatformat (OpenSSH Project).

Kryptografien utviklet seg fra eldre kombinasjoner av Diffie-Hellman, DSA, RSA/SHA-1, CBC og separate MAC-er til Curve25519/ECDH, Ed25519, RSA/SHA-2 og AEAD-metoder. Samtidig gikk driftstilliten fra manuelt distribuerte enkeltnøkler til maskinvareautentikatorer, Host-/User-CA-er, kortlivede sertifikater og identitetsbaserte bastioner. Protokollagene forble gjenkjennelige; tillits- og livssyklusdrift ble mer omfattende.

Admin-sjekkliste på ett sted

Sjekklisten oppsummerer forbindelsesvei, vertstillit, brukerrettigheter, nøkkeldrift og logging. Den egner seg for godkjenning og regelmessig kontroll av SSH-tilgang.

Kilder

• RFC 4251 – SSH-protokollarkitektur
• IANA-registeret for tjenestenavn og portnumre
• RFC 4253 – SSH Transport Layer Protocol
• RFC 9142 – Key Exchange Method Recommendations for SSH
• RFC 8308 – Extension Negotiation in SSH
• RFC 9519 – Strict Key Exchange in SSH
• ssh(1)
• sshd(8)
• RFC 4255 – SSHFP Resource Records
• IETF-utkast – OpenSSH Certificate Format
• Microsoft Learn – Resolve-DnsName
• BIND 9 – dig
• ssh-keyscan(1)
• ssh-keygen(1)
• ssh_config(5)
• RFC 4252 – SSH Authentication Protocol
• RFC 4256 – Keyboard Interactive Authentication
• sshd_config(5)
• RFC 8332 – RSA Keys with SHA-2 Signatures
• RFC 8709 – Ed25519 and Ed448 for SSH
• OpenSSH FIDO/U2F-støtte
• ssh-add(1)
• Microsoft Learn – Get-Service
• GNU grep-manual
• Microsoft Learn – Select-String
• RFC 4254 – SSH Connection Protocol
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc
• Microsoft Learn – Get-NetTCPConnection
• ss(8)
• sftp(1)
• sftp-server(8)
• scp(1)
• Microsoft Learn – Get-WinEvent
• systemd – journalctl
• Microsoft Learn – OpenSSH-oversikt
• Microsoft Learn – OpenSSH Server-konfigurasjon
• OpenSSH – History
• OpenSSH Project