Trying public/private authentication on SSH

Uff… then I forgot to mention yet something else (WTF with me…). The CentOS is text mode only, no GNOME, KDE, X, or any desktop environment. I thought that was a bit obvious since CentOS is Red Hat’s free counterpart and it’s normally used for servers, and servers are normally used in text mode. That’s what I was taught at least.

The CentOS box has already 700 permission on ~/.ssh, and the created ~/keys directory used for generated keys in different location has 777 permission. Ssh-keygen already generates keys with permission 600, so all should be ok… But ALL the tests in report were done without using ssh-agent or ssh-add at all, at least yet, so I would like to think keys in another location probably didn’t work due to this. Even seahorse in openSUSE box who claims to know everything about ~/.ssh location didn’t recognize keys created in a different location.

Nrickert, so a similar thing you explained would also be happening to passphrase protected keys?
Why passphrase-less keys change to a more weird behavior when turning off sshd in openSUSE box?

That 777 permission is likely the problem. Change it to 644 or 755. That is, don’t allow write by other than the owner. And make sure that the directory owner is either you or root. Then those keys will probably start working.

Not with those 777 directory permissions.

Suppose I have access to your box. Then I can find your uid. Then I can create a key on my own computer, owned by your uid. And then I can copy it to that “777” directory. That would allow me to trick you. And “openssh” tries to detect those kinds of problems.

Yes, I had assume that the CentOS system was text mode only.

“Openssh” is probably fussier about permissions for keys without a passphrase.

However, as I said explicity this time, that happens on openSUSE box. On it behavior with passphrase protected keys is the same described either with sshd on or off. With passphrase-less keys behavior differs with sshd on and off. You already explained something about seahorse regarding passphrase-less key with sshd on.
But what about passphrase-less key with sshd off? And what about passphrase protected keys? How could openssh be different on openSUSE than on CentOS? Wouldn’t it make a bit more sense if it was seahorse’s doing?

I reiterate that, on CentOS box all tests were successful as you can see (or read again) except for the key in different location test, to which you’ve already suggested changing the 777 permission.

Beforehand, I’m sorry for being bothering you about the same thing, but since in the real life practical application I’ll probably need to access a remote server from my openSUSE box I need to know what will I do…

Whether “sshd” is running should not affect anything. The only “sshd” that matters, is the one running on the system that you connect to. And if that isn’t running, you won’t be able to connect.

There should not be any other effect of “sshd” running.

I’m limited to the information you have provided, and it doesn’t all quite fit together, so I might me misreading some of it. It isn’t always possible to determine what is happening with limited information.

Here’s a point I omitted about connecting from your CentOS box. Since that is command line only, and since you are not running “ssh-agent” there, you can only use keys that the “ssh” command sees. By default, it only looks for “id_rsa”, “id_dsa” and perhaps “id_ecdsa” in your “.ssh” directory. If you want to use a key elsewhere or with a different name, you will need to use

ssh -i "/path/to/key/file" hostname

to tell it which key to use. This is documented with “man ssh”.

When you use a key on CentOS, the keyfile is seen only by the “ssh” command.
When you use a key under Gnome, the keyfile is seen only by “seahorse”.

These programs might have different requirements on file permissions for key files. And they might have other different permissions depending on whether there is a passphrase.

I’m not sure what else you are looking for at this stage. Perhaps provide a very specific question.

Then tell me what information you need exactly. Or are you saying it makes no sense that I’m getting different reactions with passphrase-less keys with sshd turned on and off on openSUSE box? With passphrase protected keys I do get same reactions, which would seem indeed logical/expected…

On 11/29/2013 01:46 PM, F style wrote:
>> I’m not sure what else you are looking for at this stage. Perhaps
>> provide a very specific question.
> Then tell me what information you need exactly. Or are you saying it
> makes no sense that I’m getting different reactions with passphrase-less
> keys with sshd turned on and off on openSUSE box? With passphrase
> protected keys I do get same reactions, which would seem indeed
> logical/expected…

It makes no sense at all for the client-side sshd process to affect SSH
sessions; sshd is a server-side application, so it will not affect the
client on the same system unless the system is both running the client and
server. In that case, though, sshd being off would prevent a connection,
as is the case anytime the server-side service of any kind if stopped.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

I’ve probably lost track of the question.

Somewhere above, when talking about passphrase-less keys, you say:

2b–Moving public key to another location, passphrase is not requested at all, but by putting it back passphrase neither is requested not any more.

Why are you telling me that the passphrase is not requested, when there is no passphrase? And what did you mean by that “is requested not any more”?

I just a bit confused about what you are describing and what you want explained.

Yes, I’m either confusing you and myself indeed… I’ll try building my uneasiness…

First, we’ve said that turning on/off sshd on openSUSE box should not affect loggin in from it to CentOS box, which indeed applies for passphrase protected keys.

Then come the tests on openSUSE box with passphrase-less keys, where seemingly sshd turning on/off is affecting for some reason and I don’t know why.

The case with sshd turned on has already been explained by you here.

So I would expect the same with sshd turned off, but this is what actually happens:
a.- Key is not working by default, I get “Agent admitted failure to sign using the key” and forced to log in with normal username and password on each log in attempt.
b.- If I move public key file away, the key now actually works, I log in freely. If I put back public key file key stills working, but the thing is I would expect getting again the Agent failure issue, unless what you said in your post is happening again.
c.- If I move private key file away, I get exactly point a). Yes, I get to log in with username and password, but again that Agent failure error each time!?
d.- If I move both key files away I get to log in with username and password without agent failure error, finally as expected. But when putting them back I log in freely again. Another seahorse doing?

So in summary,

  1. What happens with passphrase protected keys, is it the same as you explained here?
  2. As you can see, passphrase-less keys are not working the same as when sshd is on. If I have to tell in general terms, I hate that Agent failure issue. What’s happening here?

I admit to never coming across that message.

To me, it suggests that the public and private key files are not a matched pair. That is, something might be broken about that public key file.

That it still works after working once, is not surprising. The agent (“seahorse”) probably only checks when loading the private key the first time. So, after that, it won’t notice a problem with the public key file.

Did some more tests.

On openSUSE box
First, summarizing. Repeated tests just to be sure and I confirm that passphrase-less keys on openSUSE box don’t work the same with sshd on and off. With sshd on log in actually works but with the seahorse flaw you already explained. With sshd off it actually doesn’t work, default I get “Agent admitted failure to sign using the key” and key is ignored, then the rest I described.

Then I tried generating keys in another location, let’s say ~/keys. This directory was created with 755 permissions already, so it should be ok. Added the key to CentOS box with -i option. Tried loggin in to CentOS box with “ssh centosuser@ip_adress” but still no avail, still key ignored. So with that command system is really looking in ~/.ssh. So I tried “ssh -i (key_file) centosuser@ip_adress” and this time it worked. And not only worked, it worked all correctly, both with passphrase and passphrase-less keys! Just like the first CentOS box tests. So there must be something else in ~/.ssh directory in openSUSE box, either from Openssh or Seahorse.

It even worked with ssh-agent. I added key with -i option of ssh-add and I logged in freely even with passphrased keys. Only detail was, ssh-add worked out of the box without having to initialize with “ssh-agent /bin/bash”.

On CentOS box
But problems came here. Created ~/keys directory with 755 permissions, generated keys inside this folder, added public key to openSUSE box with ssh-copy-id’s option -i. Tried loggin in with “ssh -i (key_file) susesuser@ip_adress”, and I was asked for the key’s passphrase, but it didn’t accept it! I ran out my 3 log in attempts before loggin in with username and password. And even by using a passphrase-less key, I was still asked for a passphrase! No sense!
Permissions of both key files in CentOS box are 600, and permissions on openSUSE box are, for ~/.ssh folder 700, and for ~/.ssh/authorized_keys 600.
Though log ins still work normally if I use default keys in ~/.ssh folder…

Now I’m really desperate. Please help!

I have never run into this. So I did the obvious. I put “Agent admitted failure to sign using the key” into a google search (including the quotes). And that got a bunch of hits. The suggestion seems to be to use “ssh-add” to force adding this key.

Another suggestion was to logout, and log back in. That clears remembered keys. Is it possible you did that when starting “sshd”, and maybe it was that logout/login rather then the “sshd” that made the difference?

In any case, I suggest you repeat that google search and read a few of the pages google links to.

This is all pretty much as expected. “Seahorse” (under gnome) will recognize all keys in “.ssh”, and the “ssh” command can recognize keys is “.ssh” if they have the special names “id_rsa”, etc. Keys elsewhere have to be referenced with “-i” on the “ssh” command, or with “ssh-add”.

This one, I don’t understand at all. My text mode tests work with “ssh -i keyfile”. I have not tried with a passwordless key.

Ouch, I made a GREAT mistake with that last CentOS box test. I seemingly made everything messed up. When trying to log in with -i parameter I was specifying the public key file, no the identity one. WTF… That’s why it wasn’t working. When using default ~/.ssh keys system automatically tries to log in with identity, obviously.

Thank you Ab and Nrickert for enduring me the entire post. Guess the conclusions are:

–A remote server identifies the log in attempt from a local client by the private key file’s full location path. If it’s moved/renamed/deleted, goodbye key.
–When trying to log in from openSUSE box with GNOME to some remote server, do it without Seahorse (or KDE style, whatever you want to call it): not to use default ~/.ssh directory and always using -i parameter, unless of course using ssh-agent. Seahorse or OpenSSH with GNOME stink.
–This would be more of a last doubt. On CentOS box I had to indeed initialize agent with “ssh-agent /bin/bash” to make ssh-add to work. However this was not needed in openSUSE box. In this last one ssh-add worked out of the box. Why?

Again, thank you all (don’t forget last doubt, I’m still curious…).

Strictly speaking, the remote server does not know the name of the key file. However, it does require that a particular transaction be signed by the private key.

If you did a command line login to opensuse, you would need to start “ssh-agent”.

With a graphic login, the agent is automatically started with the desktop startup. I’m not sure, but I think it checks whether you have a “.ssh” directory, and if you do its starts the agent.

It’s done that way, so that the connection with the agent will be inherited by all processes that you start from your desktop.