OpenSSH – Adding SSH Key from PuTTY to Authorized Keys

First, there's no security benefit to only allowing users to connect with a username of "developer". If you want users to have shared access to the same group of files, put them in the same UNIX group and have /var/Tasks be owned by that group. Seperate usernames allow for auditing, better troubleshooting, etc.

As for your other questions:

• Client usernames are not important. When connecting, users can specific which remote username they want to use: ssh username@example.com
• You can populate authorized_keys with as many user keys as you have diskspace for, and you can do it before the server is deployed. Also, the same authorized_keys file is read regardless of which portnumber sshd is listening on.
• Yes, the server's public key will be stored in known_hosts and first time connections will prompt the user to accept the remote key. This part is what makes SSH able to detect man-in-the-middle attacks, and if users just blindly accept any key, SSH becomes vulnerable to man-in-the-middle attacks. If you have sufficient access to the client machines, you can add the remote servers key fingerprint to each client's known_hosts. That's the only way you can avoid this prompt.
• You can use the AuthorizedKeysFile keyword in sshd_config to specify where you want sshd to look for keys on the server. I put keys in /etc/ssh/keys/%u where %u is a file with the users name and I make sure the user only has read-access.

in order to connect to an SSH server and authenticate with your public/private keypair you have to first share your public key with the server.

this is done by copying the public key for your private key to the server, and adding it to ~/ssh/authorized_keys either by copy/paste, copying id_rsa.pub to ~/.ssh/authorized_keys on the server or with cat id_rsa.pub >> ~/.ssh/authorized_keys, appending it to the list.

when you connect, the server uses your public key to sign a challenge, and your client uses your private key id_rsa to decrypt the challenge, re-encrypt it with the server's public host key and send it back.

the host verifies that you decrypted the challenge properly, by decrypting your response with its private key, and the client/host establish an encrypted connection, based on the shared data, not on your public/private keys.

at NO POINT in the exchange is your private key, or the host's private key exchanged or revealed to one another. your public key IS stored on the server, but that's why it is a PUBLIC key.