Перадача агента 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 не вырашае яго і не аднаўляе давер да ключа, які мог быць прачытаны з дыска.

Запішыце, якому кампаненту давяралі, ці была ўключана перадача і што насамрэч назіралася. Менавіта гэты запіс робіць наступнае рашэнне абараняльным, а не здагадкай пра сэнс уцечкі.