UNIX for Beginners Questions & Answers

hello all
Happy New year
I have an issue here whenever I want to ssh into a particular server
I get this error message "Disconnected: NO supported authentication methoids available (server sent publickey)
I was trying to copy the public key to another server so that I do not need nto authenticate against a password and I think something got screwed up
I also ran this command sshd -d for debugging and the output is in this attachment
Please help

Hi,

Happy New Year to you too ! Firstly, your atetmpt to run sshd at the server-side in debugging mode failed because there was already an instance of sshd listening on port 22, so no new instance could start. To caputre debugging output you'd have to stop the SSH daemon on the server, then run the debugging instance manually again. That would then be able to bind to port 22 and capture debugging info for your incoming session, which might shed more light on things.

Regarding the actual error itself, it would seem to imply that as you suspect something has gone wrong with the key you're trying to use for authentication. Either the key you're using isn't in the authorized_keys file at the server side for the account you're attempting to log in to, or there's something wrong with its entry if it is. Alternatively, there could also be a problem with the permissions on the authorized_keys file, or with the .ssh directory or its parent.

But hopefully actually getting to capture the debugging data will help you figure out what exactly has gone wrong here. You can also get more debugging info from the client side too, by running your SSH command with the -v flag, e.g. ssh -v -v -v user@server.

Hope this helps.

Common problems include the files at both sides being world readable. SSH is designed to stop you thinking you are secure but actually credentials could be stolen or adjusted by anyone, e.g. if the authorized_keys can be written by anyone, then they could add their own public key and sign on as that account. If someone can read your private key, then they can access anything you can.

I'm probably over paranoid, but I change the directory ~/.ssh to be mode 700 and the files within to be mode 600. Obviously they must be owned by the correct user.



This might be a quick fix, but it might be totally wrong. Can you show use the output from an ssh -v user@server attempt?



Kind regards,
Robin

thanks
for all your reply
I discovered that my .ssh/authorized_keys is missing
I guess I have to start from scratch to create a public and private key

Hi,

Perhaps - or perhaps not. The authorized_keys file lives at the server end, not the client end. It's used to store your public key, which is generated along with your private key on the client side. So if your keys exist on the client side (typically stored as ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa for RSA keys, for example), then it's just a case of putting the contents of your id_rsa.pub in the .ssh/authorized_keys file underneath the home directory of the target account on the server, and that should be you (as long as the permissions of all the files are correct). But if you have no SSH keys at all on the client side, then yes, you'd need to re-generate everything from scratch.

I have regenerated the ssh key again but still having issues
it does not automatically create a authorized_keys file in the .ssh directory
but has created a id.rsa and id.rsa.pub on the server
What is the next stage

Hi,

Yes, that's right. The authorized_keys file resides at the server-side - that is, on the computer you want to SSH into. The id_rsa private key and associated id_rsa.pub public key reside on the client side - that is, the machine you're going to be SSH'ing from.

So, breaking it down step-by-step, the idea is:

So long as the permissions on all files are right, as has previously been discussed, then everything should work. SSH'ing with the key will of course only work for the one specific account that you've added the key to on the server, and not for any others. And likewise, it will only work from the account on the client to which the key belongs, and not any others.