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.

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.

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.