Добавлена статья Авторизация на сервере с использованием SSH-ключей
This commit is contained in:
210
content/articles/authorized-ssh-key/index.md
Normal file
210
content/articles/authorized-ssh-key/index.md
Normal file
@@ -0,0 +1,210 @@
|
||||
+++
|
||||
title = "Авторизация на сервере с использованием SSH-ключей"
|
||||
date = 2025-03-09
|
||||
description = "При установлении соединения с удалённым сервером, будь то через SSH или другие протоколы, критически важно подтвердить свою идентичность для получения доступа к системе. Существует несколько методов аутентификации, но наиболее безопасным и удобным считается использование SSH-ключей. В данном материале мы разберём принципы работы данной технологии, её преимущества перед парольной аутентификацией, а также порядок настройки на практике."
|
||||
|
||||
[taxonomies]
|
||||
tags = ["authorization", "ssh", "server"]
|
||||
|
||||
[extra]
|
||||
quick_navigation_buttons = true
|
||||
toc = false
|
||||
mermaid = false
|
||||
social_media_card = "social_cards/index_authorized-ssh-key.webp"
|
||||
+++
|
||||
|
||||
## Что такое авторизация с ключами?
|
||||
|
||||
Авторизация с ключами (или метод, основанный на паре открытого и закрытого ключа) — это способ идентификации, при котором вместо обычного пароля используются два криптографических ключа:
|
||||
|
||||
- `Закрытый ключ (private key)` — ваш личный "секрет", который остаётся только у вас и никому не разглашается.
|
||||
- `Открытый ключ (public key)` — своего рода "замок", который вы устанавливаете на сервере, чтобы он распознавал вас как авторизованного пользователя.
|
||||
|
||||
Когда вы подключаетесь, сервер сравнивает ваш закрытый ключ с открытым ключом, который у него есть. Если они совпадают, вы получаете доступ. Это похоже на то, как если бы у вас был ключ от двери, а серверу достаточно проверить, подходит ли он к замку.
|
||||
|
||||
## Чем это лучше паролей?
|
||||
|
||||
1. **Надёжность:** Пароли уязвимы к угадыванию или взлому через перебор (brute force), тогда как ключи — это сложные зашифрованные данные, которые почти невозможно разгадать.
|
||||
2. **Простота использования:** После настройки процесс подключения становится автоматическим, и вам не приходится каждый раз вводить пароль.
|
||||
3. **Защита от перехвата:** Даже если кто-то взломает соединение, закрытый ключ остаётся в безопасности, так как он не передаётся по сети.
|
||||
|
||||
## Принцип работы SSH-аутентификации по ключам:
|
||||
|
||||
1. **Создание ключевой пары**
|
||||
На вашем компьютере генерируется пара ключей — открытый и закрытый. Это можно сделать с помощью команды `ssh-keygen`. Важно: закрытый ключ хранится только на вашем компьютере, а открытый нужно передать на сервер.
|
||||
|
||||
2. **Установка открытого ключа на сервер**
|
||||
Открытый ключ добавляется в специальный файл `authorized_keys` на сервере. Это можно сделать через команду `ssh-copy-id` или вручную, скопировав содержимое файла с открытым ключом.
|
||||
|
||||
3. **Процесс аутентификации**
|
||||
При попытке подключения происходит следующее:
|
||||
|
||||
- Сервер генерирует случайное сообщение
|
||||
- Ваш компьютер “подписывает” это сообщение закрытым ключом
|
||||
- Подписанное сообщение отправляется обратно на сервер
|
||||
- Сервер проверяет подпись с помощью открытого ключа
|
||||
- Если подпись верна — доступ предоставляется
|
||||
|
||||
Такая система обеспечивает высокий уровень безопасности, поскольку закрытый ключ никогда не передаётся по сети, а открытый ключ не может быть использован для дешифровки данных.
|
||||
|
||||
## Настройка SSH-доступа с использованием ключей
|
||||
|
||||
Этот гайд поможет вам настроить безопасный способ подключения к серверу через SSH с использованием ключей вместо паролей. Мы рассмотрим процесс на примере Linux/macOS, но те же принципы применимы и для Windows.
|
||||
|
||||
### 1. Создание ключевой пары
|
||||
|
||||
1. **Запустите терминал на вашем компьютере**
|
||||
2. **Выполните команду генерации ключей:**
|
||||
|
||||
```
|
||||
ssh-keygen -t rsa -b 4096
|
||||
```
|
||||
|
||||
где:
|
||||
|
||||
- `-t rsa` определяет тип ключа
|
||||
- `-b 4096` устанавливает длину ключа для повышенной безопасности
|
||||
|
||||
3. **Следуйте инструкциям:**
|
||||
|
||||
- Выберите место сохранения (по умолчанию `~/.ssh/id_rsa`)
|
||||
- При желании установите пароль для дополнительной защиты ключа
|
||||
|
||||
**В результате вы получите:**
|
||||
|
||||
- Закрытый ключ (`id_rsa`) - храните в надёжном месте
|
||||
- Открытый ключ (`id_rsa.pub`) - будет отправлен на сервер
|
||||
|
||||
### 2. Установка ключа на сервере
|
||||
|
||||
1. Подключитесь к серверу обычным способом:
|
||||
|
||||
```
|
||||
ssh username@server_ip
|
||||
```
|
||||
|
||||
2. Перенесите открытый ключ:
|
||||
|
||||
```
|
||||
ssh-copy-id username@server_ip
|
||||
```
|
||||
|
||||
**Альтернативный способ:**
|
||||
|
||||
- Откройте файл `~/.ssh/authorized_keys` на сервере
|
||||
- Добавьте содержимое вашего `id_rsa.pub`
|
||||
|
||||
### 3. Тестирование подключения
|
||||
|
||||
1. Завершите текущую SSH-сессию:
|
||||
|
||||
```
|
||||
exit
|
||||
```
|
||||
|
||||
2. Попробуйте подключиться снова:
|
||||
|
||||
```
|
||||
ssh username@server_ip
|
||||
```
|
||||
|
||||
Если всё настроено верно, вы войдёте автоматически. При наличии пароля для ключа система запросит его ввод.
|
||||
|
||||
### 4. Усиление безопасности (опционально)
|
||||
|
||||
1. Отредактируйте конфигурационный файл SSH:
|
||||
|
||||
```
|
||||
sudo nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
2. Измените параметры:
|
||||
|
||||
```
|
||||
PasswordAuthentication no
|
||||
```
|
||||
|
||||
3. Перезапустите SSH-сервер:
|
||||
|
||||
```
|
||||
sudo systemctl restart sshd
|
||||
```
|
||||
|
||||
После этих действий доступ к серверу будет возможен только с использованием SSH-ключей, что значительно повысит безопасность системы.
|
||||
|
||||
### Важные рекомендации:
|
||||
|
||||
- Регулярно проверяйте список авторизованных ключей
|
||||
- Храните резервные копии приватных ключей
|
||||
- Используйте разные ключи для разных серверов
|
||||
- Не передавайте приватные ключи по незащищённым каналам
|
||||
|
||||
|
||||
## Рекомендации по работе с SSH-ключами
|
||||
|
||||
### Основные правила безопасности
|
||||
|
||||
1. **Защита приватного ключа**
|
||||
|
||||
- Храните его с правами доступа 600
|
||||
- Не передавайте никому
|
||||
- Делайте резервные копии в надёжных местах
|
||||
|
||||
2. **Организация ключей**
|
||||
|
||||
- Создавайте отдельные пары ключей для разных серверов
|
||||
- Используйте понятную систему наименования
|
||||
- Регулярно проверяйте список авторизованных ключей
|
||||
|
||||
|
||||
### Работа с SSH-агентом
|
||||
|
||||
Для удобства работы можно использовать `ssh-agent`:
|
||||
|
||||
```
|
||||
eval $(ssh-agent)
|
||||
ssh-add ~/.ssh/id_rsa
|
||||
```
|
||||
|
||||
Это позволит не вводить пароль от приватного ключа при каждом подключении.
|
||||
|
||||
### Устранение типичных проблем
|
||||
|
||||
1. **Проверьте права доступа:**
|
||||
|
||||
- На клиенте: `chmod 700 ~/.ssh` и `chmod 600 ~/.ssh/id_rsa`
|
||||
- На сервере: `chmod 700 ~/.ssh` и `chmod 600 ~/.ssh/authorized_keys`
|
||||
|
||||
2. **Проверьте настройки сервера:**
|
||||
|
||||
- В файле `/etc/ssh/sshd_config` должны быть строки:
|
||||
|
||||
```
|
||||
PubkeyAuthentication yes
|
||||
AuthorizedKeysFile .ssh/authorized_keys
|
||||
```
|
||||
|
||||
3. **Используйте отладочную информацию:**
|
||||
|
||||
- Подключайтесь с параметром -v: `ssh -v username@server`
|
||||
- Проверяйте логи сервера: `sudo tail -f /var/log/auth.log`
|
||||
|
||||
### Дополнительные меры безопасности
|
||||
<br>
|
||||
- Отключите вход по паролю:
|
||||
|
||||
```
|
||||
PasswordAuthentication no
|
||||
```
|
||||
|
||||
- Ограничьте доступ по IP:
|
||||
|
||||
```
|
||||
AllowUsers username@192.168.1.1
|
||||
```
|
||||
|
||||
- Используйте ключи длиной не менее 4096 бит
|
||||
- Регулярно проверяйте файлы `authorized_keys` на наличие посторонних ключей
|
||||
- При утере приватного ключа немедленно удалите соответствующий публичный ключ с серверов
|
||||
|
||||
Следуя этим рекомендациям, вы сможете обеспечить надёжную и безопасную работу с SSH-ключами.
|
||||
Reference in New Issue
Block a user