The standard way is to store them in plaintext files, and secure them with filesystem permissions. This is as good as the security of the accounts that can read them, and your ability to keep those permissions in place over time.
There's a tendency for locked down permissions to get looser as different applications write to the files or their directories over time. Directory ACLs can help, for example:
setfacl -m d:g::-,d:o:- /secret/dir
to try to enforce empty permissions for group and other whenever new files are written in the directory - for example if an editor creates a new copy of the password file, instead of updating the original file.
If you want to use ssh keys instead, you could store the secrets in plaintext on another host that only allows login by ssh keys. You'd have to script logging on on that host, reading the password file, then using it in an ssh command. That would be hard to do reliably and securely, but it could work.
Most options you can think of ultimately rely on filesystem permissions for their security. Chapter 11 of SSH: The Secure Shell has a discussion of the trade-offs.