Servers and security

@anuragbhandari not really there is no consensus yet... A proposal is to force only for hosts at the beginning, WDYT?

@raphaeljadot How about we force ssh keys for the hosts (agate and beryl) and keep password auth for all CTs for now? :)

@anuragbhandari ok for me, let's do this :)

I may have missed something:
-- we can use either encrypted or unencrypted ssh key
-- in the case of encrypted key, you have to unlock it with a password before the key can be sent to the serveur
-- from the net spy point of view, the key is more difficult to break than a password, so we should force the use the ssh key in that case
-- we cannot verify if a user uses an encrypted key
-- if the key is not encrypted and it is stolen, then the door is open
-- otherwise, if we want to access the host with another computer, we can either use the same key (to be copied) or another key sent to the host beforehand (if we cannot use a password)
-- if we loose our key (crash, for example) we cannot access the host anymore
This is the reason why I think we should use an encrypted key most of time but leave the possibilty to use a strong password, thus letting the possibility to handle an issue. But, ok, since we are a team, a member can reset the config for another member in case of trouble.

In fact, the main problem with SSH password is the risk of being sniffed. if someone get the key, he still has to find the password to make sudo. If pass fails, sudo send a warn mail to admin. This is why using SSH key, even with no pass, even not in a safe place seems more secure to me : the pass doesn't flow over the network but stay inside the system.

I think it should go ahead, but we should all make an individual effort to have a highly secure passphrase. An attacker cannot be sudo without the user password anyway, therefore cannot interfere with the system without both.

Roughly what are the risks and efforts involved in migration to Proxmox 3?

Well, not so much risk, but it's quite long as we have to be carefull about several steps (migrate CT in one server, move A records, check the all is working correctly, then upgrade the other server, check all is ok, move all CT in the second server, upgrade the first server etc, It may take several days (not full days, but taking time is good imho :)

@jclvanier You disagree? ;)

Sorry, I would mean: I have no real opinion since I will not be able to do the migration myself.
So abstain = no opposition :)