Ticket #2772 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

We should ditch sshv1 etc.

Reported by: cjb Owned by: cscott
Priority: normal Milestone:
Component: distro Version:
Keywords: Cc: cscott, mstone, dgilmore
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description

Ivan,

We're still generating three ssh keys -- sshv1, dsa and rsa. Can we drop to one v2 key? Which do you suggest? (We should also make sure we aren't allowing v1 negotiation.)

Change History

follow-up: ↓ 2   Changed 7 years ago by krstic

Yeah, we can drop to a single RSA v2 key. Can you reassign to whoever gets to make the change in the build? (For production, we won't automatically generate any keys at all, I imagine.)

in reply to: ↑ 1   Changed 7 years ago by cjb

  • owner changed from krstic to J5

Replying to krstic:

Yeah, we can drop to a single RSA v2 key.

Great, reassigning to J5. We were wondering at the office whether there still any patent claims left on RSA.

(For production, we won't automatically generate any keys at all, I imagine.)

jg would like us to retain the ability to help out with remote debugging. cscott suggested that we could use the sugar owner.key by default, since that's an ssh key too.

  Changed 7 years ago by jg

  • owner changed from J5 to dgilmore
  • milestone changed from Untriaged to FutureFeatures

  Changed 6 years ago by cscott

  • cc cscott, mstone added

For first-boot startup time improvement we should generate just one key as well. See also trac #7134; we probably want to take the time to grab a frame from the camera and cat it to /dev/urandom as well, but only before we generate an SSH key (not on every boot).

Something like:

gst-launch v4l2src num-buffers=2 ! fdsink fd=1 > /dev/urandom

  Changed 6 years ago by cscott

  • blocking 5451 added

Tweaking sshd startup is important for improving first-boot time, as well.

When alternate OSes claim they can boot faster, they are using our first boot time to make us look as bad as possible.

  Changed 6 years ago by cscott

  • owner changed from dgilmore to cscott
  • status changed from new to assigned

Fixed in joyride, reverted when we moved to olpc3, needs to be re-fixed.

I believe the "extra randomness" part of the patch (trac #7134) is unnecessary now; olpcrd pulls some data from the Geode hardware RNG instead.

  Changed 6 years ago by cscott

  • cc dgilmore, dwmw2 added

Blocking on getting a newer mtd-utils into F9, and getting xs-dev updated to F9.

  Changed 6 years ago by mstone

What does xs-dev have to do with it? Is mock-on-teach insufficient?

  Changed 6 years ago by cscott

An updated mtd-utils package needs to be installed on "all machines on which builds are made". That's current xs-dev and pilgrim.

  Changed 6 years ago by cscott

Um, sorry, ignore the last three comments. They were meant for trac #5174.

For *this* bug, I re-fixed it in the latest joyride branch pilgrim commit, omitting the #7134 part as discussed above.

  Changed 6 years ago by cscott

  • cc dwmw2 removed

  Changed 6 years ago by gregorio

  • milestone FutureFeatures deleted

Milestone FutureFeatures deleted

  Changed 6 years ago by cscott

  • status changed from assigned to closed
  • next_action set to never set
  • resolution set to fixed

Yup, fixed, closing.

Note: See TracTickets for help on using tickets.