home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] how to set up "passwordless" ssh login?

  • Subject: Re: [OCLUG-Tech] how to set up "passwordless" ssh login?
  • From: Rob Echlin <rob [ at ] echlin [ dot ] ca>
  • Date: Wed, 20 Mar 2013 14:32:09 -0700 (PDT)
Hi Rob,
Yup. As you said elsewhere. No way around this without some r/w space.

Rob


 
--
Rob Echlin, B. Eng.
613-266-8311 -  Ottawa, ON
http://talksoftware.wordpress.com  - http://picasaweb.google.com/coderoller



>________________________________
> From: Robert P. J. Day <rpjday [ at ] crashcourse [ dot ] ca>
>To: Rob Echlin <rob [ at ] echlin [ dot ] ca> 
>Cc: Ottawa Linux Users Group <linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca> 
>Sent: Tuesday, March 19, 2013 6:16:48 PM
>Subject: Re: [OCLUG-Tech] how to set up "passwordless" ssh login?
> 
>On Tue, 19 Mar 2013, Rob Echlin wrote:
>
>> Sounds like you could put a public key on the target. Good enough.
>
>> Everyone can login to a special remote-supervisor account on some
>> server, to connect to the target, and that account has the private
>> key. Then you don't have to get keys from everyone in advance. With
>> a passwordless connection to the target, this would be an easy extra
>> step.
>>
>> You can add their keys to the server account when you need to, then
>> they have passwordless access to that account.
>
>  i'd thought of that a while back and it seemed initially promising
>but here's the rub as i explain something i'd carefully glossed over.
>
>  imagine the unit in question is, say, a pluggable USB device running
>linux. that pluggable device will be plugged into a much larger
>system, *also* running linux. so the final system will, in fact, be
>the *combination* of these things, and the larger system will be fully
>writable. ah, you think, perfect. that should solve the problem
>exactly the way you described it.
>
>  sadly, the two units will be manufactured entirely separately. the
>little units will be cheap pluggable devices which, on a moment's
>notice, might fail and will be immediately replaced by another one. so
>there's no permanence here. and there will be potentially *thousands*
>of these systems, which would require generating key pairs for each
>little unit, installing the public key on the unit, recording the
>private key somewhere, and installing that on the larger system when
>the combination of the two is placed in the field.
>
>  the logistics of keeping track of all these key pairs would be a
>nightmare.
>
>rday
>
>-- 
>
>========================================================================
>Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                        http://crashcourse.ca
>
>Twitter:                                      http://twitter.com/rpjday
>LinkedIn:                              http://ca.linkedin.com/in/rpjday
>========================================================================
>
>
>
>
>
>
>