Hi Brian,<br><br>The keys certainly have _some_ concept of location embedded, but not user. I see now what you mean as of having no concept of user at recipient. <br><br>I went from within the account of <a href="mailto:jim@sender.com">jim@sender.com</a> with the key generated <br>
<br>"ssh-rsa [long hash] jim@MACHINENAME" user@machine (since none of my machines have the FQDN as their domain name, they all go by simple machine-names) is definitely in the public key itself<br><br>Here is my secret plan - still follows the point of the original thread - I put this key into the space for it in the FreeNAS users "dino" and "webby" (/dino/.ssh/authorized_keys and same with the other). I am testing to put my backups in safer locations as Jim Kinney suggested a few posts above. <br>
so now I can log in without a password from the account of <a href="mailto:jim@sender.com">jim@sender.com</a> - when I try to log in to the dino account from some other account on <a href="http://sender.com">sender.com</a> or from <a href="http://sender2.com">sender2.com</a> I get a password dialog again. <br>
<br>I went to the account of <a href="mailto:jimbo@sender2.com">jimbo@sender2.com</a> and tried to log into <a href="mailto:dino@recipient.com">dino@recipient.com</a> and was met with a password dialog, so apparently it is important to be on the same machine. <br>
<br>So I did a keygen at the new machine, where my login name is jimbo. Logged in with a password to <a href="mailto:root@recipient.com">root@recipient.com</a> and went to dino's authorized keys and added this one into the authorized keys there. Now I can log in to dino@recipient without a password from that account as well. That key has the embedded username jimbo@machinename2.<br>
<br>So I sudo -i to <a href="mailto:root@sender2.com">root@sender2.com</a> and attempt the same thing. I must kegen and append ity to dino's authorized keys to login without a password as root@machinename2, <br><br>Finally, I am beginning to understand it all. Thanks for the help<br>
<br>So, if I wanted (for some reason) a single user's directory on <a href="http://recipient.com">recipient.com</a> that all users on all machines could access, I would need all users to do an ssh-keygen on their machine and send me their id_rsa.pub and append that to the single user's (dino in this case) authorized keys. And further, even if I make the username at <a href="http://recipient.com">recipient.com</a> known, nobody can log in there without a password without being able to append their ssh-key to the account's authorized_keys, which makes this pretty secure, since you would need password access to the account to do that.<br>
<br>Now I can clock out and go home.<br>I think I am going to write up a how-to about this. Then I can just go back and read that instead of bothering you on a Friday afternoon.<br><br>Wolf<br><br>PS Thanks again!<br><br>
<div class="gmail_quote">On Fri, Jan 27, 2012 at 5:01 PM, Brian Mathis <span dir="ltr"><<a href="mailto:brian.mathis%2Bale@betteradmin.com">brian.mathis+ale@betteradmin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It doesn't matter what the remote user is when you generate the keys.<br>
The keys have no concept of user embedded in them. It only matters<br>
that you install the public key in the correct user account on the<br>
remote host, and you can install the same key in as many different<br>
accounts as you like.<br>
<br>
The username only comes into play when you try to login, such as when doing:<br>
rsync -avz files user@host:files<br>
ssh user@host<br>
<br>
If that's not what you mean, please describe what you are trying to do.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
❧ Brian Mathis<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Fri, Jan 27, 2012 at 4:47 PM, Wolf Halton <<a href="mailto:wolf.halton@gmail.com">wolf.halton@gmail.com</a>> wrote:<br>
> If you have dino user on the <a href="http://recipient.com" target="_blank">recipient.com</a> machine, but don't have a dino<br>
> user on the <a href="http://sending.com" target="_blank">sending.com</a> machine, you can easily ssh (knowing dino's password<br>
> on the receiver as you do) with ssh <a href="mailto:dino@recipient.com">dino@recipient.com</a> and when asked,<br>
> putting in dino's password.<br>
> You are logged in as <a href="mailto:moose@sending.com">moose@sending.com</a><br>
> how do you specify that the user you are doing ssh-keygen is the dino@large<br>
> user?<br>
> I can see you would be able to do fine if you did an adduser<br>
> <a href="mailto:dino@sending.com">dino@sending.com</a> and sudo to that user and ssh-keygen. Is that the only way<br>
> to do this. The man pages are silent on this issue<br>
><br>
><br>
> On Fri, Jan 13, 2012 at 1:56 PM, Jim Kinney <<a href="mailto:jim.kinney@gmail.com">jim.kinney@gmail.com</a>> wrote:<br>
>><br>
>> root user needs to do a keygen and put the pub on wilma.<br>
>><br>
>> On Fri, Jan 13, 2012 at 1:40 PM, Tim Watts <<a href="mailto:tim@cliftonfarm.org">tim@cliftonfarm.org</a>> wrote:<br>
>>><br>
>>> On Fri, 2012-01-13 at 11:51 -0500, Jim Kinney wrote:<br>
>>> > root on fred goes to fredbak on wilma<br>
>>><br>
>>> Just to be clear: does this mean that the backup job runs as root but<br>
>>> rsyncs as fredbak (via ssh key) to wilma? As in:<br>
>>><br>
>>> # rsync $OPTS $SRC fredbak@$TGTHOST:$DST<br>
>>><br>
>>> I get an error when I try to do something similar:<br>
>>><br>
>>> OPTS="-az --delete-during --delete-delay -h --progress --stats"<br>
>>><br>
>>> # rsync $OPTS /etc /home/timtw<br>
>>> timtw@blueberry:/home/timtw/backups/dellberry<br>
>>> Permission denied (publickey).<br>
>>> rsync: connection unexpectedly closed (0 bytes received so far) [sender]<br>
>>> rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]<br>
>>> #<br>
>>><br>
>>> I am able to ssh to blueberry via my ssh key when I'm timtw but not as<br>
>>> root. Is my key in the wrong place?<br>
>>><br>
>>><br>
</div></div><div class="im HOEnZb">>> --<br>
>> James P. Kinney III<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>This Apt Has Super Cow Powers - <a href="http://sourcefreedom.com" target="_blank">http://sourcefreedom.com</a><br>Advancing Libraries Together - <a href="http://LYRASIS.org" target="_blank">http://LYRASIS.org</a><br>
<br>