TL;DR summary: If you have a SSL/X.509 certificate+key, just give the private key file to ssh. Or, if you already have a SSH key in id_rsa, just use it with OpenSSL when signing a CSR. That's all.
Let's assume you have an user's SSL certificate in joeuser.pem and its private key in joeuser.key.
Since X.509 uses standard RSA keys, and so does SSH, you should be able to just tell your SSH client to use joeuser.key -- the only requirement is that it be in an understandable format.
Look at the insides of joeuser.key and check if it looks kinda like this:
-----BEGIN RSA PRIVATE KEY-----
MGECAQACEQCxQaFwijLYlXTOlwqnSW9PAgMBAAECEETwgqpzhX0IVhUa0OK0tgkC
CQDXPo7HDY3axQIJANLRsrFxClMDAghaZp7GwU2T1QIIMlVMo57Ihz8CCFSoKo3F
2L/2
-----END RSA PRIVATE KEY-----
In OpenSSL, this format is called "PEM" (as in -outform pem) and is used by default. The same format is used by OpenSSH, and you can use ssh -i joeuser.key to connect.
You can extract the public key in OpenSSH id_rsa.pub format (for putting into authorized_keys) with:
ssh-keygen -y -f joeuser.key > joeuser-ssh.pub
(The same public key in PEM format can be extracted with openssl rsa -pubout, but it will be of little use.)
If you have a DSA key, it should work exactly the same like RSA.
Is the uid >= 500? On RHEL/CentOS, the default PAM config has a check for uid. Another possibility could be the password is expired (if you set it as root using passwd <username>) - does a login rather than su to the user reveal any issues there? Does it work using Pubkey authentication rather than a password?
The reason is probably logged in authlog, and troubleshooting without that log data is really just speculation.
Best Answer
Nope, won't work. Best bet: reboot your (remote?) machine into recovery mode if this is possible and modify the configuration then. And an advice for the future: keep an existing shell open and try to re-login with your existing account in a new session before terminating (no offense meant).