"without-password' means password authentication cannot be used for root sessions, hence some other authentication method must be used. According to the same link, Hsphere uses shared keys.

A properly functioning ssh(1) client will not prompt for passwords. Brute force scripts (ssh attacks) don't use real ssh clients and will submit passwords anyway, which sshd(8) will ignore, though it will tell you about them it its logs.

Choices:

ignore this, knowing that another valid form of authentication must be used for root access.

In combination with the firewall, above, set up a second sshd(8) daemon listening on another port, that disallows root logins. Use this other daemon for non-Hsphere ssh use.

If Hsphere allows non-standard ssh connection ports, set up a private sshd daemon to listen for hspehre connections on another port, and use the default port 22 daemon for everything else. Set up an appropriate firewall, allowing only hsphere servers access to this daemon.

you cannot change the default port for SSH for hsphere because you're going to need to change it in all script and some are compiled so you can't do it.
And if the CP can't talk to other machine its all your setup that going to stop working.

Anyway with "without-password" the guy need to have access to your machine first to generate a key to put it on his machine to after that login. Even with this option you can't log with the root password directly.

If you concern about security about your SSH, your best choice here is to add Firewall to limit access to SSH to have 1 machine behind is to accept SSH.

Anyway with "without-password" the guy need to have access to your machine first to generate a key to put it on his machine to after that login. Even with this option you can't log with the root password directly.

You don't have to generate keys on the system you will be accessing using that key. You can generate keys on any system, even Windows using puttygen. You don't need SSH access to the system in order to put the key in place, either. You just need to be able to write to ~/.ssh/authorized_keys. Which is why .ssh/ should have permissions set to 700, so that if someone hacks the web server, gets shell access, etc, they still won't be able to write to that directory without having root access.