Where do you have the beats configuration from?
TLS/SSL uses a public-key infrastructure. The service that needs to be authenticated requires the public and the private key. The other endpoint (validating the service) only requires the public key (or even better only the CA certificate - public key). When using TLS/SSL by default only the 'server' a client connects to will be authenticated. In this scenario beats are the client and Logstash is the server.
In addition the server can request the client to authenticate itself (using a certificate). This modus is called client-authentication and must be explicitly enabled in the server (Logstash). With client-auth enabled, the client also requires a certificate and a private key + the server requires the certificate (or CAs certificate) in order to verify/authenticate the client.
Anyways, when using client-auth, each client should have it's own client certificate with matching IP/Domain name. Plus Logstash should only have the CAs public certificate for verification. This boils down to having a proper CA infrastructure.
NEVER share the private key of an endpoint/machine with another machine.
Is it bad practice to distribute the private key to each metricbeat agent?
Indeed it is.
Should that private key have a password?
If possible yes (as private key should be encrypted), but this most likely obfuscate access, as somewhere the passphrase must be configured so the key can be used. Still, encrypting the key can somewhat reduce damage if the key gets stolen.
Without client authentication the beats config should be (at least) like:
output.logstash:
hosts: ["host.url:5044"]
ssl.certificate_authorities:
- /host/certs/logstash-beats.crt
With client authentication the beats config should be (at least) like:
output.logstash:
hosts: ["host.url:5044"]
ssl.certificate_authorities:
- /host/certs/logstash-beats.crt
ssl.certificate: "/host/certs/reporter.crt"
ssl.key: "/host/certs/reporter-private.key"
ssl.key_passphrase: ...