LINUX.ORG.RU

Парольный доступ по SSH

 , ,


0

2

В целях безопасности отключил доступ по паролю в sshd_config:

PasswordAuthentication no
С удаленных устройств подключаюсь по приватному ключу. Но в таком случае при подключении на локалхосте так же требуется приватный ключ, а хранить приватный ключ на сервере вроде как считается не безопасным. Как настроить сервер так чтобы на локалхосте он подключался по паролю, а с удаленных устройств без пароля, по приватному ключу?

хранить приватный ключ на сервере вроде как считается не безопасным
настроить сервер так чтобы на локалхосте он подключался по паролю, а с удаленных устройств без пароля, по приватному ключу

/0. Наоборот тогда надо.

svinarenko
()
Ответ на: комментарий от Bers666

У меня cygwin, там это все немного иначе реализовано.

Grantrol
() автор топика
Ответ на: комментарий от Grantrol

Что зачем? Ты хочешь на серверах ключ держать, а на локалхосте не держать, при том, что как раз на серверах ключ держать небезопасно. Хде лохика?

svinarenko
()

сервер
cygwin

омфг

Deleted
()

Наркоман? Ну сгенерируй для локалхоста, с которого подключаешься к серверу, ключ защищённый с паролем.
Если ты имел в виду, что с самого _сервера_ тебе зачем-то нужен приватный ключ — обратись в ближайший наркодиспансер.

anonymous
()
Ответ на: комментарий от Grantrol

Ну тогда на ssh сервере разрешаешь, как положено, оба вида аутентификации, а с каждой «клиентской» стороны (локальной, удаленной) используешь один нужный (man ssh_config).

blexey ★★★★★
()
Последнее исправление: blexey (всего исправлений: 1)
Ответ на: комментарий от svinarenko

/0. Наоборот тогда надо.

Не, не наоборот, я кажется понял: тс имеет ввиду, что если на локальный ssh сервер тоже ходить по ключу (как все нормальные сетевые пользователи этого сервера), тогда приватный ключ придётся держать на этом же сервере, что не есть гуд.

blexey ★★★★★
()
Ответ на: комментарий от blexey

Ага, а то всякий, кто сможет зайти на этот сервер и иметь после того достаточно прав для чтения этого ключа, сможет зайти на этот сервер.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Ага, а то всякий, кто сможет зайти на этот сервер и иметь после того достаточно прав для чтения этого ключа, сможет зайти на этот сервер.

Поправлю для ясности: всякий, кто сможет зайти с достаточными правами для чтения этого ключа, сможет зайти и под этим юзером.

blexey ★★★★★
()
Ответ на: комментарий от t184256

Это понятно. Но вдруг его пользователи балуются рутом, sudo или suid... Можно, конечно, полагаться на исправность софта и порядок с правами. Но проще, всё-таки, не хранить.

blexey ★★★★★
()
Ответ на: комментарий от blexey

Ясное дело проще, как и ясное дело, что дополнительно валяющийся ключ безопасность снижает. Но ты краски пересгустил.

t184256 ★★★★★
()
Ответ на: комментарий от Grantrol

Как-то так:

1. /etc/sshd_config:
...
PubkeyAuthentication yes
PasswordAuthentication yes
# еще можно попробовать навязать обоим типам клиентов соответствующие AuthenticationMethods, но я на себе не пробовал:
...
Match Address 127.0.0.0/8
AuthenticationMethods password
...
Match Address 192.168.0.0/24
AuthenticationMethods publickey
...

2. ~/.ssh/config (удаленный клиент):
...
Host my_remote_server
PreferredAuthentications publickey
...

3. ~/.ssh/config (локальный клиент):
...
Host my_local_server
PreferredAuthentications password
...

4. Пароли удаленных клиентов поменять на сервере, чтобы не знали и пользовались только своими ключами. Или навязать им разные AuthenticationMethods, если получится с Match.

blexey ★★★★★
()
Последнее исправление: blexey (всего исправлений: 1)
Ответ на: комментарий от Grantrol

AgentForwarding

Использование приватного ключа через один хоп без сохранения самого ключа на промежуточном хосте.

PunkoIvan ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.