Ми передаємо файли на віддалений сервер у нашій програмі, і необхідний метод аутентифікації - це використання ключів SSH.
Отже, я створив ключ, використовуючи ssh-keygen і подав свій відкритий ключ для вставки у файл дозволеного_кейса віддаленого хоста. Однак це відхилило ІТ-безпека, яка сказала, що вона створить для мене ключ, і надішле мені приватний ключ. Причина: "Нам потрібні ключі SSH для підпису групи з безпеки ІТ. Це означає, що ми маємо певну роль у відстеженні та підзвітності".
Очевидно, у мене з цим проблеми. Маючи приватний ключ, згенерований кимось іншим, означає, що я можу змусити цю людину маскуватися як мене, не знаючи мене. Я намагаюся знайти способи спростувати цей аргумент.
Наскільки я можу google, начебто не відомий спосіб підписати ключі таким чином, щоб це допомагало відстежувати особу, яка ввійшла в систему. Той факт, що я представив свій відкритий ключ, означає, що я є власником ключа, а хтось, хто входить на віддалений сервер за допомогою цього ключа, за замовчуванням ідентифікується як я. Як підписання допоможе? І як би вони все-таки підписали?
Хтось, будь ласка, підкаже мене, якщо я помиляюся, дякую!
Гаразд, тепер, коли ми визначили, що неможливо підписати ключі SSH, мені потрібно показати ІТ-безпеці, як вони насправді можуть відслідковувати, хто входив у систему (я повинен бути конструктивним, мабуть, якщо не високої якості ). На власному сервері я встановив LogLevel sshd на DEBUG. Тож тепер, коли я входжу в систему, я бачу такий фрагмент:
Found matching DSA key: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Здається, це хеш-значення. Як я пов’язую цю спинку з тим, який відкритий ключ у файлі санкціонованих ключів використовувався? Я знаю, є ще один рядок, який говорить:
debug1: matching key found: file /home/bofh/.ssh/authorized_keys2, line 1
але це не так корисно, оскільки номери рядків можна легко змінити, якби я вставив ключ у верхній частині файла, натискаючи оригінальні клавіші вниз.
Дякую!