Failed to import ssh key
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| subiquity |
High
|
Unassigned |
Bug Description
Image from Apr 25th, 2018. There is no build id in /etc/cloud, not sure how to better identify it.
I gave the installer my launchpad id ("ahasenack") for the ssh key import.
At the end, there was no /home/andreas/.ssh directory, and the logs confirmed that the import failed for some reason:
2018-04-25 20:47:38,799 - cc_ssh_
2018-04-25 20:47:38,799 - util.py[DEBUG]: Running command ['sudo', '-Hu', 'andreas', 'ssh-import-id', 'lp:ahasenack'] with allowed return codes [0] (shell=False, capture=False)
2018-04-25 20:47:39,036 - util.py[WARNING]: Failed to run command to import andreas ssh ids
2018-04-25 20:47:39,036 - util.py[DEBUG]: Failed to run command to import andreas ssh ids
Traceback (most recent call last):
File "/usr/lib/
util.subp(cmd, capture=False)
File "/usr/lib/
cmd=args)
cloudinit.
Command: ['sudo', '-Hu', 'andreas', 'ssh-import-id', 'lp:ahasenack']
Exit code: 1
Reason: -
Stdout: -
Stderr: -
2018-04-25 20:47:39,040 - util.py[WARNING]: ssh-import-id failed for: andreas ['lp:ahasenack']
2018-04-25 20:47:39,040 - util.py[DEBUG]: ssh-import-id failed for: andreas ['lp:ahasenack']
Traceback (most recent call last):
File "/usr/lib/
import_
File "/usr/lib/
raise exc
File "/usr/lib/
util.subp(cmd, capture=False)
File "/usr/lib/
cmd=args)
cloudinit.
Command: ['sudo', '-Hu', 'andreas', 'ssh-import-id', 'lp:ahasenack']
Exit code: 1
Reason: -
Stdout: -
Stderr: -
And later again:
2018-04-25 20:47:39,041 - handlers.py[DEBUG]: finish: modules-
2018-04-25 20:47:39,041 - util.py[WARNING]: Running module ssh-import-id (<module 'cloudinit.
2018-04-25 20:47:39,041 - util.py[DEBUG]: Running module ssh-import-id (<module 'cloudinit.
Traceback (most recent call last):
File "/usr/lib/
freq=freq)
File "/usr/lib/
return self._runners.
File "/usr/lib/
results = functor(*args)
File "/usr/lib/
raise elist[0]
File "/usr/lib/
import_
File "/usr/lib/
raise exc
File "/usr/lib/
util.subp(cmd, capture=False)
File "/usr/lib/
cmd=args)
cloudinit.
Command: ['sudo', '-Hu', 'andreas', 'ssh-import-id', 'lp:ahasenack']
Exit code: 1
Reason: -
Stdout: -
Stderr: -
Andreas Hasenack (ahasenack) wrote : | #1 |
Andreas Hasenack (ahasenack) wrote : | #2 |
Andreas Hasenack (ahasenack) wrote : | #3 |
Andreas Hasenack (ahasenack) wrote : | #4 |
Ubuntu QA Website (ubuntuqa) wrote : | #5 |
This bug has been reported on the Ubuntu ISO testing tracker.
A list of all reports related to this bug can be found here:
http://
tags: | added: iso-testing |
Michael Hudson-Doyle (mwhudson) wrote : | #6 |
Was this the same system that you reported bug 1766286 about? Because the lack of proxy config could explain this.
In any case, the real fix for this is for subiquity to fetch the keys and shove the key material into the cloud init config rather than telling cloud-init to import the keys.
On Wed, Apr 25, 2018, 19:01 Michael Hudson-Doyle <email address hidden>
wrote:
> Was this the same system that you reported bug 1766286 about? Because
> the lack of proxy config could explain this.
>
Same system, yes, but the proxy is not mandatory in this network. There is
unrestricted egress access. The proxy is there for caching purposes.
In any case, the real fix for this is for subiquity to fetch the keys
> and shove the key material into the cloud init config rather than
> telling cloud-init to import the keys.
>
It's a cloud-init bug then?
Michael Hudson-Doyle (mwhudson) wrote : | #8 |
On 26 April 2018 at 10:41, Andreas Hasenack <email address hidden> wrote:
> On Wed, Apr 25, 2018, 19:01 Michael Hudson-Doyle <email address hidden>
> wrote:
>
> > Was this the same system that you reported bug 1766286 about? Because
> > the lack of proxy config could explain this.
> >
>
> Same system, yes, but the proxy is not mandatory in this network. There is
> unrestricted egress access. The proxy is there for caching purposes.
Ah OK.
In any case, the real fix for this is for subiquity to fetch the keys
> > and shove the key material into the cloud init config rather than
> > telling cloud-init to import the keys.
> >
>
> It's a cloud-init bug then?
I have no idea, the logs are very unhelpful :( but I guess that would be my
guess.
Cheers,
mwh
Ryan Harper (raharper) wrote : | #9 |
I'm pretty sure this is because networking was not up yet:
i-info: +++++++
ci-info: +------
ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
ci-info: +------
ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
ci-info: | lo | True | ::1/128 | . | host | . |
ci-info: +------
That should have your nic.
I noticed in a previous install of subiquity, that it keeps the 'optional' flag on in the netplan configuration, which is fine for subiquity environment, but user environment should not use the optional flag.
Can you collect /etc/netplan/
Changed in subiquity: | |
importance: | Undecided → High |
status: | New → Incomplete |
Andreas Hasenack (ahasenack) wrote : | #10 |
Here is my netplan config file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
ethernets:
enp0s25:
dhcp4: true
version: 2
Ryan Harper (raharper) wrote : | #11 |
Yes, subiquity shouldn't mark the interface optional.
That means that network-online won't wait for the network to be up, and cloud-config/
Changed in subiquity: | |
status: | Incomplete → Triaged |
Andreas Hasenack (ahasenack) wrote : | #12 |
Does this have any implication on packages I install afterwards on this
server and that depend on the network-online target?
On Thu, Apr 26, 2018, 12:26 Ryan Harper <email address hidden> wrote:
> Yes, subiquity shouldn't mark the interface optional.
>
> That means that network-online won't wait for the network to be up, and
> cloud-config/
> operations do use networking.
>
>
> ** Changed in: subiquity
> Status: Incomplete => Triaged
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Failed to import ssh key
>
> To manage notifications about this bug go to:
> https:/
>
Steve Langasek (vorlon) wrote : | #13 |
> That means that network-online won't wait for the network to be up,
> and cloud-config/
> operations do use networking.
That is not the agreed meaning of network-online. network-online should only be true if at least one interface, and a default route, and DNS, are available; and only after all non-optional interfaces are up or timed out. In the case where you only have one interface at install time, 'optional' should make no difference (and if it does, that needs to be fixed elsewhere still). In the case where you have more than one interface, there's a design question of whether we should default to waiting for all interfaces to be up.
So I'm ok with us changing subiquity to make the interfaces not-optional on install as that seems to be the more robust solution.
Ryan Harper (raharper) wrote : | #14 |
On Thu, Apr 26, 2018 at 12:40 PM, Steve Langasek
<email address hidden> wrote:
>> That means that network-online won't wait for the network to be up,
>> and cloud-config/
>> operations do use networking.
>
> That is not the agreed meaning of network-online. network-online should
> only be true if at least one interface, and a default route, and DNS,
> are available; and only after all non-optional interfaces are up or
> timed out. In the case where you only have one interface at install
> time, 'optional' should make no difference (and if it does, that needs
> to be fixed elsewhere still).
Are you suggesting that for a system with only one interface and that
it's marked optional networkd-
> In the case where you have more than one interface, there's a design
> question of whether we should default to waiting for all interfaces to be up.
I'm certainly not asking for all interfaces to be up; We're in
violent agreement that at least *one* should be up.
In this bug, there was only one, *and* it was marked optional.
>
> So I'm ok with us changing subiquity to make the interfaces not-optional
> on install as that seems to be the more robust solution.
I think whatever the user accepts or configures should NOT include optional.
That's sufficient to resolve this bug.
If there are additional nics that don't get configured in subiquity ui, those
could either stay unconfigured, or marked optional. We may want to include
them as optional in the config to communicate that the installer saw the
interfaces but the user chose not to configure it.
That's likely out of scope for this bug, but worth discussing long term.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Failed to import ssh key
>
> To manage notifications about this bug go to:
> https:/
Michael Hudson-Doyle (mwhudson) wrote : | #15 |
So the optional: true stuff is fixed in dailies but the bug as reported is also "superfixed" because the SSH key is fetched in the installer rather than on first boot now.
Changed in subiquity: | |
status: | Triaged → Fix Released |
Changed in subiquity: | |
assignee: | nobody → Ngo Quang Thong (quangthong1981) |
Changed in subiquity: | |
assignee: | Ngo Quang Thong (quangthong1981) → nobody |
In another attempt, I tried a github key, but it also failed.