Hibaelhárítás

Azoknak az üzeneteknek a katalógusa, amiket ez a termék ténylegesen kiír: mit jelent mindegyik, és mi a teendő. Minden alább idézett blokk az a szöveg, ahogy az átjáró kibocsátja, …-tal jelölve a futásidőben kitöltött részeket — tehát a képernyődön álló üzenet visszakereshető ezen az oldalon.

Az üzenetek négy csoportba esnek aszerint, hogy mikor látod őket: a daemon nem hajlandó elindulni, egy munkamenet elutasításra kerül, egy isg system check sora, vagy egy üzemeltetési tünet saját üzenet nélkül. Ez a lap a platform és az SSH; az oldalak, amiket a böngésző a Web Access-től kap, a Web Access hibaelhárítása lapon állnak.

Az átjáró nem indul el

Az isg serve inkább elutasít, mint hogy olyan állapotban induljon el, ami helyesnek látszik, de nem az. Minden alábbi elutasítás megnevezi, mi a baj; egyiknek sincs felülbíráló kapcsolója, mert az a kontroll, amit csendben ki lehet kapcsolni, nem kontroll.

Fel nem ismert kulcs egy konfigurációs fájlban

unknown configuration key(s) — refusing to start:
  …
remove or correct the key(s) above; `isg system check` reports them too

Ok. Elgépelés, vagy egy másik fájlból való kulcs. Az ellenőrzés minden regisztrált konfigurációs fájlon végigmegy, még minden más megnyitása előtt.

Javítás. Javítsd vagy töröld a megnevezett kulcsot. Az isg system check ugyanezt a leletet jelenti a daemon indítása nélkül, tehát az a gyorsabb kör. A konfigurációs referencia a mérvadó lista arról, hogy melyik fájl mit fogad el.

Nem-loopback bind hitelesítés nélkül

non-loopback bind (0.0.0.0:8765) requires LDAP authentication — ldap.yaml must be configured; refusing to serve without auth

Ok. A --bind a loopbacktől eltérő címet nevez meg, és nincs ldap.yaml, tehát az admin felület a hálózatról bejelentkezés nélkül lenne elérhető.

Javítás. Konfiguráld az ldap.yaml-t, vagy köss loopbackre, amíg meg nem tetted. A legtöbb telepítés ebbe fut bele az első systemctl start-nál, mert a csomagolt unit a 0.0.0.0-ra köt — a címtárat a unit engedélyezése előtt konfiguráld.

Titkosítatlan kapcsolat a címtárhoz

load identity resolver for web auth: configure LDAP resolver from /var/lib/isg/ldap.yaml: ldap: refusing to use the unencrypted url "ldap://dir.example.com:389": with scheme ldap:// and no start_tls, every operator's bind password and the service account's own password cross the network in the clear. Fix it with ONE of: url: "ldaps://dir.example.com:636"; or keep this url and add start_tls: true (same port, TLS before the first bind); or, if you accept plaintext passwords on this network, say so explicitly with allow_plaintext: true

Ok. Az ldap.yaml egy ldap:// url-t nevez meg, és sem a start_tls: true, sem az allow_plaintext: true nincs beállítva. Az admin felület úgy ellenőrzi az operátor jelszavát, hogy az adott operátorként bindol, tehát ez a kapcsolat a szolgáltatásfiók jelszaván túl operátor-jelszavakat is hordoz — és az elutasítás szándékos: amíg ez az ellenőrzés nem létezett, egy ilyen telepítés úgy futott, hogy mindezek a jelszavak olvashatók voltak a hálózaton, az isg system check pedig végig zöld volt.

Javítás. A három közül az egyik, amit az üzenet megnevez. Az ldaps:// (alapból a 636-os port) és a start_tls: true (ugyanaz a 389-es port, az első bind előtt felminősítve) az igazi két válasz; az allow_plaintext: true a leírt döntés arról, hogy ezen a hálózaton elfogadjuk a titkosítatlan jelszót, és ameddig áll, az ldap.yaml sorát sárgán tartja.

Ellentmondó TLS-beállítás a címtárhoz

ldap: url "ldaps://dir.example.com:636" is already TLS, but start_tls: true is also set — these are two different ways to encrypt the same connection and cannot be combined …

Ok. Az ldap.yaml két kulcsa két különböző szándékot állít. Ugyanez az elutasítás fedi az allow_plaintext: true-t az ldaps:// vagy a start_tls mellett, és a tls_ca_file-t egy olyan kapcsolaton, ami nem hordoz TLS-t.

Javítás. Töröld azt a kulcsot, ami nem a szándék. Itt szándékosan nem oldódik fel semmi csendben: bármelyik kulcs veszítene, pont az lenne az, amit senki nem vesz észre.

A címtár tanúsítványa nem megbízható, vagy nem illeszkedik

[FAIL] LDAP bind    failed to connect (dir.example.com:636): ldap dial ldaps://dir.example.com:636: LDAP Result Code 200 "Network Error": tls: failed to verify certificate: x509: certificate signed by unknown authority

Ok. A kézfogás a hálózaton lezajlott, és az ellenőrzésen bukott el. Három szokásos alakja van, és a Go üzenete szavakkal megkülönbözteti őket: ismeretlen kiadó írta alá (a kiadó CA sem a tls_ca_file-ban, sem a gép trust-storéjában nincs benn), lejárt vagy még nem érvényes (dátumos — az isg system check LDAP bind sora kiírja a lejáratot, és 30 napon belül figyelmeztet), vagy más névre érvényes (figyelj rá, hogy egy IP-címet hordozó url-hez IP-SAN kell; egy csak DNS-neves tanúsítvány itt bukik).

Javítás. Állítsd a tls_ca_file-t arra a PEM-re, amelyik a címtár tanúsítványát kiadta, újítsd meg a tanúsítványt, vagy adasd ki újra arra a névre, amit a url tényleg használ. Egy elbukott ellenőrzés kapcsolódási hiba, sosem rossz jelszó: az mfa.yaml kizárási számlálóihoz nem ér hozzá, és egyetlen kísérlet sem esik vissza titkosítatlan kapcsolatra.

Nem-loopback bind TLS nélkül

non-loopback bind (0.0.0.0:8765) requires TLS — run `isg ca init` first; refusing to serve plain HTTP on the network

Ok. A webUI kiszolgáló-tanúsítványa az X.509 CA-ból származik, a CA pedig nincs inicializálva. Egy hálózati bindhoz a hitelesítés és a TLS is kell; bármelyik hiánya elutasítás.

Javítás. isg ca init --permitted-dns <name> --permitted-ip <CIDR>. Idempotens, és az SSH- meg az X.509-fele független egymástól. A két kapcsoló egy ÚJ X.509 CA-hoz kötelező, és a nameConstraints-e lesz: azok a nevek, amikre ez a CA aláírhat. Egyik nélkül sem a parancs semmit nem hoz létre, és megnevezi mindkét kapcsolót, plusz a tudatos kibúvót, a --no-name-constraints-ot.

Egy másik daemon birtokolja az állapotgyökeret

refusing to take the state root lease /var/lib/isg/serve.lease: …

holder: host …, broker id …, pid …, isg …; acquired …, heartbeat …

two brokers writing one file-based state root silently lose each other's writes …

Ok. Egy állapotgyökeret pontosan egy isg serve birtokolhat. Kettő nem rontaná el egymás rekordjait — a második csendben eldobná az első munkameneteit.

Javítás. Olvasd el a birtokos-blokkot. Ha a birtokos ezen a gépen fut, állítsd le azt a folyamatot; az üzenet ezt kimondottan meg is mondja, és az isg system lease release ugyanezért fog elutasítani. Ha a birtokos egy másik gépen vagy egy korábbi indulásban volt, és megbizonyosodtál róla, hogy elment, takarítsd el az isg system lease release-zel — ne rm-mel, ami nem kielégíti, hanem kijátssza az őrt, és nem ír auditbejegyzést. Az isg system lease status mutatja a birtokost anélkül, hogy bármit megváltoztatna.

Olyan rekord-tár, ami nem vette fel a migrációt

…/storage.yaml: records.backend is "postgres", but the aggregate document … is still here — that state root has never taken the per-record migration, and doing both in one start would mean guessing twice; run once with records.backend: "dir" first, or move it aside

Ok. Két migráció egy induláson — a régi aggregátumból rekordonkénti fájlokba, majd a rekordonkénti fájlokból PostgreSQL-be — kétszeri találgatást jelentene arról, hogy mi az aktuális.

Javítás. Egyesével csináld: indulj egyszer records.backend: dir-rel, hagyd lefutni azt a migrációt, aztán válts postgres-re. Vagy tedd félre az aggregátum-dokumentumot, ha tudod róla, hogy elavult.

Két rekord-tár, és mindkettő tart rekordokat

both the aggregate … and the per-record directory … exist; refusing to guess which is current — move one aside

Ok. Mindkét elrendezés jelen van és nem üres. Az egyik választása csendben eldobná a másikat.

Javítás. Döntsd el, melyik az aktuális, és tedd félre a másikat. Az átjáró semmit nem töröl.

A tulajdonosán kívül más által is olvasható hitelesítőadat-fájl

…: records.postgres.dsn_file … is mode 0644 — it holds a database password that can read and rewrite every session record, so it must not be readable by group or other (chmod 0600)
…: recordings.s3.credentials_file … is mode 0644 — it holds an access key pair that can read every archived session recording, so it must not be readable by group or other (chmod 0600)
vault token_file … has mode 0644 — must not be group- or world-readable (chmod 0600)

Ok. Ez a három titok a saját fájljában él, elkülönítve attól a konfigurációtól, ami megnevezi őket, pontosan azért, hogy szigorúbb módot hordozhassanak. A módot ellenőrizzük, nem feltételezzük, és a laza mód elutasítja az indulást ahelyett, hogy figyelmeztetne: egy csoport által olvasható hitelesítő adatról szóló figyelmeztetés olyan sor, ami fölött egy futó átjáró elgörget.

Javítás. chmod 0600 a megnevezett fájlra, és ha már ott vagy, nézd meg a tulajdonosát is.

Egy konfigurált háttértár, ami nem válaszol

…: the record store postgres:… did not answer within …: …
…: the stream store's bucket "…" at … did not answer, so `isg serve` will not start with a stream store it cannot reach: …

Ok. Rossz hoszt, rossz hitelesítő adatok, nem figyelő adatbázis, tűzfal. Mindkét háttértár szándékosan induláskor bizonyíttatik — az alternatíva az, hogy órákkal később, az első isg connect-nél derül ki, amikor a tünet egy el nem induló munkamenet, és már senki nem köti össze egy konfigurációs változtatással.

Javítás. A becsomagolt hiba a meghajtó sajátja. Vedd észre, hogy a rekord-tárból érkező hiba sosem hordozza a jelszót: az üzenet felépítése előtt kitakarásra kerül, tehát egy DSN-probléma kapcsolódási hibaként jelenik meg, nem hitelesítőadat-kiöntésként.

A legális halmazán kívüli konfigurációs érték

unknown mfa_mode "…" in …: want one of "email", "totp", "totp-with-email-fallback"
parse connect config …: unknown host_key_check "…" (must be "strict" or "insecure")
parse connect config …: human_auth: local_keys is no longer supported — the client-side connect path was removed; set human_auth: cert
parse connect config …: allow_password_auth: true is no longer supported — the client-side connect path that implemented the password fallback was removed (ADR 653328395, S3); remove the key or set it to false

Ok. Nincs biztonságos mód arra, hogy egy ismeretlen értéket ismertté kényszerítsünk, és nincs megengedő alapértelmezés, amire vissza lehetne esni. Az utolsó kettő olyan mechanizmust nevez meg, amit eltávolítottunk, ahelyett hogy csendben újraértelmeznénk a fájlt — egy olyan telepítésnek, ami még hordozza ezeket a sorokat, észre kell vennie.

Javítás. Használd az üzenetben felsorolt értékek egyikét. A human_auth-nak a cert az egyetlen legális értéke.

Megnevezett, de nem létező CMDB mock-fájl

B398: cmdb.yaml names mock_file …, but that file does not exist — refusing to start. A static resolver with no mock file resolves EVERY host to an empty label set, so none of the … label_rules can ever match and every unpinned host falls back to default_level …, while the CLI still reports "CMDB: active" and "source: cmdb". …

Ok. A cmdb.yaml resolver: static-ot mond és megnevez egy mock_file-t, a fájl pedig nincs azon az útvonalon. Amíg ez az elutasítás nem létezett, az átjáró ettől is elindult, egy olyan resolverrel, ami minden hosztra egyáltalán semmilyen címkét nem adott — tehát egyetlen label_rules bejegyzés sem illeszkedhetett, minden pin nélküli hoszt csendben a default_level-t vette fel, az isg servers show pedig továbbra is CMDB: active-ot írt. Azok a lockdown-szintek, amiket a telepítés kikényszerítendőnek állított be, egyszerűen nem voltak hatályban, és ezt semmi nem mondta ki. Egy élő brókeren mérve, 2026-10-07-én, ahol egy teljes környezet-felépítést túlélt.

Javítás. Három közül az egyik, és hogy melyik, azon múlik, mit szándékoztál. Tedd oda a fájlt, ahová a mock_file mutat — figyelj rá, hogy a mock JSON, tehát egy *.yaml konfigurációs fájlokat szállító telepítési folyamat nem viszi magával, csak ha külön fel van sorolva. Vagy irányítsd a mock_file-t arra a fájlra, ami már ott van. Vagy vedd ki a mock_file kulcsot: az a kimondott módja annak, hogy üres statikus CMDB-t kérj, és támogatott is — a cmdb.yaml ellenőrző sora ilyenkor sárgán megnevezi a következményt, az indulást nem tagadja meg.

A relatív mock_file a cmdb.yaml saját könyvtárához képest oldódik fel, nem a daemon munkakönyvtárához, tehát a mock_file: cmdb_mock.json az állapot-gyökérben a cmdb.yaml melletti fájlt jelenti. Egy ~-vel kezdődő értéket viszont azonnal elutasít: a daemonban semmi nem bontja ki a ~-t — rendszer-fiókként fut a systemd alatt, soha nem shellen át —, tehát egy ilyen útvonal szó szerint nyílna meg.

Önmagának ellentmondó hozzáférési policy

human_access.requested_by_enforce is true but human_access.enforce is false — enable human_access.enforce first; otherwise a request no allow rule covers falls through to a no_matching_rule denial enforced by requested_by_enforce alone, silently reintroducing the access gate's own enforcement

Ok. A szűkebb kapcsoló bekapcsolása a tágabb nélkül egy hátsó ajtón át kényszerítené ki a hozzáférési kaput, amit az operátor kifejezetten nyitva hagyott.

Javítás. Előbb tedd be a human_access.enforce: true-t, vagy kapcsold vissza a requested_by_enforce-t.

A megőrzési söprés időköze a padló alatt

…: sweep.interval "…" (…) is below the … floor — one pass walks the state root and stats every closed session's artifacts, so its cost grows with the gateway's HISTORY rather than with how much there is to delete …

Ok. Egy söprési kör költsége azzal arányos, hogy mennyi az átjáró előtörténete, nem azzal, hogy mennyit kell törölni. Ez sweep.enabled: false mellett is elutasításra kerül, tehát olyan érték, ami elrontaná az átjárót, nem ülhet a lemezen arra várva, hogy valaki bekapcsolja.

Javítás. Emeld meg az időközt. Az alapértelmezéshez hagyd el a kulcsot teljesen.

Az auditnapló nem nyitható meg

open audit log …: …

Ok. Jogosultsági probléma, hiányzó szülőkönyvtár, vagy tele lemez. Az auditnapló a történtek rekordja, tehát az az átjáró, ami nem tudja írni, nem fut.

Javítás. A becsomagolt hiba megnevezi az okot. Vesd össze az állapotgyökér tulajdonosát azzal a fiókkal, ami alatt a unit fut.

Egy munkamenet vagy egy parancs elutasításra kerül

Egy parancs illeszkedett egy policy-szabályra

DENIED by policy: block_interactive_root_shell (interactive root shell is not allowed)

Ok. A legszigorúbb illeszkedő szabály döntött. A szabály neve és az indoka is benne van az üzenetben, és a COMMAND_DENIED auditbejegyzésben is.

Javítás. Ha a szabály a beépített tiltások egyike, a parancsnak kell változnia — semmilyen policy.yaml nem gyengítheti őket. Ha a sajátod, az isg policy show kiírja a teljes effektív szabályhalmazt, minden szabályt eredet szerint címkézve.

Egy szabály a sor egy részére illeszkedett, nem az egészére

DENIED by policy: block_passwd_changes (password changes must go through the IdP) — part 2 of 2: "passwd -S peter"

Ok. Egy sor egynél több parancsot is futtathat, és mindegyik kiértékelődik. A part 2 of 2 farok megnevezi, melyik illeszkedett — itt a sor második parancsa, nem az id, ami megelőzte. Ha a farokban az is ott áll, hogy (behind wrappers), a szabály azután illeszkedett, hogy egy sudo-előtagot vagy egy parancs-előtagot (például env vagy timeout) átléptünk.

Javítás. Változtasd meg azt a részt, vagy tedd külön sorokba a parancsokat, hogy mindegyik a saját döntését kapja. Az auditbejegyzés továbbra is a teljes sort rögzíti, úgy, ahogy begépelték.

A sor olyat használ, amit a policy nem tud kiértékelni

DENIED by policy: block_dynamic_shell_construct (command substitution ($(...)) cannot be evaluated by the policy before it runs — split it into separate lines)

Ok. A sorban olyan szerkezet van, aminek a hatása csak futás közben dől el: parancs-behelyettesítés, folyamat-behelyettesítés, here-document, függvénydefiníció, eval, source, exec, alias, egy interpreter, aminek a programját sztringként adták át (bash -c), vagy egy parancsnév, ami csak behelyettesítés után áll elő. Az alapértelmezés az, hogy ezeket elutasítjuk, ahelyett hogy találgatnánk róluk.

Javítás. Bontsd külön sorokra a sort, mindegyikben megnevezve a futtatott programot. Ahol ez tényleg nem megy, a policy.yaml dynamic_construct_action kulcsa állítható require_approval-ra, hogy egy második személy döntsön helyette; az allow kiértékelés nélkül futtatja az ilyen sorokat, és laborbeállítás, nem éles beállítás. A szomszédos eset a block_unparseable_line — amikor a sor nem is shell-sor —, és az nem állítható.

Az exit elutasításra került egy sor közepén

DENIED by policy: block_exit_in_compound_line (exit/quit/logout ends the session only as a line of its own — run it on its own line) — part 2 of 2: "exit"

Ok. Az exit, a quit és a logout csak akkor zárja a munkamenetet, ha az egész sor. Az id; exit sorban a szó a célgépnek küldött parancs, és a munkamenettel nem csinálna semmit — ezért a sort elutasítjuk, ahelyett hogy csendben a másikat csinálnánk.

Javítás. Futtasd le a többi parancsot, aztán az exit jöjjön saját sorban.

Kideríteni, mit csinál egy sor, mielőtt lefuttatnád

isg policy check -- 'id; passwd -S peter'

Kiírja, hogyan bomlik fel a sor, minden jelölt-szöveget, amire a motor a szabályokat illeszti, és a döntő szabályt. Semmit nem futtat, démonhoz nem nyúl, és nem ír sehova. A kilépési kód maga a válasz: 0 engedélyezve, 1 tiltva, 2 jóváhagyás szükséges. A --file a gateway sajátjától eltérő policy-fájlra értékel ki, a --level és a --role pedig másik hoszt-szintként vagy felhasználói szerepkörként.

Egy jóváhagyási kérésből kifutott az idő

approval request APPR-2026-000042 expired without a decision

Ok. Egyetlen jóváhagyó sem döntött a szabály timeout_seconds-én belül (alapból 300).

Javítás. Add ki újra a parancsot. Ellenőrizd, hogy a jóváhagyókat tényleg eléri-e valami — a notify.yaml konfigurálja a kiküldést, és az az átjáró, amelyiknek se webhookja, se kimenő sora nincs, senkit nem értesít.

Egy munkamenet audit-naplója a webUI-n: a jóváhagyási kérés és az értesítése, majd ugyanabban a pillanatban a COMMAND_APPROVAL_EXPIRED és a COMMAND_DENIED, (timeout) okkal

Képernyőkép: referencia-környezet (env1), 2026-10-17.

Egy jóváhagyó nemet mondott

DENIED by …

Ok. Egy második személy elutasította a kérést. Ez döntés, nem hiba.

Senki nem tudta jóváhagyni

self-approval is not allowed: … requested this command and cannot decide it

Ok. A négy szem elve. Feltétel nélkül áll: a kérelmező sosem jogosult döntéshozó, szerepkörtől és csoporttól függetlenül.

Javítás. Valaki más dönt az approver_group-ból. Ha rajta kívül senki nincs benne, az maga a lelet.

A hozzáférési kapu elutasította a kapcsolatot

access denied: you are not authorized to open a session on <host> as <user> (no_matching_rule) — if you should have this access, contact your ISG administrator

A zárójelben álló ok zárt halmazból való, és mindegyik mást jelent:

Ok Jelentés
not_configured A ca.yaml-ban egyáltalán nincs human_access szekció
no_matching_rule Egyetlen engedélyszabály sem fedi ezt a principalt ezen a hoszton
group_unverifiable Egy szabály csoportot követel, de a csoportok a users.json-ból jöttek, nem címtárból — tehát a követelmény nem ellenőrizhető
labels_stale Egy host_labels szabály illeszkedhetett volna, de a CMDB-címkék elavult gyorsítótárból valók
labels_unavailable Ugyanaz, egyáltalán használható címkék nélkül

Javítás. A no_matching_rule-hoz vedd fel a hosztot egy szabály hosts: listájába, vagy adj neki olyan címkét, amit egy meglévő szabály kiválaszt — hoszt-helyettesítő karakter nincs. A group_unverifiable-höz konfiguráld az ldap.yaml-t: a tartalék fájl nem tud egy csoport-állítást ellenőrizhetővé tenni.

A kérelmező nem volt jogosult azzal a principallal eljárni

access denied: you are not authorized to open a session on <host> as <user> (requester_mismatch) — if you should have this access, contact your ISG administrator

Ok. A requester_mismatch azt jelenti, hogy az illeszkedő szabálynak nincs requested_by listája, az alapértelmezés pedig a csak-önmaga: magadként kapcsolódhatsz, más nevében nem. A requester_not_listed azt jelenti, hogy a szabálynak van listája, és te nem vagy rajta. A requester_unknown azt jelenti, hogy a hívó saját identitása egyáltalán nem volt megállapítható — ezt elutasítja ahelyett, hogy találgatna.

Javítás. Nevezd meg a hívót a szabály requested_by listájában. Helyettesítő karakter ott nincs — a megszemélyesítés vagy ki van írva, vagy nem történik meg.

Egy hosztonkénti csoportkövetelmény nem teljesült

access denied: you are not authorized to open a session on <host> as <user> (missing_required_group) — if you should have this access, contact your ISG administrator

Ok. A hostgroup.yaml címtárbeli csoporttagságot követel az ilyen címkéjű hosztokhoz, és ez a felhasználó nincs benne a megkövetelt csoport(ok)ban. A felhasználó sora csak az okot nevezi meg; a megkövetelt csoportok az adott címke hostgroup.yaml-szabályában állnak.

Javítás. Vedd fel a tagságot a címtárban, vagy változtasd meg a követelményt. A hostgroup.yaml enforce-a kikapcsolva ugyanez a helyzet lenne-tiltásként auditálódik, és nem blokkol.

A többfaktoros hitelesítés nem fejeződött be

no MFA enrolled for "…"
MFA attempts exhausted
MFA challenge timed out waiting for a response
no email address for "…"
MFA is not configured on this daemon

Ok, sorrendben. A felhasználó sosem futtatta az isg mfa enroll-t, és az mfa.yaml TOTP-módot állít be. Túl sok rossz kód — az ismételt hibák a felhasználót és a forráscímet is kizárják arra az időre, amit az mfa.yaml beállít. Nem jött válasz időben. Nincs mail attribútum a címtár-bejegyzésen, e-mail módban. Egyáltalán nincs többfaktoros konfiguráció.

Javítás. Regisztrációhoz: isg mfa enroll, önkiszolgálóan, futó isg serve mellett. Kizárt felhasználónál a kizárás magától lejár; az isg mfa reset egy regisztrációt töröl, és maga is az mfa_reset_group kapuja mögött van.

A webUI e-mailes kód-lépése rossz kód után: Érvénytelen kód. hibaüzenet a kódmező fölött

Képernyőkép: referencia-környezet (env1), 2026-10-17.

Az identitást nem sikerült feloldani

could not resolve identity for …: …

Ok. Egy címtár-lekérdezés, ami infrastrukturális okból hiúsult meg — nem „nincs ilyen felhasználó", ami túlélhető. A daemon megtagadja a munkamenetet ahelyett, hogy üres csoporttagságokkal folytatná, és abban reménykedne, hogy valamelyik szabály átengedi.

Javítás. Az isg system check jelenti a címtár saját sorát; az LDAP bind ellenőrzés elvégez egy bindot és egy keresést, és megmondja, a kettő közül melyik bukott el.

A célgép elutasította a tanúsítványt

ssh: certificate authentication rejected by target

Ok. Tanúsítvány-módban az átjáró pontosan egy hitelesítő adatot ajánl fel, tehát egy publikuskulcs-hiba egyértelműen azt jelenti, hogy azt a hitelesítő adatot utasították el. A szokásos ok az, hogy a célgépen nincs erre a CA-ra mutató TrustedUserCAKeys. Jelszavas visszaesés szándékosan nincs: egy prompt itt pontosan azt a leletet nyelné le, ami számít.

Javítás. Készítsd elő a célgépet, aztán erősítsd meg az isg system check --probe-hosts-tal.

A célgép saját identitása lett elutasítva

ssh: target host key/certificate rejected

Ok. A célgép olyan hosztkulcsot mutatott fel, amit a szigorú ellenőrzés nem fogad el: más CA írta alá, vissza lett vonva, lejárt, rossz principal a tárcsázott névhez, vagy csupasz hosztkulcs tanúsítvány helyett.

Javítás. Az isg system check megnevezi, melyik. A leggyakoribb az, hogy a tanúsítvány más névre lett kiadva, mint amit a leltár tárcsáz — a principaloknak pontosan egyezniük kell a tárcsázott névvel.

isg system check sorok

no human_access rule names this host

Egyetlen engedélyszabály sem említi ezt a célgépet, tehát senki nem tud kapcsolódni hozzá, függetlenül attól, ki kéri. Vedd fel egy szabály hosts: listájába, vagy egy host_labels szelektorba.

host cert expired / host cert revoked / no host cert issued for this host

Az átjáró saját kiadási nyilvántartása erre a hosztra. A lejárt tanúsítvány a hosztot szigorú módban elérhetetlenné teszi; a sor 30 nappal előtte figyelmeztet. Adj ki újat az isg ca host-cert issue-val.

target offers a plain host key, not a certificate — sshd may have started without the host cert (fail-open); strict-mode connect would be rejected

Az sshd a hoszttanúsítvány nélkül jött fel. A port válaszol és a hoszt egészségesnek látszik, egy szigorú kapcsolódás viszont elutasításra kerülne. Ellenőrizd, hogy a HostCertificate be van-e állítva, és hogy az általa megnevezett fájl létezik-e, aztán indítsd újra az sshd-t.

certificate rejected (cert_rejected)

A célgép elutasított egy tanúsítványt, amit ez a CA írt alá — a TrustedUserCAKeys hiányzik, máshová mutat, vagy eltávolították. Kizárólag --probe-hosts alatt látszik, mert az átjárón semmi nem tudja elolvasni a célgép sshd-konfigurációját.

duplicate host key shared with …

Két hoszt tartja ugyanazt az SSH-hosztkulcsot, jellemzően golden image-ből vagy klónozott pillanatképből, tehát bármelyik fel tudja mutatni a másik identitását. Generáld újra a klón hosztkulcsait (ssh-keygen -A), és adj ki neki új tanúsítványt. A kiadás pontosan ezért tagadja meg a második tanúsítványt egy már tanúsított kulcs fölé.

breakglass_group_required is true but no breakglass_group is set — every break-glass attempt fails as a config error

A fail-closed kapcsoló be van kapcsolva, de nincs mihez ellenőrizni. Állítsd be a breakglass_group-ot az ldap.yaml-ban, vagy kapcsold ki a kapcsolót. Vedd észre, hogy a break-glass mindenkitől meg van tagadva, ha nincs csoport konfigurálva — kapcsolóval vagy anélkül.

required but no group/directory (misconfig)

Ugyanez az alak a többi kapu valamelyikére: az approver_group_required, az mfa_reset_group_required vagy a ca_admin_group_required be van kapcsolva, és vagy a csoportnév, vagy az identitásforrás hiányzik.

ldap.yaml exists, but failed to build a resolver from it

A fájl jelen van, egy címtár-kapcsolatot megkíséreltünk, és nem lett belőle semmi. Az url nélküli ldap.yaml legitim alak — olyankor csak a jogosultsági kapuk csoportneveit hordozza —, és „nincs konfigurálva"-ként olvasódik helyette.

resolver: static without mock_file — every host is unlabelled; label_rules never match

A cmdb.yaml a statikus CMDB-resolvert választja és nem nevez meg mock_file-t, tehát a resolvernek nincs adata: minden hoszt üres címke-halmazra oldódik fel, egyetlen label_rules bejegyzés sem illeszkedhet, és minden pin nélküli hoszt a default_level-t veszi fel. Ez sárga és nem piros, mert támogatott, kimondott alak — egy telepítés, ami a szabályait még a CMDB-export létezése előtt bedrótozza. A fenti elutasítás párja: egy megnevezett, de nem létező mock_file megállítja a daemont, a kulcs kihagyása nem.

Egy zöld sor megnevezi a feloldott útvonalat és azt, amit a fájl hordozott, tehát a szám összevethető azzal, amit vársz:

[OK  ] cmdb.yaml                    resolver: static, 4 label rules, mock_file: /var/lib/isg/cmdb_mock.json, 10 hosts

Az átjárós bejelentkezési fiók vagy a csoportja hiányzik

"isg-login" does not exist — run `isg system provision`

Ok. Az a fiók, amiként az sshd ForceCommand-ja beengedi az embert, vagy az a csoport, amihez az átjáró socketje kötve van, nem lett létrehozva.

Javítás. isg system provision, rootként. Idempotens, és pontosan ezt a két dolgot hozza létre — sosem ír /etc/pam.d/-be vagy /etc/ssh/sshd_config.d/-be, és sosem indít újra szolgáltatást. A testvér-üzenetek, a group "isg-gateway" does not exist on this host és a not a member of isg-gateway, ugyanerre a parancsra mutatnak.

… — this daemon cannot issue certificates until it can read the CA private key again; every human_auth: cert session will fail

A CA aláíró kulcsa olvashatatlan annak a fióknak, ami alatt a daemon fut. Minden munkamenethez frissen aláírt tanúsítvány kell, tehát ez teljes. Vesd össze a CA-könyvtár tulajdonosát a unit User=-ével.

no scrape stamp at … / scrape stamp not refreshed for … — the daemon is probably not running

A diagnosztikai figyelő be van kapcsolva, de a daemon saját bélyegfájlja elavult vagy hiányzik. Ezt a daemonról szóló állításként olvasd, ne a monitorozásodról szólóként: a bélyeg időzítőre frissül, függetlenül attól, hogy scrape-eli-e bármi.

Measured locally as user …

A jelentés első sora azt mondja, hogy a daemont nem kérdezte meg, és hogy miért: a socket nem volt elérhető (a daemon nem fut), a hozzáférés megtagadva rajta (ez a fiók nincs az isg-operators csoportban — a következő sor mondja, hogy add hozzá, vagy futtasd isg-ként), a daemon túl régi a kéréshez, vagy a --local volt megadva. A jelentés többi részét úgy olvasd, mint amit EZ a fiók mérni tud: a rekord-tár hitelesítő fájlja mögötti sorok azt mondják, not measurable from this account, és WARN-t adnak a FAIL — vagy a hamis OK — helyett. Ha az első sor Measured by the daemon (pid N, user isg) over …, a jelentés a daemon sajátja — ugyanaz, amit a /system oldal mutat —, és ebből semmi nem érvényes.

--probe-hosts requires the daemon-mediated audit channel, which is unavailable

A szondák valódi kapcsolatokat nyitnak termelési hosztokra, amik megjelennek minden célgép saját sshd-naplójában; a daemon nélkül nem lenne ISG-auditbejegyzés, ami megmagyarázná őket. Indítsd el az isg serve-öt, vagy add át a --probe-without-audit-ot, és fogadd el a cserét kimondottan.

--probe-hosts refused: another gateway-wide probe run happened too recently — wait …s before running again

Minden futás minden célgép 9 kapcsolatos PerSourcePenalties keretéből 4-et használ el, az átjáró címe ellen könyvelve, nem egy operátoré ellen. A túl korai újrafuttatás kiváltja a célgép kizárását, a kizárás pedig hamis FAIL-t termel, ami újabb próbálkozásra hív. Várd ki az időközt; ne próbáld újra azért, hogy megerősítsd a hibát.

Üzemeltetési tünetek

Az admin felület elérhetetlen

failed to connect (…): …
healthz unreachable (https://…/healthz): …

Az ellenőrzés tárcsázza a címet, majd TLS fölött megkérdezi a /healthz-t. Három dolgot járj végig, ebben a sorrendben: fut-e a daemon (systemctl status isg-ui.service és journalctl -u isg-ui.service); bekötötte-e azt a címet, amit tárcsázol (a --bind alapértelmezése a 127.0.0.1, tehát egy távoli böngészőhöz ki kell szélesíteni — a kiszélesítéshez pedig hitelesítés és TLS kell, lásd fentebb); és átengedi-e a gép tűzfala a portot (alapból 8765).

Az a daemon, ami elindul, aztán azonnal kilép, majdnem mindig az első szakasz indulási elutasításainak egyike — az ok a journalban van.

A jóváhagyások nem érnek el senkit

Az értesítés legjobb-szándékú, és sosem blokkol munkamenetet, tehát egy rosszul konfigurált notify.yaml csendet termel, nem hibát. Ellenőrizd, hogy megnevez-e webhookot vagy kimenő sort; ha egyiket sem, semmi nem kerül kézbesítésre, és a kérés kivárja a teljes időkorlátját.

Egy archivált felvétel nem található

isg storage verify

Azt ellenőrzi, hogy minden felvétel, amit egy munkamenet-rekord archiváltnak mond, ott van-e a folyam-tárban, akkora méretben, amekkorával archiválták. A --deep ezenfelül vissza is olvassa mindegyiket, és összeveti a SHA-256-ját az archiváláskor rögzített hash-sel. A sima formát futtasd rutinszerűen; a mély forma minden archivált felvétel teljes letöltése egy objektumtárról.

Az auditfájlok elcsúsztak a várt tulajdonosuktól

Az Audit artifact isolation sor minden általa mért fájlcsaládot jelent, és az elcsúszást owned by a login account, mode 0644, vagy mindkettőként nevezi meg. Az auditnapló és a munkamenet-artifactok a daemon fiókjához tartoznak, és nem olvashatók csoport vagy mások által. Ez WARN, nem FAIL: már megírt fájlokról szóló tény, és semmi nem állítja meg tőle az átjárót.

Magát az auditnaplót soha nem írjuk újra, sosem söpörjük és sosem mozdítjuk el — szerződés szerint csak hozzáfűzhető. Az alakját, a módját és a rotálási viselkedését az auditnapló-séma írja le, és egy naplószállító ez ellen dolgoz fel.

Egy hosztról hiányzik a break-glass bizonyíték

A hosztonkénti Break-glass command-audit chain sor azt jelenti, ami egy célgép saját továbbításából megérkezett. Amikor not measurable: …-t ír, az átjáró folyamata nem tudta elolvasni a gyűjtőfájlt — útvonal- vagy jogosultsági probléma az átjárón, nem a célgépen.