Можно ли каким-то образом настроить ssh-сервер, который не требует имени пользователя, пароля или сертификата для входа в систему? Если это невозможно, если бы я дал всем клиентам один и тот же открытый ключ, было бы каждое соединение зашифровано индивидуально? (т.е. пользователь A не может расшифровать полезную нагрузку соединения пользователя B)
Я хочу предоставить доступ к одной программе, которая запросит имя пользователя и пароль.
Однако шифрование важно, и пользователи не должны иметь возможность подглядывать друг за другом.
Спасибо
Я не думаю, что вы можете удалить часть аутентификации SSH, потому что вам всегда нужно имя пользователя для открытия сеанса, но вы можете установить пустой пароль и установить PermitEmptyPasswords на да в вашей конфигурации sshd.
Но это не совсем безопасно, лучше использовать аутентификацию по ключам.
Если вы дадите своим клиентам открытый ключ, это означает, что они смогут разрешить вам подключаться к своему ssh-серверу, а не к вашему.
Я думаю, вы хотите, чтобы клиенты подключались к вашему ssh-серверу. В этом случае клиенты должны предоставить вам свой открытый ключ, и вы позволите им подключиться. Если бы все клиенты использовали один и тот же открытый ключ для подключения к вашему ssh-серверу, это означало бы, что все клиенты используют один и тот же закрытый ключ, и это не вариант (не ваша роль предоставлять закрытый ключ, и закрытый ключ не должен использоваться совместно )
Что касается шифрования и отслеживания, шифрование выполняется с помощью ключей сеанса, а не открытого / закрытого ключа, но для обмена ключами сеанса ssh использует открытый / закрытый ключ.
Поэтому, если все ваши клиенты используют одни и те же закрытые ключи, если они отслеживают сеанс с самого начала, они могут расшифровать сеанс, если они будут отслеживать сеанс после обмена ключами сеанса, расшифровать сеанс будет очень сложно.
Хорошая статья о том, как работает ssh http://www.eng.cam.ac.uk/help/jpmg/ssh/ssh-detail.html
Думайте о закрытом ключе как о секрет. Когда вам нужно что-то доказать, например, вашу личность в данном случае, вы можете потребовать знаю секрет, в данном случае закрытый ключ ssh. Открытый ключ таков: «открытый», и в этом смысле его нельзя использовать для доказательства чего-либо.
Это согласуется с рекомендацией, что никогда не давайте один и тот же закрытый ключ более чем одному пользователю. Огромное количество дыр в безопасности возникает из-за попыток сделать процессы безопасности менее обременительными. Есть и безопасные способы сделать это. Но вам, как администратору, придется работать, иначе вы автоматически открываете свою сеть и ее пользователей для атаки.
"Не выбирайте ярлыков"
Немного поздно, но вы можете заставить пользователя запускать определенную программу при входе в систему (любыми способами), установив его оболочку для этой программы в / etc / passwd. Я считаю, что есть более сложный способ использования sshd с использованием файлов .sshrc, но я не предполагаю, что вы используете OpenSSH - хотя все это находится в файлах man.
Придерживайтесь имен пользователей и паролей, если вы все равно планируете запрашивать их у клиентов. Вам нужно будет предоставить один и тот же закрытый ключ всем клиентам, если вы встраиваете его в клиентское программное обеспечение, и поэтому они будут иметь доступ ко всему, что может использовать этот ключ, то есть к любой учетной записи на сервере.
Вы действительно хотите создать отдельные учетные записи для каждого пользователя, и нет реальной причины использовать ключи, когда клиенты ожидают, что им придется вводить имена пользователей и пароли (они будут сбиты с толку, насколько это безопасно, если им не нужно давать пароль каждый раз).
Чтобы упростить поддержку, вы захотите, чтобы было действительно легко изменять имена пользователей и пароли - возможно, центральный сервер каталогов, на котором работает LDAP, с красивыми графическими интерфейсами для службы поддержки.
Пользователи воля иметь возможность отслеживать друг друга, поскольку они смогут получить доступ к пространству памяти других процессов (при условии, что они могут запускать произвольные программы).