Дозволи для ssh і домашнього каталогу

sshd відмовиться прийняти аутентифікацію відкритого ключа, якщо домашній каталог користувача доступний для групи, навіть якщо ~/.ssh встановлено на 700? Якщо дозволи на ~/.ssh є прийнятними, чому дозволяються дозволи ~ має значення?

ssh permissions file-permissions

— Blacklight Shining
джерело

Відповіді:

Думаю, причина полягає в тому, що якщо ваш домашній каталог може бути записаний кимось іншим, то зловмисний користувач може створити ~/.ssh, додайте потрібні клавіші, а потім змініть дозволи на неї до 700.

Навіть якщо у вас вже є ~/.ssh, його можна просто перейменувати на щось інше і створити нове.

Однак на сучасних системах такий трюк зазвичай неможливий через chown працюючи тільки для суперкористувачів, це не завжди було так:

У попередніх версіях UNIX всі користувачі могли запускати команду chown змінити право власності на файл, який вони належали, на будь-який інший користувача в системі. ( http://www.diablotin.com/librairie/networking/puis/ch05_07.htm )

Чи поводиться chmod так чи інакше залежить від параметри компіляції libc , а для безпеки сервера OpenSSH трохи параноїдальний.

— aland
джерело

Вони не зможуть chown це вам, правда, не без кореневого доступу… і якщо вони мають кореневий доступ, вони можуть потрапити ~/.ssh так чи інакше.

— Blacklight Shining

@BlacklightShining оновив відповідь

— aland

Дякую, це має більше сенсу. Чи є тоді спосіб зробити ssh Чи не робите це сувора перевірка? І оскільки директорії, які ви робите, мають вашу групу за замовчуванням (яку тільки ви належите), це не так безпечно, як 770?

— Blacklight Shining

@BlacklightShining Можна використовувати StrictModes no в sshd_config, але він вимкне всі перевірки дозволів. Ви також можете змінити місцезнаходження свого authorized_keys файл з AuthorizedKeysFile можливість бути поза вашим $HOME. Немає способу. Наскільки мені відомо, вимкнути лише одну з перевірок дозволів, якщо ви не зміните вихідний код ssh-server.

— aland

Гаразд, щоб виправити це ви могли б піти небезпечно маршрут і встановити StrictModes no у вашому /etc/ssh/sshd_config як вже згадувалося, або ви могли б перейти на складний спосіб і зберегти ssh-ключі для всіх користувачів у каталозі, доступному тільки для root. Ось кроки для останнього:

Створіть каталог для зберігання нових ключів. Тут ми використаємо /usr/share/sshkeys, що може бути не найкращим місцем, але найкращим з моєї голови.
```
sudo mkdir /usr/share/sshkeys
```
Редагувати /etc/ssh/sshd_config включити лінію
```
AuthorizedKeysFile /usr/share/sshkeys/%u
```
Скопіюйте старий файл авторизованого ключа з вашого користувача (тут він називається "exampleuser") у новий каталог
```
mv /home/exampleuser/.ssh/authorized_keys /usr/share/sshkeys/exampleuser
```
(Необов'язково, але рекомендується, оскільки користувач прикладу очікує, що він зможе додавати ключі звичайним способом) Посилання нового ключового файлу на місце старого і надання користувачеві доступу до нового файлу ключа
```
sudo chown exampleuser /usr/share/sshkeys/exampleuser
sudo chmod 600 /usr/share/sshkeys/exampleuser
ln -s /usr/share/sshkeys/exampleuser /home/exampleuser/.ssh/authorized_keys
```
Перезапустіть демон ssh
```
sudo service sshd restart
```

— con-f-use
джерело

Ідеальний. Тепер нам просто потрібен спосіб автоматичного налаштування dpkg-reconfigure openssh-server.

— Blacklight Shining

Зачекайте, що про інші файли в ~/.ssh? Не буде ssh скаржаться на їхню небезпеку? Зловмисник не зможе read вони могли рухатися ~/.ssh вбік і зробіть нове з чим завгодно known_hosts вони люблять…

— Blacklight Shining

Ні, розташування ключового файлу було змінено /etc/ssh/sshd_config. Це означає, що ssh перевірить права нового файлу, які не читаються у групах. Все, що може зробити зловмисник, це змінити файл, який тепер не має відношення до ssh. Посилання просто знає, де знаходиться його новий файл.

— con-f-use

Крім того, я виправив суміш файлів на кроці 4. Не знаю, чи перевіряє ssh дозволи на інші файли в ~/.ssh. Для мене це не було. Якщо це для вас, перемістіть інші файли таким же чином. Проте файл, що містить авторизовані ключі, є найважливішим для безпеки.

— con-f-use