well, that indeed is problematic, as there's no way to limit access to listening sockets based on the user. if bob can connect to the machine, he will be able to connect to the localhost-bound socket as well.
for this you can indeed use some sort of clear-text password authentication... there's no need, however, to set up an encrypted channel again, as it's performed over the ssh tunnel (or over the localhost, in case bob tries to connect to the socket). either way, assuming bob != root, it's safe. you may even use rpycuser's own password for that (e.g., authenticate it with the linux login) ----------------------------------------------------------------- *Tomer Filiba* tomerfiliba.com <http://www.facebook.com/tomerfiliba> <http://il.linkedin.com/in/tomerfiliba> On Thu, Jun 14, 2012 at 10:11 PM, Eduard Thamm <[email protected]>wrote: > Ok. > But assume this rpycService is running on machine A localhost:16000 under > rpycuser, how would that prevent bob who has ssh access to A from > connecting to the service. > > > > 2012/6/12 Tomer Filiba <[email protected]> > >> $ ssh-keygen -f mykey_rsa >> and then add the public key part (mykey_rsa.pub) to the host >> machine's authorized_keys, under the user you want to connect as. >> for example, if you have a user called rpycuser, go to >> /home/rpycuser/.ssh/authorized_keys and add the generated pubkey. >> then, in the ssh context, pass mykey_rsa as the identity file, and user = >> "rpycuser". >> >> >> ----------------------------------------------------------------- >> >> *Tomer Filiba* >> tomerfiliba.com <http://www.facebook.com/tomerfiliba> >> <http://il.linkedin.com/in/tomerfiliba> >> >> >> >> On Sun, Jun 10, 2012 at 8:37 PM, Eduard <[email protected]> wrote: >> >>> and you can always just create a distinct id file for the sake of your >>>> service, so not anyway who can access your machine >>>> could access the service. >>>> >>> Out of curiosity. How would one do that? >>> >> >> >
