Re: public key not making it into authorized_keys

[CK(1)]

It doesn't appear to be key length (2048 bit RSA doesn't make it into authorized_keys either).

On Wednesday, July 22, 2015 at 6:32:55 PM UTC-4, CK(1) wrote:

I tried spinning up a single host using the "OnePC-Ubuntu14" profile.  Shell access works fine. So does sudo.

I was unable to access the device via SSH and I peeked at ~/.ssh/authorized_keys and my public key isn't listed there (ditto for root).

Next I tried managing my SSH keys and I do see it listed ... then did a reboot/reload of the node ... nada. Still no public key in authorized_keys.

Are there restrictions on types of keys which may be used (this one is 4096 bit RSA)?

It also doesn't seem to let me in when using Console (using either my userid or root). Manpages in the shell say that alpha num and punctuation is allowed (so not sure what's unhappy).

I seem to be striking out at my first time at bat!  :(     Suggestions welcome ... thanks!!

Chris

[CK(1)]

I found a workaround ... I had to run "sudo passwd username" from the Shell (which allowed me to use the special-characters that seemed to be causing problems).

Both Console and SSH access seems to be working ... and for some reason the public key has now been slurped down into authorized_keys.

Chris

[Leigh Stoller]

> It also doesn't seem to let me in when using Console (using either my
> userid or root). Manpages in the shell say that alpha num and punctuation
> is allowed (so not sure what's unhappy).

This is by design; we do not put user passwords on the nodes, only ssh
keys. This is cause many people (present company excluded of course) use
terrible passwords, and we have bitten too many times by nodes being broken
into via trivial passwords.

The console window allows you to login as root, which is why we provide the
root password we generate at the top of the console window. If this did not
work, it is very unusual.

You are welcome to set a password for yourself, but note that it will be
removed when the node reboots.

Later ...

> Both Console and SSH access seems to be working ... and for some reason
> the public key has now been slurped down into authorized_keys.

This is unusual, it would seem to indicate that you were trying to log in
before the node was actually ready. Was the node green in the topology
window? More details would be helpful, since it seems like we have a bug
that needs to be fixed.

Thanks!
Leigh

[CK(1)]

Ah ... evidently this is a "failing eyesight or neurons with advancing age" problem on my part. I completely missed the little "password" link above the Console tab. It's also mentioned in one of the bullets on p.64 of the PDF manual too. Sorry!

 

I did figure out what was happening with authorized_keys. If the SSH keys are updated/changed after an experiment has been provisioned, subsequent reloads/reboots do NOT seem to pull in updated keys.  But if I Terminate the experiment and start another ... that initialization appears to slurp down the new-improved keys.  Docs made it sound like reloads/reboots would also refresh authorized_keys ... but it wasn't happening.  Perhaps there is some script which can be invoked to refresh authorized_keys on systems already running?

 

Thanks!!

 

Chris

[Robert Ricci]

> On Jul 23, 2015, at 10:05 AM, CK(1) <cko...@g.clemson.edu> wrote:
> I did figure out what was happening with authorized_keys. If the SSH keys are updated/changed after an experiment has been provisioned, subsequent reloads/reboots do NOT seem to pull in updated keys. But if I Terminate the experiment and start another ... that initialization appears to slurp down the new-improved keys. Docs made it sound like reloads/reboots would also refresh authorized_keys ... but it wasn't happening. Perhaps there is some script which can be invoked to refresh authorized_keys on systems already running?

Ah, yes, I can certainly understand this confusion. Just a quick explanation of how this works, in case that helps explain the behavior: when the experiment is created, we pass all of your public keys known to the portal at that time to the control nodes at any/all of the specific clusters involved. So it’s true that every time a node boot, it fetches a new list of public keys from the local controller from its cluster, but that’s just the list that was given to the controller at the time you started the experiment.

So, doing what you suggest would in fact be possible, and a good idea, but it will need to go the other way: a push from the portal that updates the keys at the local controllers, followed by re-fetch by the nodes themselves. We don’t have all these pieces right now, but I can put them on our TODO list.

[Christopher A Konger]

Thanks Rob ... that makes tons of sense. :) CK(1)