After looking at this and reading a bit, I think I can fully explain what’s going on.
When the sshd server receives a connect request, it spawns off a new privileged process (i.e., as root), to process the authentication and to trade key pairs for the session.
If above works, and you are authenticated, then the server starts another process in parallel to the first one, this one is in user space and will be the one that handles the terminal session that you’ll be using.
When /etc/ssh/sshd_config contains the ~/.ssh/authorized_keys, it is expanded by step 1 to point into /root/..., which is what causes the failure. If you leave off the ~ prefix, then the server apparently uses the login area of the user as the prefix.
I hope to remember this the next time I see it, but the old grey matter never was much good at the remembering part (it still seems to be able to brute force things ok).
I realized you can actually see this, not that it helps with debugging, but it might clarify what happens when things work.
Once you’ve got a session running, just look at the process list and there they are: the server demon listening on 22, the privileged process and the user process hooked to the terminal session.
$ ps -ax | grep sshd
1059 ? Ss 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
972719 ? Ss 0:00 sshd: efahl [priv]
972842 ? S 0:00 sshd: efahl@pts/1
I’m seeing this thread late, so apologies if what I’m suggesting has already been tried.
On the server, the one you’re connecting to, tail and follow the appropriate log file. In the case of Ubuntu, off the top of my head the command would be:
sudo tail -f /var/log/auth.log
While that’s running, open a new terminal window on your client computer, the one you’re connecting from, add the -v option:
ssh -v user@host
Between the output of the client and the server, it should tell you exactly what the problem is. 9 out of ten times it’s permissions in my experience, other times it’s a setting on the server that’s preventing the client from connecting.
Thanks for responding, and thank you for the information that you have shared. The issue was already been addressed with the help of @efahl and @hulxmash
