ssh авторизация

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

Так это понятно. Еще раз - я хочу зайти другим юзером на сервер, для этого копирую свой приватный кей ему в .ssh. По идее должно быть достаточно, но без копирования значения из known_hosts не работает

Свой приватный ключ другому юзеру? Ну вот это и неправильно. Сгенерируй новую пару ключей. От этого юзера. Приватный оставь у него, и пусть он его никому не показывает. Публичный тебе надо передать на сервер и там добавить в authorised_keys.

так это чтож, если у меня 10 моих личных аккаунтов, я каждому должен генерировать ключ? Ну да хрен с ним. Предположим я хочу СВОЙ ключ использовать на другой системе, почему не пашет без known_hosts?

так это чтож, если у меня 10 моих личных аккаунтов, я каждому должен генерировать ключ?

Конечно. Иначе какой в них вообще смысл?..

Предположим я хочу СВОЙ ключ использовать на другой системе

Ты уверен, что этого хочешь? Не проще тогда вообще пароль использовать? Never copy a private key from a host to another. If one workstation is compromised, revoke all those keys. [по теме]

почему не пашет без known_hosts?

По идее known_hosts это вообще немного про другое.

«Ты уверен, что этого хочешь?»

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

«По идее known_hosts это вообще немного про другое.»

https://s13.postimg.org/6knef8zc7/pubkeys.jpg

Ну и? Ты путаешь host key и client key. При подключении по ssh первый раз на неизвестных сервер ты авторизуешь этот сервер по отпечатку его host key. В следующий раз при коннекте, если отпечаток сменился(а ты ничего на сервере не менял) - это будет расценено как попытка MitM-атаки.

В идеале пару приватный/публичный ключ ты генеришь на каждом клиенте. А потом публичные(не приватные!) ключи добавляешь в authorized_keys на сервере.

Если серверов много - есть мнение задуматься о централизованной авторизации. Публичные SSH-ключи необязательно хранить на каждом сервере, их можно хранить, например, в LDAP.

спасибо за расширенный ответ, вроде проясняется. Вообще-то я сделал очень удобное монтирование по sshfs с помощью x-systemd.automount и споткнулся на авторизации. Т.е я так понял, надо в любом случае хоть раз зайти по ssh на сервер чтобы получить его host key или скопировать его из known_host? Про MitM-атаку тоже было интересно почитать :)

Т.е я так понял, надо в любом случае хоть раз зайти по ssh на сервер чтобы получить его host key или скопировать его из known_host?

Есть пара настроек позволяющих это игнорировать, но тогда сам понимаешь - никакой защиты от MitM.

Про MitM-атаку тоже было интересно почитать

Общий принцип таков(конкретно для SSH возможно нужны дополнительные телодвижения):

1. Делаем SSH-сервер в том же сегменте сети что и целевой
2. Спуфим ARP
3. Дожидаемся клиента у которого отключена проверка ключа сервера или он бездумно тычет «да, мне наплевать что ключ изменился»
4. Выбрасываем ему диалог авторизации
5. Пересылаем авторизационные запросы от клиента настоящему серверу и от него - обратно

Ну а дальше возможны варианты. Если реализация SSH-сервера уязвима к replay-атакам, то там очень широкий простор для всякого разного.

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

обалдеть, очень интересно. Где можно тебе в карму плюсануть? :) Большое спасибо за ответы

Честно говоря описанное ТС я как раз делал (включая копирование known_hosts), только не применимо к разным пользователям, а к разным клиентам. Но тут много «но» почему именно так оказалось удобнее.
1. scp при нестабильной связи показал себя лучшим решением.
2. клиентские железки (специализированный софт) работают в жутких условиях и представляют из себя ту еще помойку, летят часто. Поэтому «специально обученным» лишних телодвижений при развороте сдохшей железки меньше совершать.
3. На сервере они попадают в chroot только для копирования файлика. Хотя это уже так, just for fun, или моя излишняя паранойя, один фиг это распределенная корпоративная сеть где у рядовых юзверей к этим сетям доступа нет (это я про арпспуфинг).

Все описаное мной - это упрощенное описание схемы атаки, большую часть которого можно найти даже на википедии(что уже говорит о том что это не какой-то там rocket science). Если тебе так интересно, то лучше вместо поиска кармы(которой все равно тут нет :-)) поищи лучше книжки по безопасности сетей. Там еще много такого интересного написано. Заодно и общую грамотность по сетям подтянешь ;-)

Но вообще да, я в своё время когда узнал о некоторых возможностях SSH(X11 forwarding, port forwarding, socks proxy), то долго восхищался теми, кто эти возможности писал и интегрировал - очень всё складно и толково получилось в результате. Но да, если с ним ни разу не до этого сталкивался, некоторые его возможности могут показаться непривычными.

«некоторых возможностях SSH»

я тоже когда про SSH-туннели узнал, возился некоторое время. Достучаться с рабочего компа до порта на домашнем сервере, который слушает только на локалхосте очень впечатлило.

«поищи лучше книжки по безопасности сетей»

так постоянно самосовершенствуюсь :) Однако некоторые вещи гораздо быстрее на форуме узнать(правда далеко не всегда) и кстати может быть еще что-то новое заодно. Вообщем еще раз спасибо за ответы