, there are multiple approaches, depending on which method is in use -- but for the SSH and SFTP methods, it's as simple as "if you can ssh somewhere without a password, tramp won't ask for one either". You can adjust the username used by default for connection to a particular host via something like
in ~/.ssh/config; you can arrange to use a different private key (corresponding to a public key in ~/.ssh/authorized_keys on the server side, both generated at the same time via ssh-keygen) via the IdentityFile option; using "IdentitesOnly yes" will force that identity to be used even if you're using ssh-agent (or something else like a PKCS11Provider) to offer other keys by default...
... really, getting ssh to connect without a password is really not rocket science. Unfortunately it is also not widely documented, and it's very easy to come up with approaches that appear to be safe but actually provide no security at all. (e.g., if you have a network-shared $HOME filesystem with your keys in ~/.ssh, if you want those keys to provide any security at all when sshing around between the hosts sharing the filesystem you have
to use AuthorizedKeysCommand or something similar in sshd_config to extract the list of authorized keys from somewhere not on that network-shared filesystem, or an attacker can just generate a brand new key on one machine, drop it in ~/.ssh/authorized_keys, and ssh everywhere in the cluster freely! Of course if you're using writable shared $HOME there are all sorts of other attacks an intruder on one system can carry out, like editing your ~/.profile...)