Каковы точные отношения между ключами в многопользовательской установке SSH?
Esto depende de su formato de imagen y de cómo crea la imagen en primer lugar, sin embargo, generalmente uso virt -sysprep para desconfigurar imágenes, los detalles se pueden encontrar aquí :"http://libguestfs.org/virt-sysprep.1.html" El comando se vería así:
# virt-sysprep --operations ssh-hostkeys,udev-persistent-net,machine-id -a disk.img
Luego consideraría usar cloud -init para configurar las nuevas máquinas virtuales en el arranque, nuevamente, esto depende de su tecnología de hipervisor sobre cómo debería configurarse.http://cloudinit.readthedocs.io/en/latest/
still logged as user, ssh-copy-id root@vm1 (skipping the password auth step...) succeeds, copying the [user]'s public key to the authorized_keys file in vm1's root ~/.ssh/ folder. The key is still tagged with the name and machine of the [user].
Принцип аутентификации на основе ключа SSH -заключается в том, что:если клиент может криптографически доказать, что он владеет закрытым ключом, который соответствует открытому ключу в ~/.ssh/authorized_keysфайле запрошенного имени пользователя на сервере, доступ разрешен. Вот именно. «Имя и машина [пользователя]» на самом деле представляют собой текстовое поле свободной -формы, которое позволяет людям легко идентифицировать конкретный открытый ключ. Содержимое этого поля никак не используется при аутентификации.
По умолчанию сервер SSH не заботится о том, какое имя пользователя входящее соединение утверждает на стороне клиента, потому что:
- клиент может не захотеть сообщать об этом серверу
- сервер никак не может проверить имя пользователя на стороне клиента -
- Даже если это так, злонамеренный клиент с украденным ключом может быть настроен с любым именем пользователя на стороне клиента -, которое выгодно клиенту.
Если вы хотите ограничить использование аутентификации с помощью ключа SSH, вы можете сделать это, поставив перед ключом SSH в файле authorized_keysпрефикс from="<hostname-or-IP-address-pattern>". Как сказано на справочной странице sshd:
The purpose of this option is to optionally increase security: public key authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key).
To me, this seems to weaken the root access protection on the target machine because the user's public key verifies the login privilege, but the target root's corresponding private key is not stored in a restricted root account ~/.ssh/ folder on the source machine.
Это верно только в том случае, если исходная машина всегда гарантированно находится под тем же административным контролем, что и целевая машина. SSH не предполагает этого и признает, что бесполезно основывать что-либо на том, кем пользователь исходной машины называет себя , если нет способа проверить это утверждение.
Если вы имели в виду, что user@vm1запустил ssh-copy-id root@vm1и успешно ввел пароль root, то вы, возможно, были удивлены тем, что ssh-copy-idсделал в этом случае. Если в user@vm1:.ssh/id_*не было закрытого ключа SSH, а sshdиз vm1разрешала пересылку агента SSH, тогда ssh-copy-idиспользовал соединение агента для получения открытого ключа с клиентского хоста Mac. И вот как открытый ключ, помеченный именем и машиной [user], оказывается в файле root@vm1:.ssh/authorized_keys.
Современная macOS имеет расширенный ssh-agent, который интегрируется со связкой ключей macOS и по умолчанию доступен для каждого сеанса пользователя macOS. Если вы ожидаете простое старое поведение OpenSSH, это также может быть сюрпризом.