Propojení AI se serverem: jak AI agent nasazuje a spravuje váš server

Většina lidí zatím používá AI jako velmi sečtělého kolegu na druhém konci telefonu: člověk popíše problém se serverem, dostane návrh příkazu, zkopíruje ho do konzole, chybovou hlášku zkopíruje zpátky a celé kolečko opakuje, dokud to nezačne fungovat. Jakmile propojíte AI se svým serverem, tato oklika odpadá. AI agent jako Claude Code, OpenAI Codex CLI nebo Gemini CLI se k serveru sám přihlásí přes SSH, přečte logy, zkontroluje konfiguraci, nasadí změny, otestuje výsledek a zapíše, co udělal. Vy zadáte úkol a schválíte kroky, které nejde vzít zpět.

Tento článek je zprávou z praxe. U KernelHost s námi AI agent už několik měsíců denně pracuje na naší vlastní infrastruktuře: zákaznický portál, monitoring, platební kanály, dokumentace. Ukážeme, jak je spojení mezi agentem a serverem postavené, podle jakého postupu agent nasazuje na produkční systémy, jaká pravidla brání tomu, aby se přitom něco pokazilo nebo něco proniklo ven, a co musí server splňovat, aby to celé fungovalo. Základy o nástrojích a architekturách najdete v článku AI managed server: bezpečné propojení AI agentů, instalaci na server v návodu pro Claude Code a Codex CLI.

Propojení AI se serverem: co to znamená

Propojit AI se serverem znamená dát AI agentovi vlastní, kontrolovaný přístup k příkazové řádce serveru, většinou přes SSH klíč. Od té chvíle může agent příkazy nejen navrhovat, ale také sám spouštět, číst jejich výstup a odvozovat z něj další krok. Samotný jazykový model dál běží u poskytovatele (Anthropic, OpenAI nebo Google), na vašem počítači nebo serveru běží jen lehký nástroj příkazové řádky, který příkazy odesílá.

Rozhodující je slovo „kontrolovaný“. Agent s přístupem k serveru není autopilot, ale velmi rychlý spolupracovník, který se před každým zásahem zeptá. Kolik toho smí bez dotazu, určujete sami: od přístupu jen pro čtení až po samostatné nasazování aktualizací podle pevného postupu.

Chatbot, nebo agent: rozdíl v jedné tabulce

Z půlhodiny přeposílání sem a tam je tak často jen několik minut a zdroj chyb „špatně opsáno“ úplně mizí.

Co AI agent na serveru zvládne: příklady z našeho provozu

Následující příklady pocházejí z naší každodenní praxe. Jména, adresy a přístupové údaje vynecháváme, postupy jsou skutečné.

Nasazení se zálohou a cestou zpět

Když něco měníme na zákaznickém portálu nebo v serverovém skriptu, nasazení převezme agent. Nejdřív porovná soubor na serveru s posledním známým stavem, aby nepřepsal cizí změnu. Pak vytvoří zálohu s datem mimo webový adresář, napíše skript pro vrácení změn, zkontroluje syntaxi nového souboru, nasadí ho se stejnými vlastníky a právy jako předtím a potom otestuje dotčenou funkci. Teprve když je všechno zelené, ohlásí, že je hotovo. Přesný postup najdete níže v části o nasazování.

Hledání chyb: od příznaku k příčině během minut

„Z naší kanceláře není web dostupný, odjinud ano.“ Dřív by to znamenalo delší pátrání. Agent zkontroluje pravidla firewallu, vyhledá v záznamech ochranného softwaru adresu kanceláře, najde pravidlo, které zasáhlo, a vysvětlí, který požadavek ho spustil. Rozhodnutí, co dělat, zůstává na nás, detektivní práce už ne. U typických chyb webového serveru jako 502 Bad Gateway nebo plných disků postupuje stejně: čte logy přes journalctl a logy aplikací, vysloví hypotézu a doloží ji dřív, než cokoli změní.

Monitoring, který si agent postaví sám

Velká část našeho monitoringu vznikla ve spolupráci s agentem: malé kontrolní skripty, které každých pár minut přes cron úlohu otestují službu od začátku do konce a při chybě pošlou zprávu na mobil, například přes bota v Telegramu. Agent skript napíše, otestuje ho se záměrně vyvolanou chybou, nastaví cron úlohu a zdokumentuje, jak alarm ztlumit. Jak něco takového obecně postavit, popisuje článek Nastavení monitoringu serveru.

Přehledy a úklid

Které servery ještě běží, přestože byla příslušná smlouva vypovězena? Které doplňkové služby se platí, ale už se nepoužívají? Na takové otázky agent odpovídá tak, že se databází a rozhraní dotazuje jen pro čtení a výsledek připraví jako tabulku. Uklízet smí až po schválení a předtím ověří, zda je stroj opravdu nevyužívaný, například podle datového provozu za poslední dny.

Dokumentace, která roste sama

Každá změna končí záznamem v protokolu změn a v případě potřeby doplněním provozní příručky. Agenta to stojí sekundy a nám to později ušetří hodiny, protože otázka „Proč je to vlastně takhle?“ má písemnou odpověď.

Výhody, když AI pracuje přímo na serveru

• Rychlost: agent přečte za pár sekund to, na co člověk potřebuje minuty, a hypotézu hned vyzkouší, místo aby ji nejdřív popisoval.
• Důkladnost: čte celou konfiguraci včetně načítaných souborů a řádky logu kolem chyby, ne jen úryvek, který někdo považoval za podstatný.
• Stále stejný postup: záloha, kontrola syntaxe a ověření proběhnou pokaždé, i v pátek večer a i u dvacáté drobné změny.
• Dokumentace bez práce navíc: každá změna je popsaná včetně důvodu, místa uložení zálohy a cesty zpět.
• Automatizace bez studia skriptování: kontrolní skripty, cron úlohy a reporty vznikají z popisu v běžném jazyce a před ostrým použitím se otestují.
• Učení mimochodem: agent vysvětluje, co dělá a proč. Kdo jeho výstupy průběžně čte, rozumí po pár týdnech svému serveru výrazně lépe.

Tři architektury a kterou z nich používáme

Existují tři osvědčené způsoby, jak propojit agenta se serverem. Liší se tím, kde nástroj běží a kde jsou uložené přístupové údaje.

Naše volba: agent na pracovní stanici, servery přes SSH

Pracujeme s první variantou. Agent běží na pracovním počítači, každý server má záznam v konfiguraci SSH a agent se připojuje vlastním klíčem. Nejdůležitější důvod: spravujeme mnoho systémů a právě takto může jediný agent v jedné relaci sledovat příčinu napříč několika servery, například od webového serveru přes databázi až po firewall. Navíc jsou přihlášení u poskytovatele AI i klíče na místě, které tak jako tak chráníme. Kdo má jen jeden server a chce v noci automatické reporty, tomu dobře poslouží druhá varianta. Více o výhodách a nevýhodách najdete v článku o AI managed serveru.

Návod: jak propojit AI agenta se serverem přes SSH

Následujících sedm kroků funguje stejně s Claude Code, Codex CLI i Gemini CLI. Příklady používají dokumentační adresu 203.0.113.10 a uživatelské jméno deploy, obojí nahraďte svými hodnotami. Předpokladem je server s přihlášením SSH klíčem, jak ho popisuje článek Zabezpečení SSH a nastavení přihlášení klíčem.

Krok 1: vytvořit vlastní SSH klíč jen pro agenta

Agent nikdy nedostane váš osobní klíč, ale vlastní. Přístup mu tak můžete kdykoli odebrat, aniž byste přišli o svůj, a z logů je poznat, které přihlášení pocházelo od agenta.

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

Klíč Ed25519 je krátký, rychlý a považuje se za bezpečný. Komentář ki-agent se později objeví v authorized_keys na serveru a klíč podle něj poznáte na první pohled.

Krok 2: uložit veřejný klíč na server

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

Kdo chce přístup dál omezit, uvede v souboru ~/.ssh/authorized_keys na serveru volby před samotným klíčem. from= povolí přihlášení jen z určité adresy, no-agent-forwarding a no-port-forwarding brání tomu, aby spojení sloužilo jako odrazový můstek:

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

Pokud server potom hlásí Permission denied (publickey), pomůže článek Řešení chyby SSH Permission denied (publickey).

Krok 3: vytvořit alias hostitele v konfiguraci SSH

Díky aliasu stačí, aby agent znal jen krátký název, a vždy použije správný klíč:

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

Pak stačí ssh web-prod "systemctl status nginx". IdentitiesOnly yes zabrání tomu, aby SSH zkoušelo jiné klíče z vaší klíčenky. Pro každý další server vytvořte vlastní blok, pro testovací a produkční systémy nejlépe s odlišnými názvy jako web-test a web-prod, aby záměna byla patrná už z názvu.

Krok 4: nainstalovat agenta a přihlásit ho

Claude Code, Codex CLI a Gemini CLI běží na Linuxu, macOS a Windows a přihlašují se účtem u poskytovatele nebo API klíčem. Instalaci a přihlášení bez prohlížeče popisuje návod krok za krokem. Pro variantu s pracovní stanicí nainstalujte nástroj na svůj počítač, ne na server.

Krok 5: stanovit pravidla, kterými se agent řídí

Všechny tři nástroje při spuštění čtou soubor s pravidly v pracovním adresáři: Claude Code soubor CLAUDE.md, Codex CLI AGENTS.md, Gemini CLI GEMINI.md. Je v něm popsáno, jak se na vašich serverech pracuje. Osvědčený začátek:

# Pravidla pro práci na serverech

- Před každou změnou vytvořit zálohu s datem, mimo webový adresář.
- Před nasazením zkontrolovat syntaxi (nginx -t, php -l, apachectl configtest).
- Po nasazení zkontrolovat službu, log a funkci a ohlásit výsledek.
- Hesla, API klíče a tokeny nikdy nevypisovat, nikdy je nekopírovat do souborů.
- Mazání, změny v databázích a vše nevratné jen po výslovném schválení.
- Soubory, které spravuje ovládací panel, neměnit přímo.
- Testovací soubory po testu zase odstranit.

Pravidla průběžně přibývají. Pokaždé, když agent udělá něco jinak, než chcete, patří oprava jako pravidlo do tohoto souboru. Po několika týdnech pracuje tak, jak byste pracovali vy sami.

Krok 6: nastavit schvalování a allowlist

Ve výchozím nastavení se nástroje ptají před každým příkazem, který něco mění. Na začátku je to správně. Příkazy pro čtení, které neustále potvrzujete, můžete povolit. V Claude Code se to dělá v souboru .claude/settings.json:

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

Vše, co na tomto seznamu není, nadále vyžaduje váš souhlas. Přepínače, které vypínají veškeré dotazy, patří nanejvýš na jednorázový testovací stroj.

Krok 7: první úkol: jen číst

Začněte úkoly, které nemohou nic změnit, a sledujte, jak agent postupuje:

Zkontroluj na web-prod chyby nginx za posledních 24 hodin a uveď tři nejčastější
příčiny, u každé s jedním dokladem z logu. Nic neměň.

Teprve když analýzy sedí, přicházejí na řadu malé změny, například nová rotace logů nebo služba systemd, a teprve potom nasazení na produkční systém.

Jak agent nasazuje: náš postup pro každou změnu na produkčním systému

AI agent smí na produkční systém nasazovat jen podle pevného postupu, který zahrnuje zálohu, připravenou cestu zpět a kontrolu před nasazením i po něm. U nás tento postup vypadá takto:

1. Ověřit aktuální stav. Soubor na serveru se porovná s posledním známým stavem. Pokud ho mezitím změnil někdo jiný, agent práci přeruší a zeptá se, místo aby cizí změnu přepsal.
2. Vytvořit zálohu. Dotčené soubory skončí s datem ve složce pro zálohy mimo webový adresář. Záloha ve webovém adresáři by za určitých okolností mohla být veřejně dostupná.
3. Připravit cestu zpět. Malý skript, který jediným příkazem vrátí starý stav, vzniká před změnou, ne až v nouzi.
4. Zkontrolovat syntaxi. Nový soubor se před nasazením zkontroluje, u PHP pomocí php -l, u nginx pomocí nginx -t. Syntaktická chyba se tak na produkční systém vůbec nedostane.
5. Nasadit se správnými právy. Vlastník, skupina a práva souboru se převezmou ze starého stavu. Špatná práva jsou po syntaktických chybách nejčastější příčinou výpadků po aktualizaci.
6. Testovat bez vedlejších účinků. Testuje se jen čtením, s vymyšlenými testovacími daty nebo v izolovaném prostředí, nikdy se skutečnými objednávkami nebo skutečnými daty zákazníků.
7. Ověřit naživo. Po nasazení se zkontroluje stavový kód HTTP, chybový log a změněná funkce.
8. Zdokumentovat. Doplní se protokol změn a provozní příručka, včetně místa uložení zálohy a příkazu pro cestu zpět.

Jako posloupnost příkazů, se zástupnými hodnotami místo skutečných cest, to vypadá zhruba takto:

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/

Proč cesta zpět vzniká před změnou

Když se něco pokazí, nikdo není v nejlepší kondici promýšlet čistou cestu zpět. Pokud je skript už připravený, je vrácení změny otázkou sekund a agent může změnu vrátit i sám, když kontrola po nasazení selže. To je největší rozdíl mezi agentem, který „jen tak rychle“ něco změní, a agentem, kterému lze svěřit produkční systém.

Testy, které nemohou nic rozbít

Mnoho funkcí nejde otestovat, aniž by se něco stalo: objednávka, platba, e-mail. Tady pomáhají tři techniky. Zaprvé běhy nanečisto, které nabízí samotný nástroj. Zadruhé vymyšlené identifikátory, které zaručeně nikde neexistují. Zatřetí izolované prostředí: proces, který běží ve vlastním síťovém jmenném prostoru bez sítě (unshare -n), nedosáhne na žádné externí rozhraní ani omylem nic nekoupí, lokální databázi ale přes unixový socket dál vidí. Po testu se všechny testovací soubory zase odstraní.

Akce, které stojí peníze, potřebují zámek

Když nějaká úloha něco objednává, účtuje nebo maže, nesmí běžet dvakrát současně, a to ani tehdy, když někdo klikne dvakrát nebo agent příkaz zopakuje. Nejjednodušší řešení na Linuxu je flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "už běží"

U databázových aplikací plní stejný účel pojmenovaný zámek (GET_LOCK v MySQL a MariaDB), u rozhraní Idempotency-Key, více o tom níže v části o KernelHost API.

Bezpečnost: přístup pro agenta, aniž by cokoli uniklo

Obava, kterou slyšíme nejčastěji, zní: „A co moje data?“ Upřímná odpověď: vše, co agent čte, posílá ke zpracování jazykovému modelu poskytovatele. Proto pomocí následujících pravidel rozhodujete, co vůbec uvidí.

Tajemství do chatu nepatří

Hesla, API klíče a tokeny se nikdy nepíší do úkolu a agent je nikdy nevypisuje. Skripty je čtou ze souborů s právy 600, které agent nemusí zobrazovat, aby mohl skript použít. Pokud se klíč přesto někdy ocitne v chatu, okamžitě se u poskytovatele zablokuje a vygeneruje se nový. Do chatu nepatří ani útržky: první znaky klíče nikomu nepomohou při hledání chyby, útočníkovi ale zkrátí práci.

Vlastní klíče, vlastní práva, kdykoli odvolatelné

Každý agent dostane vlastní SSH klíč a každý klíč je v authorized_keys poznat podle svého komentáře. Kdo chce přístup odebrat, smaže ten jeden řádek. Kde to stačí, pracuje agent s vlastním uživatelem a pravidlem sudo, které povoluje jen nezbytné příkazy. Pro programová rozhraní se používají vlastní klíče s co nejmenšími právy, pro pouhé vyhodnocování jen pro čtení.

Schvalování: co se nikdy nestane bez člověka

Bez výslovného souhlasu u nás agent nesmí mazat, zapisovat do databází, uvolňovat pravidla firewallu ani jiná ochranná pravidla, zastavovat stroje ani nic objednávat. Nástroje to podporují: Claude Code akce zasahující do systému pozastaví a dá se navíc nastavit tak, aby bezpečnostní filtr rozpoznal riskantní příkazy a až do schválení je blokoval. Z naší praxe: tento filtr víc než jednou zastavil akci, která byla věcně správná, ale prostě nevratná. Proběhla až poté, co ji člověk výslovně schválil. Přesně tak to má být.

Dohledatelnost: protokol, seznam změn, zálohy

Každá relace zanechává stopy, které si člověk může přečíst: zálohy s datem, skript pro vrácení změn, záznam v protokolu změn a přihlášení v systémovém logu. Kdo navíc spravuje /etc pomocí etckeeper v Gitu, vidí každou změnu konfigurace jako diff. Co není dohledatelné, nejde ani vrátit zpět. Základem zůstává funkční zálohovací strategie, protože agent zálohu nenahradí.

Jaký server se hodí pro AI agenta?

Server pro správu s pomocí AI potřebuje plný root přístup, přihlášení SSH klíčem, neomezená odchozí spojení, trvalou ochranu proti DDoS a ideálně programové rozhraní, přes které lze servery automatizovaně objednávat a řídit. GPU nepotřebuje, protože jazykový model běží u poskytovatele.

Proč KernelHost pro servery spravované AI

AI agent může v zásadě pracovat s jakýmkoli serverem, na kterém dostane shell. V praxi však o tom, kolik práce mu opravdu můžete předat, rozhoduje prostředí. Na KVM root serveru nebo dedikovaném serveru od KernelHost nejsou žádné omezené účty, žádné překážky pro spojení přes HTTPS k poskytovatelům AI a žádný smluvní závazek, který by zkoušení prodražil. Trvalá ochrana proti DDoS je u každého serveru aktivní bez příplatku a pro výpočetně náročné úlohy jsou tu profesionální root servery s dedikovanými jádry. Účtuje se v režimu PrePaid: žádná smlouva, žádná minimální doba trvání, žádný poplatek za zřízení. Kdo si to chce nejdřív vyzkoušet, začne s bezplatným testovacím serverem.

KernelHost API: váš agent sám objednává a řídí servery

Největší páka leží o úroveň výš než jednotlivý server. Přes KernelHost API může agent načítat produkty a ceny, objednávat servery, číst stav svých služeb, servery spouštět, zastavovat a restartovat a také zadávat zrušení a zase je odvolávat. Z „Nastav mi testovací server“ se tak stane jediný úkol: agent objedná stroj, počká na zprovoznění, připojí se přes SSH, nainstaluje aplikaci a nahlásí zpět adresu.

Pro práci s agenty je rozhraní záměrně navržené opatrně. API klíče dostávají jen ta práva, která potřebují, a klíč pro vyhodnocování nemůže objednat vůbec nic. Idempotency-Key zajistí, že objednávka, kterou agent zopakuje po chybě kvůli vypršení časového limitu, se neprovede dvakrát. Počet požadavků je omezený pro každý klíč, každý účet i každou adresu, takže ani agent v nekonečné smyčce nespustí lavinu. A každé načtení přístupových údajů vyvolá upozornění e-mailem, abyste viděli, kdy agent přístupové údaje četl.

Kolik stojí server spravovaný AI?

Vznikají dvě položky. Zaprvé samotný server: pro agenta, který pracuje přes SSH, nepotřebuje žádnou zvláštní výbavu, stačí jakýkoli root server, na kterém vaše aplikace stejně běží. Pokud agent běží přímo na serveru, potřebuje samotný nástroj jen několik stovek megabajtů operační paměti, stačí root server se 2 vCPU a 4 GB RAM, když na něm jinak mnoho neběží. Zadruhé jazykový model: buď předplatné poskytovatele, které zahrnuje používání nástroje příkazové řádky, nebo API klíč s účtováním podle spotřeby. Při každodenním intenzivním používání je předplatné většinou levnější, pro automatizované úkoly bez člověka u klávesnice je API klíč čistá cesta, protože ho lze omezit měsíčním rozpočtem. Aktuální ceny serverů najdete na stránce Pronájem root serveru.

Časté chyby a jak se jim vyhnout

• Agent pracuje s osobním klíčem administrátora. Pak mu nejde přístup odebrat samostatně a v logu ho nelze rozlišit. Řešení: vlastní klíč s vlastním komentářem.
• Všechny dotazy jsou vypnuté. První den to ušetří kliknutí a jednou to bude stát server. Řešení: allowlist pro příkazy pro čtení, schvalování pro vše, co zasahuje do systému.
• Žádná záloha před změnou. Řešení: záloha a skript pro vrácení změn jako pevné pravidlo v CLAUDE.md nebo AGENTS.md.
• Zálohy ve webovém adresáři. Soubor jako config.php.bak v kořenovém adresáři webu může být veřejně dostupný, včetně hesla k databázi. Řešení: složka pro zálohy mimo webový adresář s právy 700.
• Tajemství v promptu. Řešení: přístupové údaje jen v souborech s právy 600, které čtou skripty, a při nechtěném úniku je okamžitě vygenerovat znovu.
• Dvojí provedení. Dvojí kliknutí nebo opakovaný požadavek objedná dvakrát. Řešení: zámek pomocí flock nebo Idempotency-Key.
• Přímo změněné soubory, které spravuje ovládací panel. Panel je při příští aktualizaci přepíše, nebo na nich selže. Řešení: takové soubory v pravidlech vyloučit a změny dělat přes panel nebo jeho rozhraní.
• Výstupy převzaté bez kontroly. Agent, který výstupu nerozumí, hádá. Řešení: vyžadovat doklady („ukaž mi ten řádek logu“) a nechat výsledky ověřit naživo.

Stručné shrnutí

• Propojit AI se serverem znamená dát agentovi, jako je Claude Code, Codex CLI nebo Gemini CLI, vlastní SSH klíč a jasná pravidla.
• Agent čte logy, nasazuje změny, kontroluje výsledek a dokumentuje ho, kroky zasahující do systému probíhají jen se schválením.
• Každé nasazení se řídí pevným postupem: ověřit aktuální stav, zazálohovat, připravit cestu zpět, zkontrolovat syntaxi, nasadit, otestovat, ověřit naživo, zdokumentovat.
• Tajemství nikdy nepatří do chatu a akce, které stojí peníze, potřebují zámek proti dvojímu provedení.
• Server potřebuje root přístup, SSH klíče, volná odchozí spojení a ochranu proti DDoS, ale žádnou GPU.
• Servery KernelHost splňují všechny požadavky od začátku, PrePaid bez smluvního závazku, a přes KernelHost API může agent servery dokonce sám objednávat a řídit.