This is definitely on the todo list. It's completely correct that users
should be able to manage their own keys.
On Wed, Mar 8, 2017 at 11:01 AM James Beedy wrote:
> I'm quickly finding myself maintaining users ssh keys. How do people feel
> about making ssh keys bound to the
I'm quickly finding myself maintaining users ssh keys. How do people feel
about making ssh keys bound to the user instead of the model? This way,
when a user is added to a model ssh access comes with the package.
Moreover, can we allow users to manage their own keys?
--
Juju-dev mailing list
The new functional-ssh-keys test is non-voting while it gathers a few
runs and awaits a branch landing.
<http://juju-ci.vapour.ws/job/functional-ssh-keys/>
The test was written as part of fixing lp:1555727 as we lacked
functional test coverage for the key management in juju, and wit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/12/13 19:33, John Arbash Meinel wrote:
> On 2013-12-17 10:20, John Arbash Meinel wrote:
>> ...
>>> This hints to me that Juju run is improperly design. We already
>>> have a way to inform all machines that we have work for them
>>> to do. Which
it".
To speak to tim's general points -- we cannot indeed assume that users have
ssh keys, or even that they are entirely au fait with what ssh keys are and
do. Allowing those users to negotiate a bootstrap without confronting that
topic is clearly a Good Thing, and we must be prepared to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-12-17 10:20, John Arbash Meinel wrote:
> ...
>> This hints to me that Juju run is improperly design. We already
>> have a way to inform all machines that we have work for them to
>> do. Which *doesn't* require us to ssh into them (the hook
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> This hints to me that Juju run is improperly design. We already
> have a way to inform all machines that we have work for them to
> do. Which *doesn't* require us to ssh into them (the hook
> triggers).
>
> Just create a "run" hook that fires a
On Tue, Dec 17, 2013 at 1:59 PM, John Arbash Meinel
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> ...
>
> > 5) Juju run. In order to make this available to the GUI, it needs
> > to be executed from the API server. This means that the API server
> > machine needs to be able to SSH t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> 5) Juju run. In order to make this available to the GUI, it needs
> to be executed from the API server. This means that the API server
> machine needs to be able to SSH to all the other machines. No one
> is going to want to upload their own pr
Hi all,
A while back Andrew raised the suggestion that we create a SSH key for
the purpose of monitoring the juju bootstrap. This has raised its head
again for several reasons:
1) Many windows users don't have ssh keys, nor even ssh installed. We
have a go ssh implementation that we can
that's valid in a
jenv seems to work in environments.yaml so far.
Another option is to auto-generate the credentials, but stick them in
the control-bucket. That way, they can be used automatically by
anyone with access to the bucket, and no one has to worry about
getting SSH keys to their team
>> Though if we actually start getting into that, then whether you're
>> using OpenSSH or SunSSH or Putty or any of a number of SSH
>> implementations starts to complicate things.
>>
>
> If we were to auto-generate, I think they would go into either ~/.juju or
tart getting into that, then whether you're
> using OpenSSH or SunSSH or Putty or any of a number of SSH
> implementations starts to complicate things.
>
If we were to auto-generate, I think they would go into either ~/.juju or
the .jenv file.
We already make assumptions about how thin
write the ssh private key
into the .jenv and pull it out to hand off to the SSH subprocess.
Though if we actually start getting into that, then whether you're
using OpenSSH or SunSSH or Putty or any of a number of SSH
implementations starts to complicate things.
So *if* you don't configur
So, synchronous bootstrap broke CI. The reason for this is that we're now
using SSH as part of the process; I can see in the CI logs that a
non-default identity file is being used with "juju scp". That explains why
"juju ssh" (during bootstrap) is failing -- it just tries the default keys.
To work
15 matches
Mail list logo