Solved Passwordless ssh asks for password

Maybe cause I just woke up but I created a public key using ssh-keygen -t rsa and copied that key to my server at .ssh/authorized_keys but when I do ssh -p 5555 me@example.com I still get asked for my password. Now, I just did this last Friday on a work machine without issue so I don't know what I'm doing wrong now.

Looking at the private key, I noticed that, at the end of the string, it starts to show an email address without the hostname: drhowarddrfine@ I don't know if that's the issue or not. Interestingly, an old private key I have (not sure I ever used it) says drhowarddrfine@drhowarddrfine. So I'm confused and not awake yet.

All the permissions are correct. 700 for .ssh and 600 for authorized_keys all set to drhowarddrfine:wheel though I guess I should take wheel off that.
 
The last column is just comments, so it doesn't matter what it says. One thing that bit me more than once, make sure the key is all on one line. This may not be obvious when vi(1) uses the same width as the text.
 
No, that's the key type and is mandatory. Try connecting with ssh -vv and see if that provides any clues.
 
Here's the relevant part of ssh -vv, I think, with some things x'ed out:

Code:
Server host key: ecdsa-sha2-nistp256 SHA256:rg5ma7iGrSfnYL2/JzYy/i+aI7lKvwvd2KVU7Bb
debug1: Host '[xxx.com]:50222' is known and matches the ECDSA host key.
debug1: Found key in /home/xxxx/.ssh/known_hosts:4
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/xxxx/.ssh/id_rsa (0x60006b5e0),
debug2: key: /home/xxxx/.ssh/id_dsa (0x0),
debug2: key: /home/xxxx/.ssh/id_ecdsa (0x0),
debug2: key: /home/xxxx/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/xxxx/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/xxxx/.ssh/id_dsa
debug1: Trying private key: /home/xxxx/.ssh/id_ecdsa
debug1: Trying private key: /home/xxxx/.ssh/id_ed25519
debug2: we did not send a packet, disable method

I don't recall if I set anything in sshd_config when I set this server up but I have a meeting to go to.

EDIT: The only thing I changed there was the port number and disallowing root login.

Yes, this is a FreeBSD box on both ends.
 
You don't need to edit sshd_config to disallow root login. It is disabled by default. Your best option now is to generate again your keys and make sure that there are no line breaks in authorized_keys.

Looking at the private key, I noticed that, at the end of the string, it starts to show an email address without the hostname: drhowarddrfine@ I don't know if that's the issue or not. Interestingly, an old private key I have (not sure I ever used it) says drhowarddrfine@drhowarddrfine. So I'm confused and not awake yet.
That is wrong. The private key is id.rsa and it should be in the form of:
Code:
-----BEGIN RSA PRIVATE KEY-----
......
......
-----END RSA PRIVATE KEY-----
The public key is id.rsa.pub and it looks like the one you describe.
 
So this company runs an Ubuntu VPS server on DigitalOcean so I set that up in the same way and I'm able to get into that box, without a password, using cygwin on Windows and FreeBSD10.1 running in VirtualBox. So obviously there's something goofy on my server and I don't know what else to do.
 
One easy thing to miss is to make sure .ssh folder is chmod 700 and the authorized_keys file is chmod 600

Otherwise it would not use these files and you still get prompted for password.

I have missed this when I was is a rush.

Additionally you can check that the folder is recursively owned by the owner of the home directory where it lives.
 
Any chance you have some special setting in your ssh client's .ssh/config file that may be interfering.

Have you tried from more that one client.

Have you verified the key is loaded with ssh-add, etc.

Is ssh-add successful?

ssh-add && echo "worked" || echo "failed"
 
Yes, the key is there. The only thing I see in /var/log/auth.log is this:

Code:
Authentication refused: bad ownership or modes for directory /usr/home/xxxx

I Googled for a possible answer but I think the issue shows up more in ssh -vv but I don't know what it means. Unfortunately, I didn't get to work on this from home and don't have a copy of it. I'll get it tomorrow.

Yes, as I said earlier, I do have permissions set correctly.
 
It's complaining about the permissions on the user's home directory, not the ~/.ssh directory.
 
Yes but I've set permissions there to 777 and still get the error. I think I'll try it again cause my memory on that is shady. Right now I have it set to 770.
 
Also check the ownership of the user's home directory, it should be owned by the user.
 
It is.

EDIT: Oh crap. I think I see one problem. It might be the username is wrong in one case but not the other but I can't check that for a while.

EDIT2: That was the problem. I misspelled the one username but that doesn't explain why I can't get this to work from home. I would bet I was getting my attempt to login from home mixed up with my work login and just getting myself turned around. I'll find out tonight.

EDIT3: And just like that, it quit working. I am so confused.
 
EDIT3: And just like that, it quit working. I am so confused.
Happens to me all the time. Must be an age thing ;)

Anyway. Just take a step back and start fresh, test one thing at a time and take logical steps. You'll figure it out eventually. Make sure you can login without a key, using a password. Check you're using the correct username, if the home directory is correct, etc. Then move on to adding the key.
 
Well, it's official. I've gone insane. I need a good home to be put into.

I mentioned earlier that I had permissions on the home directory set to 770 but you need at least 754 on that for this to work. And now all is well. For the moment. I guess. I feel such shame.
 
Back
Top