SSH основанная на ключе аутентификация: known_hosts по сравнению с authorized_keys
Это Работы Для Me™. Приложения Gnome имеют встроенную поддержку доступа к файлу по ssh через Gvfs (раньше Gnome-VFS).
Другим способом получить доступ к файлам по ssh является sshfs. Это требует ОС, которая поддерживает FUSE, но большинство нельдов (Linux, Mac OS X, *BSD, Солярис, …) делает в эти дни. Так как файлы представлены через обычный интерфейс файловой системы, никакая определенная поддержка приложений не требуется. Я не знаю, существует ли обертка GUI для него; рабочий процесс командной строки
mkdir ~/example.com
sshfs example.com:/path/to/directory ~/example.com
file-roller ~/example.com/foo.zip
# ...
fusermount -u ~/example.com
Вы перепутываете аутентификацию машины сервера к клиентской машине и аутентификацию пользователя к машине сервера.
Аутентификация сервера
Одна из первых вещей, которая происходит, когда соединение SSH устанавливается, - то, что сервер отправляет свой открытый ключ клиенту и доказывает (благодаря криптографии с открытым ключом) клиенту, что это знает связанный закрытый ключ. Это аутентифицирует сервер: если эта часть протокола успешна, клиент знает, что сервер - то, кто это притворяется, что это.
Клиент может проверить, что сервер является известным и не некоторым сервером жулика, пытающимся выдавать за правильный. SSH обеспечивает только простой механизм для проверки законности сервера: это помнит серверы, которые Вы уже подключили с, в ~/.ssh/known_hosts файл на клиентской машине (существует также файл в масштабе всей системы /etc/ssh/known_hosts). В первый раз, когда Вы соединяетесь с сервером, необходимо проверить некоторые другие средства, что открытый ключ, представленный сервером, является действительно открытым ключом сервера, с которым Вы хотели соединиться. Если у Вас есть открытый ключ сервера, Вы собираетесь соединиться с, можно добавить его к ~/.ssh/known_hosts на клиенте вручную.
Аутентификация сервера должна быть сделана перед отправкой любых конфиденциальных данных в него. В частности, если аутентификация пользователя включает пароль, пароль не должен быть отправлен на неаутентифицируемый сервер.
Аутентификация пользователя
Сервер только позволяет удаленному пользователю войти в систему, если тот пользователь может доказать, что они имеют право получить доступ к той учетной записи. В зависимости от конфигурации сервера и выбора пользователя, пользователь может представить одну из нескольких форм учетных данных (список ниже не является исчерпывающим).
- Пользователь может представить пароль для учетной записи, в которую он пытается войти; сервер затем проверяет, что пароль является правильным.
- Пользователь может представить открытый ключ и доказать, что обладает закрытым ключом, связанным с тем открытым ключом. Это - точно тот же метод, который используется для аутентификации сервера, но теперь пользователь пытается удостоверить их личность, и сервер проверяет их. Попытка входа в систему принята, если пользователь доказывает, что знает закрытый ключ, и открытый ключ находится в списке авторизации учетной записи (
~/.ssh/authorized_keysна сервере). - Другой тип метода включает часть делегирования работы аутентификации пользователя к клиентской машине. Это происходит в управляемых средах, таких как предприятия, когда много машин совместно используют те же учетные записи. Сервер аутентифицирует клиентскую машину тем же механизмом, который используется наоборот, затем полагается на клиент для аутентификации пользователя.
-
1Хороший ответ Gilles, но мой вопрос является любым сервером, может отправить случайный открытый ключ и доказать, что имеет связанный открытый ключ. Как это доказывает, что сервер подлинен? – Alex 09.03.2016, 10:01
-
2@spartacus я думаю, что Вы имели в виду “и доказываете, что он имеет связанный закрытый ключ”, право? Идея состоит в том, что клиент отправляет случайным образом сгенерированное значение (проблема) к серверу, и сервер делает некоторое вычисление на основе закрытого ключа, который зависит от проблемы (таким образом, сервер не может сделать вычисление, пока это не получает эту проблему), и это может только быть сделано со знанием закрытого ключа. – Gilles 'SO- stop being evil' 09.03.2016, 12:25
-
3я думаю Alex, отсылает к первому разу клиентские подключения к серверу. Я думаю, что клиент будет доверять серверу в тот первый раз. Затем сервер отправит свой открытый ключ, и клиент сможет аутентифицировать сервер для следующих соединений. – synack 23.06.2016, 12:15
-
4@synack, в первый раз? Скорее клиент les пользователь принимает решение (“Вы уверены, что хотите продолжить соединяться (да/нет)?”). Сервер ничего не доказывает в той точке. – Gilles 'SO- stop being evil' 23.06.2016, 12:37
-
5Вы правы, это - пользователь, который принимает решение. – synack 23.06.2016, 16:38
Мои друзья дали мне ответ. По умолчанию ключ определяет машину и не пользователя. Таким образом, ключи хранятся в/etc/ssh/. Вот почему я получил другой ключ от того, сохраненного в/root/.ssh