Що насправді означає невідомий SSH-ключ
SSH-ключ, доданий до облікового запису GitHub, — це облікові дані, які можуть автентифікуватися від імені цього облікового запису. Побачити ключ, якого ви не впізнаєте, — це привід для перевірки, а не висновок. Ключ може належати пристрою, про який ви забули, налаштуванню колишнього члена команди, старому ноутбуку або чомусь, що ви не авторизували. Безпечний підхід — визначити власника й призначення, перш ніж щось видаляти, адже видалення ключа, який використовується легітимним робочим процесом, зламає цей процес.
GitHub розглядає кілька речей як окремі шляхи доступу. Особистий SSH-ключ, deploy-ключ, прикріплений до репозиторію, і авторизований застосунок OAuth — це різні механізми з різними областями дії. Аудит одного не є аудитом інших.
GitHub рекомендує перевіряти SSH-ключі, deploy-ключі та авторизовані застосунки як окремі шляхи доступу. Джерело
Чекліст до і після
Використовуйте це як робочий список. Стовпець «до» — про збір фактів; стовпець «після» — про підтвердження результату.
| Етап | Перевірка | Чому це важливо |
|---|---|---|
| До | Перелічіть усі SSH-ключі, показані в обліковому записі, з їхніми назвами та будь-яким видимим відбитком або деталями створення | Потрібна повна картина, перш ніж вирішувати, який запис невідомий |
| До | Зіставте кожен ключ із пристроєм або особою, яку можете назвати | Ключ без назви — це той, який варто поставити під сумнів |
| До | Запитайте, чи залежить від ключа якийсь поточний робочий процес (збірки, розгортання, спільна машина) | Видалення ключа в активному використанні зламає цей процес |
| До | Перевірте, чи той самий доступ також надано через deploy-ключі або авторизовані застосунки | Це окремі шляхи, і їх потрібно перевіряти окремо |
| До | Визначте рішення: залишити, замінити чи видалити | Застарілий ключ може потребувати заміни, а не простого видалення |
| Після | Підтвердіть, що ключ більше не відображається в списку SSH-ключів облікового запису | Видимий список — це ваше перше підтвердження |
| Після | Підтвердіть, що постраждалий робочий процес досі працює або що у вас є шлях заміни | Видалення не повинно залишати легітимний процес без виходу |
| Після | Занотуйте, що ви видалили і коли, не записуючи сам матеріал ключа | Запис допомагає в майбутніх аудитах |
Видалення SSH-ключа облікового запису
Саме видалення відбувається в налаштуваннях облікового запису. Задокументований шлях GitHub — це Settings, потім SSH and GPG keys, де можна переглянути SSH-ключі облікового запису й видалити ті, що не розпізнаються або застаріли.
У Settings, SSH and GPG keys перегляньте SSH-ключі облікового запису й видаліть ті, що не розпізнаються або застаріли. Джерело
Тримайте вузьку область дії. Цей крок видаляє SSH-ключ облікового запису. Він не видаляє deploy-ключі, не відкликає авторизовані застосунки й не змінює вміст репозиторію. Якщо ваш аудит виявив проблеми в цих сферах, розглядайте їх як окремі завдання.
Легітимні робочі процеси, які варто врахувати перед видаленням
Не кожен незнайомий ключ ворожий. Перш ніж діяти, розгляньте ці типові ситуації:
- Пристрій, яким ви більше не користуєтесь. Старий ноутбук або робоча машина можуть досі мати зареєстрований ключ. Якщо пристрій у вас, ви можете підтвердити збіг; якщо ні, видалення зазвичай правильний вибір.
- Спільна або командна машина. Хтось інший міг додати ключ із легітимною метою. Підтвердіть у власника, перш ніж видаляти.
- Налаштування розгортання або автоматизації. Якщо ключ використовується запланованим процесом, його видалення може зупинити цей процес. Спершу визначте залежність.
- Ключ, який ви створили й забули. Назви та дати створення часто освіжають пам’ять. Якщо можете зіставити його з власним минулим налаштуванням, можете залишити або замінити його, а не видаляти.
Якщо сумніваєтесь, безпечніша послідовність — визначити, потім замінити ключем, який ви контролюєте, а потім видалити старий запис. Це зберігає робочий шлях, поки ви закриваєте невідомий.
Чого цей процес не робить
Видалення SSH-ключа — це точкова дія, а не повне очищення облікового запису. Воно не:
- відкликає застосунки OAuth або інші авторизовані інтеграції;
- видаляє deploy-ключі з репозиторіїв;
- доводить, хто створив ключ і чому;
- підтверджує, що іншого шляху доступу не існує.
Розглядайте кожен із цих пунктів як окрему перевірку. Аудит — це набір маленьких, перевірюваних кроків, а не один перемикач.
Де місце пошуку за іменем користувача, а де ні
Публічний пошук за іменем користувача може допомогти побачити, з чим, імовірно, пов’язаний відомий хендл на публічних платформах. Це корисний контекст, коли ви намагаєтесь зрозуміти особу або її онлайн-слід. Це не спосіб переглянути налаштування облікового запису GitHub, і він не може сказати, кому належить SSH-ключ. TraceSeek, застосунок, про який пише TruthsSeek, перевіряє відомі публічні імена користувачів на 3.000+ платформах і повертає перший скан за 20–30 секунд, перший скан безкоштовний. Він не керує налаштуваннями GitHub, а публічний збіг — це зачіпка, а не доказ власності.
Безпечне поводження з обліковими даними
Ніколи не публікуйте приватний ключ, токен або повні облікові дані в чаті, issue, скріншоті чи дописі на форумі. Якщо вам потрібна допомога з ідентифікацією ключа, діліться лише несекретними деталями, як-от його назва або видимий відбиток, і лише з тим, кому довіряєте. Якщо підозрюєте, що ключ було розкрито, видалення з облікового запису — це один крок; ротація всього, що від нього залежало, — окреме рішення, яке слід ухвалювати виважено.