Hi Rob, 1) I believe that the location where the SSH server looks for keys can be configured in /etc in its config fiile. Is that on a read-only location, too?
2) Given what you do every day, I think there is some possibility that you are going to burn the file system on the remote system yourself. <g> If that is the case, create the .ssh folder with 1 or more public keys in it before you burn it. Copy the private key to whatever system(s) you are working from. Don't use the passwordless option for your private key. <g> Probably don't try this with a production system, but test systems would be fine. Captain Obvious strikes again!! <g> >________________________________ > From: Robert P. J. Day <rpj...@crashcourse.ca> >To: Ottawa Linux Users Group <linux@lists.oclug.on.ca> >Sent: Tuesday, March 19, 2013 4:43:21 PM >Subject: [OCLUG-Tech] how to set up "passwordless" ssh login? > > > before i start digging through the docs for something subtle that i >missed, i want to make sure i understand the recipe for setting up >passwordless ssh login, and what it *requires* to be possible on both >ends. (i think i already know the answer to this, i just want to be >absolutely sure.) > > so, i'm on system A, and i know an account and its password on >system B -- that part is kind of essential to start with. with that >alone, i can of course: > > $ ssh nameb@systemb > >but i will be prompted for the password -- ssh is very particular >about that. so far, so good, right? > > now i want to extend this so i don't have to type in the password >every time. AFAIK, this involves being able to do the following: > >1) on system A, i need to run "ssh-keygen" to generate my own pair of >keys > >2) i need to then run "ssh-copy-id" to copy my *public* key to the >remote system, into the home directory of the target account -- >specifically, into ~/.ssh/authorized_keys > > again, all of this is pretty standard but here's where i run into >trouble. turns out that the target system is a small embedded linux >system where there is only one account -- root -- which has its home >directory in a read-only filesystem. as best i know, i'm pretty well >screwed here, right? > > for the above to work, the home directory of the target account >*must* be writable in order for me to stash my public key in >~/.ssh/authorized_keys, correct? if even the remote account can't >write into its own home directory, i don't see how to get around that. >thoughts? > > a couple other questions while i'm here. again, i think this is >pretty obvious but if a whole bunch of different accounts want to >passwordless ssh into the same remote account, each one of them has to >run the recipe above, yes? so the remote account better be prepared to >stash a lot of public keys in .ssh. > > finally, if i'm unable to change the configuration of the remote >system, the only option i see that's completely client side-based is >"sshpass": > > http://linux.die.net/man/1/sshpass > >am i missing anything? given the read-only nature of the target >system, i don't see any easy workaround. > >rday > >-- > >======================================================================== >Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > >Twitter: http://twitter.com/rpjday >LinkedIn: http://ca.linkedin.com/in/rpjday >======================================================================== >_______________________________________________ >Linux mailing list >Linux@lists.oclug.on.ca >http://oclug.on.ca/mailman/listinfo/linux > > > _______________________________________________ Linux mailing list Linux@lists.oclug.on.ca http://oclug.on.ca/mailman/listinfo/linux
