> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/rdm/da/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md). # Bedste praksis for OpenSSH-sikkerhed Følg bedste praksis for Open SSH-sikkerhed, herunder nøglebaseret godkendelse og deaktivering af adgangskodelogon, for at hærde installationer til fjernadgang. Selv om Open SSH er blevet normen for fjernadgang, udgør standardinstallationen stadig nogle sikkerhedsrisici. Denne vejledning foreslår måder at øge sikkerhedsniveauet for en Open SSH-installation betydeligt. ### Brug godkendelse med private/offentlige nøgler Det er nyttigt at bruge krypterede nøgler til godkendelse, da det fjerner behovet for at indtaste adgangskoder. Selv de mest opfindsomme hackere kan ikke blande sig eller snige sig ind i en session, og der er ikke længere forsøg på at knække adgangskoder. 1. Generer et par af offentlige/private nøgler med denne kommando: `$ ssh-keygen -t rsa`. Det opretter to filer i den (skjulte) mappe `~/.ssh`. Den private nøgle hedder `id_rsa`, og den offentlige hedder `id_rsa.pub`. 2. Vælg en adgangskode, der bruges til at låse den offentlige nøgle op ved hver forbindelse. De kan eventuelt tilføje en kryptering, der er beskyttet med en adgangssætning, når nøglen oprettes.

Det virker også at trykke på Enter uden at angive en adgangssætning. Vær dog opmærksom på, at oprettelse af en nøgle uden adgangssætning automatisk giver SSH-adgang til fjernserveren til enhver, der får adgang til Deres lokale maskine.

3. Kopiér den offentlige nøgle (`id_rsa.pub`) til serveren: ```` Scp –p id_rsa.pub remoteuser@remotehost: ```
The `remoteuser` should never be root. Select the default non-root user as `remoteuser` instead.
```` 4. Log på med SSH, og kopiér den offentlige nøgle til det rigtige sted: ``` ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout ``` 5. Slet derefter den offentlige nøgle fra serveren. Ellers tillader SSH-klienten ikke logon på serveren: ``` rm id_rsa.pub ``` 6. Angiv filtilladelser på serveren (disse to er påkrævede, hvis "StrictModes" er sat til ***yes***): ``` $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys ``` 7. Når De er logget på med nøglens adgangssætning, kan adgangskodegodkendelse deaktiveres helt. Det gør De ved at åbne filen `/etc/ssh/sshd_config` og tilføje følgende linjer: ``` # Disable password authentication forcing use of keys PasswordAuthentication no ``` ### Deaktiver godkendelse med brugernavn og adgangskode For helt at fjerne adgangskodebaseret godkendelse og gennemtvinge brugen af SSH-nøgler eller certifikater skal De opdatere SSH-konfigurationen ved at tilføje følgende linjer i filen `/etc/ssh/sshd_config`: ``` PasswordAuthentication no ChallengeResponseAuthentication no KbdInteractiveAuthentication no UsePAM no ``` Genstart derefter SSHD-tjenesten ved at angive enten `/etc/init.d/sshd restart` eller `service sshd restart`. Når det er gjort, bør serveren afvise alle logon med brugernavn/adgangskode og kun acceptere godkendelse via nøgle eller certifikat. ### Konfigurer interval for inaktiv timeout Der kan angives et interval for inaktiv timeout for at undgå en SSH-session uden opsyn. Det gør De ved at åbne filen `/etc/ssh/sshd_config` og tilføje følgende linje: ``` ClientAliveInterval 360 ClientAliveCountMax 0 ``` Intervallet for inaktiv timeout er i sekunder (360 sekunder = 6 minutter). Når intervallet er udløbet, logges inaktive brugere automatisk af. ### Deaktiver tomme adgangskoder Af hensyn til yderligere sikkerhed anbefales det at forhindre fjernlogon fra konti med tomme adgangskoder. Åbn filen `/etc/ssh/sshd_config`, og opdater følgende linje: ``` PermitEmptyPasswords no ``` ### Begræns SSH-adgang til nogle få brugere I tilfælde, hvor godkendelse med brugernavn/adgangskode ikke kan undgås, anbefales det at begrænse SSH-logon til kun visse brugere, der har brug for fjernadgang, og dermed minimere konsekvensen af brugere med svage adgangskoder. For at begrænse SSH-logon skal De åbne filen `/etc/ssh/sshd_config` og tilføje en `AllowUsers`-linje efterfulgt af listen over brugernavne adskilt med mellemrum: ``` AllowUsers user1 user2 ``` Genstart derefter SSHD-tjenesten ved at angive enten `/etc/init.d/sshd restart` eller `service sshd restart`. ### Deaktiver root-logon For at deaktivere root-logon skal De åbne filen `/etc/ssh/sshd_config`, mens De er logget på som root, og ændre linjen `#PermitRootLogin` til `PermitRootLogin no`. Sørg for at fjerne tegnet #. Ellers virker det ikke. Genstart derefter SSHD-tjenesten ved at angive enten `/etc/init.d/sshd restart` eller `service sshd restart`. ### Deaktiver svag cipher Åbn filen `/etc/ssh/sshd_config`, og tilføj disse linjer: ``` # Ciphers moderns Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com # KEX robusts KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384 # MAC moderns MACs hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com # Disable weak algorithms PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512 HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512 ``` Genstart derefter SSHD-tjenesten ved at angive enten `/etc/init.d/sshd restart` eller `service sshd restart`. ### Brug en ikke-standardport Langt de fleste hackere, der leder efter åbne SSH-servere, leder efter port 22, da SSH som standard lytter efter indgående forbindelser på den port. For at køre SSH på en anden port skal De åbne filen `/etc/ssh/sshd_config` og tilføje følgende linjer: ``` #Run SSH on a non standard port Port 2025 #Change me ``` Genstart derefter SSHD-tjenesten ved at angive enten `/etc/init.d/sshd restart` eller `service sshd restart`. Husk at ændre portvideresendelsen i Deres router og eventuelle nødvendige firewallregler. Det anbefales at informere klienter om eventuelle portændringer, så de ved, hvilken port de skal oprette forbindelse til, da SSH ikke længere lytter efter forbindelser på standardporten. ### Begræns SSH-eksponering med netværkskontroller Hvis det ikke er muligt at ændre SSH-porten, giver udrulning af en jump-server et stærkt Zero-Trust-kontrolpunkt mellem klienter og interne systemer. Den centraliserer godkendelse, håndhæver ensartede adgangspolitikker og forhindrer direkte eksponering af kritiske aktiver. Se [Remote Desktop Manager Jump (funktion)](https://docs.devolutions.net/agent/jump-host#configure-a-jump-host) for konfigurationstrin. ### Aktivér multifaktorgodkendelse Multifaktorgodkendelse er en af de vigtigste beskyttelser, der kan tilføjes SSH-servere for at beskytte dem mod uautoriseret adgang, da hvert brugerlogon skal knyttes til en konfigureret MFA-bruger. Selv hvis en hacker får fat i en adgangskode eller bryder ind på SSH-serveren, bliver vedkommende stadig blokeret af MFA. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.devolutions.net/rdm/da/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.