Прослеђивање SSH агента наспрам копирања кључа: шта заиста цури

Два различита догађаја називају се процурио SSH кључ, и захтевају различите одговоре. Аутентикација јавним кључем шаље јавни кључ и потпис направљен приватним кључем, па приватни кључ никада није поље у захтеву. Прослеђивање агента излаже нешто друго, јер удаљени хост који дохвати ваш прослеђени агент може га замолити да потпише, а да притом никада не држи кључ. Ако то третирате као један догађај, завршавате или с бесмисленом заменом кључа или с делегирањем које остаје активно.

Пријава јавним кључем преноси потпис, а не кључ

Размена аутентикације носи корисников јавни кључ и потпис над подацима сесије. Сервер проверава тај потпис према кључу којем већ верује, зато приватна половина може остати на клијенту преко неповерљиве мреже. Оператер VPN-а који гледа тунел у сваком случају види шифровану SSH сесију.

То описује протокол, а не поузданост сваке крајње тачке на путу. Сачувајте проверу идентитета хоста нетакнутом, јер клијент који прихвата било који кључ хоста одрекао се друге контроле од оне о којој говоримо. Пресретнута сесија и пресретнут кључ су одвојени налази, а само један од њих је губитак акредитива. Држите их у одвојеним реченицама извештаја.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

Прва наредба исписује јавни отисак да га упоредите с оним што сервер наводи. Друга чини проверу кључа хоста експлицитном уместо ослањања на подразумевану вредност коју нико није прочитао. Покрените обе пре него што промените било шта у вези с кључевима, да основица буде документована.

Прослеђивање агента делегира могућност потписивања

Када је прослеђивање укључено, на удаљеном хосту се појављује утичница, а локални агент одговара на захтеве који кроз њу пристижу. Свако ко може користити ту утичницу током сесије може се представити као ви према хоставима који прихватају учитане идентитете. Ниједан приватни кључ не прелази мрежу да би то радило.

Способност је изложеност, а не датотека. Зато прослеђивање припада именованом задатку и именованом хосту, а не свакој вези коју преносни рачунар оствари. Скок-хост који преноси везу без прослеђеног агента обично потпуно уклања потребу.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

Прва наводи које идентитете агент тренутно држи, што је вредно знати пре него што његову утичницу предате другом рачунару. Друга се повезује без делегирања. Трећа показује образац скок-хоста који често потпуно замењује прослеђивање.

Одаберите одговор према доказима које имате

Идентитет за потписивање за који се верује да је изложен тражи поступак замене и опозива, те уклањање његовог прихватања из сервиса који су му веровали. Брисање копије на преносном рачунару оставља сваку другу копију нетакнутом. Почните од сервиса, па очистите клијенте.

Привремени проблем с делегирањем је ужи. Зауставите прослеђивање које није било потребно и с власником инцидента прегледајте које је сесије и идентитете покривало. Замена кључа може уследити, али о томе одлучују докази, а не брига.

Нема уоченог извоза доказује само да се механизам којег сте се плашили није појавио. То не говори ништа о томе шта је још хост с друге стране те утичнице могао учинити.

Држите контроле одвојенима у извештају

Заштите приватни материјал, ограничите ко може тражити од њега потпис, задржите проверени идентитет друге стране. То су три контроле које се међусобно јачају, и ниједна од њих не замењује другу када објашњавате шта се догодило.

Компромитован преносни рачунар или привилегована апликација на њему трећи је случај с много ширим радијусом дејства. Промена VPN руте то не решава и не враћа поверење у кључ који је можда прочитан с диска.

Запишите која је компонента била поуздана, да ли је прослеђивање било укључено и шта је заиста уочено. Управо тај запис чини следећу одлуку одбрањивом, уместо нагађања о томе шта цурење значи.