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