Koppla AI till servern: så driftsätter och hanterar en AI-agent din server

De flesta använder än så länge AI som en mycket beläst kollega i telefon: man beskriver ett serverproblem, får ett kommando föreslaget, kopierar in det i konsolen, kopierar tillbaka felmeddelandet och upprepar proceduren tills det fungerar. Så snart du kopplar AI:n till din server försvinner den omvägen. En AI-agent som Claude Code, OpenAI Codex CLI eller Gemini CLI loggar själv in på servern via SSH, läser loggarna, kontrollerar konfigurationen, lägger in ändringar, testar resultatet och skriver ned vad den har gjort. Du anger uppgiften och godkänner de steg som inte går att ångra.

Den här artikeln är en erfarenhetsrapport. Hos KernelHost har en AI-agent i flera månader arbetat varje dag med vår egen infrastruktur: kundportal, övervakning, betalflöden, dokumentation. Vi visar hur anslutningen mellan agent och server är uppbyggd, vilket arbetsflöde agenten följer när den driftsätter på produktionssystem, vilka regler som förhindrar att något går snett eller läcker ut, och vad en server behöver ha för att det hela ska fungera. Grunderna om verktyg och arkitekturer finns i artikeln AI-hanterad server: koppla AI-agenter säkert, installationen på servern i guiden för Claude Code och Codex CLI.

Koppla AI till servern: vad det innebär

Att koppla en AI till servern innebär att ge en AI-agent en egen, kontrollerad åtkomst till serverns kommandorad, oftast via en SSH-nyckel. Från och med då kan agenten inte bara föreslå kommandon utan också köra dem själv, läsa utdatan och härleda nästa steg ur den. Själva språkmodellen körs fortfarande hos leverantören (Anthropic, OpenAI eller Google). På din dator eller server körs bara ett lätt kommandoradsverktyg som skickar kommandona.

Det avgörande ordet är ”kontrollerad”. En agent med serveråtkomst är ingen autopilot utan en mycket snabb medarbetare som frågar före varje ingripande åtgärd. Hur mycket den får göra utan att fråga bestämmer du själv: från ren läsåtkomst till att på egen hand installera uppdateringar enligt ett fast arbetsflöde.

Chattbot eller agent: skillnaden i en tabell

En halvtimmes fram och tillbaka blir på så sätt ofta några få minuter, och felkällan ”felskrivet” försvinner helt.

Vad en AI-agent gör på servern: exempel från vår drift

Följande exempel kommer från vår vardag. Namn, adresser och inloggningsuppgifter har vi utelämnat, arbetsflödena är äkta.

Driftsättningar med backup och väg tillbaka

När vi ändrar något i kundportalen eller i ett serverskript sköter agenten driftsättningen. Först jämför den filen på servern med den senast kända versionen, så att den inte skriver över någon annans ändring. Sedan skapar den en daterad backup utanför webbkatalogen, skriver ett återställningsskript, kontrollerar syntaxen i den nya filen, lägger in den med samma ägare och rättigheter som tidigare och testar därefter den berörda funktionen. Först när allt är grönt rapporterar den att arbetet är klart. Det exakta arbetsflödet beskrivs längre ned i avsnittet om driftsättning.

Felsökning: från symptom till orsak på några minuter

”Från vårt kontor går webbplatsen inte att nå, men på språng fungerar den.” Förr hade det inneburit ett längre letande. Agenten kontrollerar brandväggsreglerna, söker igenom skyddsprogramvarans loggar efter kontorets adress, hittar regeln som slog till och förklarar vilken förfrågan som utlöste den. Beslutet om vad som ska göras fattar fortfarande vi, detektivarbetet gör agenten. Vid typiska webbserverfel som 502 Bad Gateway eller fulla diskar arbetar den på samma sätt: den läser loggarna med journalctl och går igenom applikationsloggarna, ställer upp en hypotes och belägger den innan den ändrar något.

Övervakning som agenten bygger själv

En stor del av vår övervakning har vuxit fram i samarbete med agenten: små kontrollskript som med några minuters mellanrum testar en tjänst från början till slut via ett cronjobb och skickar ett meddelande till mobilen när något går fel, till exempel via en Telegram-bot. Agenten skriver skriptet, testar det med ett avsiktligt framkallat fel, sätter upp cronjobbet och dokumenterar hur man tystar larmet. Hur du i grunden bygger upp något sådant beskrivs i artikeln Sätt upp serverövervakning.

Översikter och städning

Vilka servrar körs fortfarande trots att det tillhörande avtalet är uppsagt? Vilka tilläggstjänster betalas men används inte längre? Sådana frågor besvarar agenten genom att enbart läsa från databaser och API:er och sammanställa resultatet i en tabell. Städa får den först efter godkännande, och innan dess kontrollerar den om maskinen verkligen är oanvänd, till exempel utifrån datatrafiken de senaste dagarna.

Dokumentation som växer av sig själv

Varje ändring avslutas med en post i ändringsloggen och vid behov ett tillägg i drifthandboken. Det kostar agenten sekunder och sparar oss timmar senare, eftersom frågan ”Varför är det egentligen så här?” har ett skriftligt svar.

Fördelarna när AI:n arbetar direkt på servern

• Snabbhet: Agenten läser på sekunder det som tar minuter för en människa och prövar en hypotes direkt i stället för att först beskriva den.
• Grundlighet: Den läser hela konfigurationen med alla inkluderade filer och loggraderna runt felet, inte bara det utdrag som någon ansåg vara relevant.
• Konsekvent arbetsflöde: Backup, syntaxkontroll och verifiering görs varje gång, även en fredagskväll och även vid den tjugonde lilla ändringen.
• Dokumentation utan extra arbete: Varje ändring är beskriven, med orsak, var backupen ligger och vägen tillbaka.
• Automatisering utan skriptstudier: Kontrollskript, cronjobb och rapporter tas fram utifrån en beskrivning på vanligt språk och testas innan de tas i bruk.
• Lärande på köpet: Agenten förklarar vad den gör och varför. Den som följer med förstår sin server betydligt bättre efter några veckor.

Tre arkitekturer och vilken vi använder

Det finns tre beprövade sätt att koppla en agent till en server. De skiljer sig åt i var verktyget körs och var inloggningsuppgifterna ligger.

Vårt val: agenten på arbetsstationen, servrarna via SSH

Vi arbetar med den första varianten. Agenten körs på arbetsdatorn, varje server har en post i SSH-konfigurationen och agenten ansluter med en egen nyckel. Det viktigaste skälet: vi sköter många system, och just på det här sättet kan en enda agent följa en orsak över flera servrar i en och samma session, till exempel från webbservern via databasen till brandväggen. Dessutom ligger inloggningen hos AI-leverantören och nycklarna på ett ställe som vi ändå skyddar. Den som bara har en server och vill ha automatiska rapporter nattetid klarar sig bra med den andra varianten. Mer om för- och nackdelarna finns i artikeln om AI-hanterad server.

Guide: koppla en AI-agent till servern via SSH

Följande sju steg fungerar på samma sätt med Claude Code, Codex CLI och Gemini CLI. Exemplen använder dokumentationsadressen 203.0.113.10 och användarnamnet deploy; ersätt båda med dina egna värden. En förutsättning är en server med inloggning via SSH-nyckel, så som beskrivs i artikeln Säkra SSH och sätt upp nyckelinloggning.

Steg 1: skapa en egen SSH-nyckel enbart för agenten

Agenten får aldrig din personliga nyckel, utan en egen. Då kan du när som helst dra in dess åtkomst utan att förlora din egen, och i loggarna syns vilken inloggning som kom från agenten.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 ger korta nycklar, är snabb och anses säker. Kommentaren ki-agent dyker senare upp i serverns authorized_keys och gör nyckeln lätt att känna igen med en gång.

Steg 2: lägg in den publika nyckeln på servern

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Om du vill begränsa åtkomsten ytterligare lägger du till alternativ framför nyckeln i filen ~/.ssh/authorized_keys på servern. from= tillåter inloggning bara från en viss adress, och no-agent-forwarding och no-port-forwarding förhindrar att anslutningen används som språngbräda:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Om servern därefter svarar med Permission denied (publickey) hjälper artikeln Åtgärda SSH Permission denied (publickey).

Steg 3: skapa ett host-alias i SSH-konfigurationen

Ett alias gör att agenten bara behöver känna till ett kort namn och alltid använder rätt nyckel:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Därefter räcker det med ssh web-prod "systemctl status nginx". IdentitiesOnly yes förhindrar att SSH provar andra nycklar från din nyckelring. För varje ytterligare server skapar du ett eget block, för test- och produktionssystem helst med olika namn som web-test och web-prod, så att en förväxling syns redan på namnet.

Steg 4: installera agenten och logga in

Claude Code, Codex CLI och Gemini CLI körs på Linux, macOS och Windows, och du loggar in med ett konto hos leverantören eller med en API-nyckel. Installationen och inloggningen utan webbläsare beskrivs i steg-för-steg-guiden. För arbetsstationsvarianten installerar du verktyget på din dator, inte på servern.

Steg 5: bestäm reglerna som agenten följer

Alla tre verktygen läser vid start en regelfil i arbetskatalogen: Claude Code läser CLAUDE.md, Codex CLI AGENTS.md och Gemini CLI GEMINI.md. Där står hur arbetet på dina servrar går till. En beprövad början:

# Regler för arbete på servrar

- Skapa före varje ändring en daterad backup utanför webbkatalogen.
- Kontrollera syntaxen före driftsättning (nginx -t, php -l, apachectl configtest).
- Kontrollera efter driftsättning tjänst, logg och funktion och rapportera resultatet.
- Visa aldrig lösenord, API-nycklar eller tokens, kopiera dem aldrig till filer.
- Borttagningar, databasändringar och allt oåterkalleligt bara efter uttryckligt godkännande.
- Ändra inte direkt i filer som kontrollpanelen hanterar.
- Ta bort testfiler igen efter testet.

Reglerna växer med tiden. Varje gång agenten gör något på ett annat sätt än du vill, ska korrigeringen föras in som en regel i den här filen. Efter några veckor arbetar den så som du själv skulle ha arbetat.

Steg 6: ställ in godkännanden och tillåtelselista

Som standard frågar verktygen före varje kommando som ändrar något. I början är det precis rätt. Läsande kommandon som du hela tiden bekräftar kan du i stället tillåta. I Claude Code görs det i filen .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Allt som inte står på den här listan kräver fortfarande ditt godkännande. Flaggor som stänger av alla frågor hör på sin höjd hemma på en testmaskin för engångsbruk.

Steg 7: den första uppgiften: bara läsa

Börja med uppgifter som inte kan ändra något och se hur agenten går till väga:

Kontrollera nginx-felen på web-prod under de senaste 24 timmarna och ange de tre
vanligaste orsakerna med ett belägg ur loggen för var och en. Ändra ingenting.

Först när analyserna stämmer följer små ändringar, till exempel en ny loggrotation eller en systemd-tjänst, och först därefter driftsättningar på produktionssystemet.

Så driftsätter agenten: vårt arbetsflöde för varje ändring i produktionssystemet

En AI-agent får bara driftsätta på ett produktionssystem enligt ett fast arbetsflöde som omfattar en backup, en förberedd väg tillbaka och en kontroll före och efter driftsättningen. Hos oss ser arbetsflödet ut så här:

1. Kontrollera nuläget. Filen på servern jämförs med den senast kända versionen. Har någon annan ändrat den under tiden avbryter agenten och frågar, i stället för att skriva över den andres ändring.
2. Skapa en backup. De berörda filerna hamnar med datum i en backupkatalog utanför webbkatalogen. En backup i webbkatalogen skulle under vissa omständigheter kunna hämtas av vem som helst.
3. Förbered vägen tillbaka. Ett litet skript som återställer det gamla läget med ett enda kommando skrivs före ändringen, inte först när nödläget är ett faktum.
4. Kontrollera syntaxen. Den nya filen kontrolleras innan den läggs in, för PHP med php -l, för nginx med nginx -t. På så sätt når ett syntaxfel aldrig ens produktionssystemet.
5. Lägg in filen med korrekta rättigheter. Ägare, grupp och filrättigheter tas över från den gamla versionen. Efter syntaxfel är felaktiga rättigheter den vanligaste orsaken till avbrott efter en uppdatering.
6. Testa utan bieffekter. Tester görs läsande, med påhittade testdata eller i en isolerad miljö, aldrig med riktiga beställningar eller riktiga kunddata.
7. Kontrollera live. HTTP-status, fellogg och den ändrade funktionen kontrolleras efter driftsättningen.
8. Dokumentera. Ändringsloggen och drifthandboken kompletteras, med var backupen ligger och kommandot för vägen tillbaka.

Som kommandosekvens, med platshållare i stället för riktiga sökvägar, ser det ungefär ut så här:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Varför vägen tillbaka skapas före ändringen

När något har gått fel är ingen i bästa form för att tänka ut en ren väg tillbaka. Ligger skriptet redan klart tar återställningen bara sekunder, och agenten kan också köra den själv om kontrollen efter driftsättningen misslyckas. Det är den största skillnaden mellan en agent som ”bara snabbt” ändrar något och en som man anförtror ett produktionssystem.

Tester som inte kan förstöra något

Många funktioner går inte att testa utan att något händer: en beställning, en betalning, ett e-postmeddelande. Här hjälper tre tekniker. För det första torrkörningar som verktyget självt erbjuder. För det andra påhittade identifierare som garanterat inte finns någonstans. För det tredje en isolerad miljö: en process som körs i en egen nätverksnamnrymd utan nätverk (unshare -n) kan varken nå ett externt gränssnitt eller av misstag köpa något, men ser fortfarande den lokala databasen via Unix-socketen. Efter testet tas alla testfiler bort igen.

Åtgärder som kostar pengar behöver ett lås

När ett arbetsflöde beställer, fakturerar eller raderar något får det inte köras två gånger samtidigt, inte heller när någon dubbelklickar eller agenten upprepar ett kommando. Den enklaste lösningen på Linux är flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "körs redan"

I databasapplikationer fyller ett namngivet lås (GET_LOCK i MySQL och MariaDB) samma funktion, i API:er en Idempotency-Key. Mer om det i avsnittet om KernelHost API längre ned.

Säkerhet: åtkomst för agenten utan att något läcker ut

Den oro vi oftast hör är: ”Och vad händer med mina data?” Det ärliga svaret: allt som agenten läser skickar den till leverantörens språkmodell för bearbetning. Därför avgör du med följande regler vad den över huvud taget får se.

Hemligheter hör inte hemma i chatten

Lösenord, API-nycklar och tokens skrivs aldrig in i en uppgift och skrivs aldrig ut av agenten. Skript läser dem från filer med rättigheterna 600, som agenten inte behöver visa för att kunna använda skriptet. Hamnar en nyckel ändå i chatten spärras den omedelbart hos leverantören och en ny skapas. Inte heller fragment hör hemma i chatten: de första tecknen i en nyckel hjälper ingen vid felsökning, men de förkortar en angripares arbete.

Egna nycklar, egna rättigheter, när som helst återkalleliga

Varje agent får en egen SSH-nyckel, och varje nyckel känns igen på sin kommentar i authorized_keys. Vill du dra in åtkomsten raderar du just den raden. Där det räcker arbetar agenten med en egen användare och en sudo-regel som bara tillåter de nödvändiga kommandona. API:er får egna nycklar med minsta möjliga rättigheter, för rena analyser bara läsrättighet.

Godkännanden: det som aldrig sker utan en människa

Utan uttryckligt godkännande får agenten hos oss inte radera något, inte skriva i databaser, inte lätta på brandväggs- eller skyddsregler, inte stoppa maskiner och inte beställa något. Verktygen stöder detta: Claude Code stoppar ingripande åtgärder och kan dessutom ställas in så att ett säkerhetsfilter känner igen riskabla kommandon och blockerar dem tills de har godkänts. Från vår vardag: det här filtret har mer än en gång stoppat en åtgärd som var sakligt riktig men helt enkelt oåterkallelig. Den kördes först efter att en människa uttryckligen hade godkänt den. Precis så ska det vara.

Spårbarhet: logg, ändringslista, backuper

Varje session lämnar spår som en människa kan läsa: de daterade backuperna, återställningsskriptet, posten i ändringsloggen och inloggningarna i systemloggen. Den som dessutom versionshanterar /etc i Git med etckeeper ser varje konfigurationsändring som en diff. Det som inte är spårbart kan inte heller rullas tillbaka. Grunden är fortfarande en fungerande backupstrategi, för en agent ersätter ingen backup.

Vilken server passar för en AI-agent?

En server för AI-stödd administration behöver full rootåtkomst, inloggning med SSH-nyckel, obehindrade utgående anslutningar, permanent DDoS-skydd och helst ett API genom vilket servrar kan beställas och styras automatiskt. Någon GPU behöver den inte, eftersom språkmodellen körs hos leverantören.

Varför KernelHost för AI-hanterade servrar

I princip kan en AI-agent arbeta med vilken server som helst där den får ett skal. I praktiken avgör dock miljön hur mycket arbete du verkligen kan lämna över till den. På en KVM-rootserver eller dedikerad server från KernelHost finns inga begränsade konton, inga hinder för HTTPS-anslutningarna till AI-leverantörerna och ingen avtalsbindning som gör det dyrt att prova sig fram. Det permanenta DDoS-skyddet är aktivt på varje server utan extra kostnad, och för beräkningsintensiva uppgifter finns Professional VDS med dedikerade kärnor. Debiteringen sker PrePaid: inget avtal, ingen bindningstid, ingen startavgift. Den som vill prova först börjar med den kostnadsfria testservern.

KernelHost API: din agent beställer och styr servrar själv

Den största hävstången finns en nivå ovanför den enskilda servern. Via KernelHost API kan en agent hämta produkter och priser, beställa servrar, läsa status för sina tjänster, starta, stoppa och starta om servrar samt säga upp tjänster och återkalla uppsägningar. Därmed blir ”Sätt upp en testserver åt mig” en enda uppgift: agenten beställer maskinen, väntar på leveransen, ansluter via SSH, installerar applikationen och rapporterar tillbaka adressen.

API:et är medvetet försiktigt utformat för att användas av agenter. API-nycklar får bara de rättigheter de behöver, och en nyckel för analyser kan inte beställa någonting alls. En Idempotency-Key ser till att en beställning som agenten upprepar efter ett timeout-fel inte utförs två gånger. Förfrågningar är begränsade per nyckel, per konto och per adress, så att inte ens en agent i en oändlig slinga kan utlösa en lavin. Och varje hämtning av inloggningsuppgifter utlöser en avisering via e-post, så att du ser när en agent har läst inloggningsuppgifter.

Vad kostar en AI-hanterad server?

Det tillkommer två kostnadsposter. För det första själva servern: för en agent som arbetar via SSH behövs ingen särskild utrustning, det räcker med vilken rootserver som helst som din applikation redan körs på. Körs agenten direkt på servern behöver verktyget självt bara några hundra megabyte arbetsminne, och en rootserver med 2 vCPU och 4 GB RAM räcker om inte mycket annat körs på den. För det andra språkmodellen: antingen ett abonnemang hos leverantören som inkluderar användningen av kommandoradsverktyget, eller en API-nyckel som debiteras efter förbrukning. Vid daglig intensiv användning är abonnemanget oftast billigare. För automatiserade uppgifter utan människa framför är API-nyckeln den rena vägen, eftersom den kan begränsas med en månadsbudget. Aktuella serverpriser hittar du på sidan Hyra rootserver.

Vanliga misstag och hur du undviker dem

• Agenten arbetar med administratörens personliga nyckel. Då går dess åtkomst varken att dra in separat eller att skilja ut i loggarna. Lösning: en egen nyckel med en egen kommentar.
• Alla frågor är avstängda. Det sparar klick den första dagen och kostar förr eller senare en server. Lösning: tillåtelselista för läsande kommandon, godkännande för allt som ingriper.
• Ingen backup före ändringen. Lösning: backup och återställningsskript som fast regel i CLAUDE.md eller AGENTS.md.
• Backuper i webbkatalogen. En fil som config.php.bak i webbroten kan vara publikt åtkomlig, databaslösenordet inräknat. Lösning: en backupkatalog utanför webbkatalogen med rättigheterna 700.
• Hemligheter i prompten. Lösning: inloggningsuppgifter bara i filer med rättigheterna 600 som skripten läser, och vid ett misstag genast skapa nya.
• Dubbel körning. Ett dubbelklick eller en upprepad förfrågan beställer två gånger. Lösning: lås med flock eller Idempotency-Key.
• Filer som kontrollpanelen hanterar har ändrats direkt. Panelen skriver över dem vid nästa uppdatering eller slutar fungera på grund av dem. Lösning: undanta sådana filer i reglerna och gör ändringar via panelen eller dess gränssnitt.
• Utdata godtas utan kontroll. En agent som inte förstår utdata gissar. Lösning: kräv belägg (”visa mig loggraden”) och låt resultaten kontrolleras live.

Kort sammanfattning

• Att koppla en AI till servern innebär att ge en agent som Claude Code, Codex CLI eller Gemini CLI en egen SSH-nyckel och tydliga regler.
• Agenten läser loggar, lägger in ändringar, kontrollerar resultatet och dokumenterar det. Ingripande steg körs bara med godkännande.
• Varje driftsättning följer ett fast arbetsflöde: kontrollera nuläget, ta backup, förbered vägen tillbaka, kontrollera syntaxen, lägg in, testa, kontrollera live, dokumentera.
• Hemligheter hör aldrig hemma i chatten, och åtgärder som kostar pengar behöver ett lås mot dubbel körning.
• Servern behöver rootåtkomst, SSH-nycklar, fria utgående anslutningar och DDoS-skydd, men ingen GPU.
• KernelHost-servrar uppfyller alla krav från start, PrePaid utan avtalsbindning, och via KernelHost API kan agenten till och med beställa och styra servrar själv.