[ale] [ot] Xmpp, ejabberd question

[Brian Mathis]

The public key does have the username in it by default, but that's a
comment field so it can be whatever you want.  It's only there so you
can easily see what keys are in your authorized_keys or *.pub files.

In order to login with no password, the private key needs to be
installed on the machine you are logging in from.  So you either need
to copy the private key around (maybe not a good idea), or generate a
new one for each source.  There's another way with ssh agent
forwarding, but that's somewhat more complex and probably best avoided
at this stage.


❧ Brian Mathis



On Fri, Jan 27, 2012 at 6:08 PM, Wolf Halton <wolf.halton at gmail.com> wrote:
> Hi Brian,
>
> 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.
>
> I went from within the account of jim at sender.com with the key generated
>
> "ssh-rsa [long hash] jim at MACHINENAME" user at 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
>
> 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.
> so now I can log in without a password from the account of jim at sender.com -
> when I try to log in to the dino account from some other account on
> sender.com or from sender2.com I get a password dialog again.
>
> I went to the account of jimbo at sender2.com and tried to log into
> dino at recipient.com and was met with a password dialog, so apparently it is
> important to be on the same machine.
>
> So I did a keygen at the new machine, where my login name is jimbo.  Logged
> in with a password to root at recipient.com and went to dino's authorized keys
> and added this one into the authorized keys there. Now I can log in to
> dino at recipient without a password from that account as well. That key has
> the embedded username jimbo at machinename2.
>
> So I sudo -i to root at sender2.com and attempt the same thing.  I must kegen
> and append ity to dino's authorized keys to login without a password as
> root at machinename2,
>
> Finally, I am beginning to understand it all.  Thanks for the help
>
> So, if I wanted (for some reason) a single user's directory on recipient.com
> 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 recipient.com 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.
>
> Now I can clock out and go home.
> 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.
>
> Wolf
>
> PS Thanks again!
>
> On Fri, Jan 27, 2012 at 5:01 PM, Brian Mathis
> <brian.mathis+ale at betteradmin.com> wrote:
>>
>> It doesn't matter what the remote user is when you generate the keys.
>> The keys have no concept of user embedded in them.  It only matters
>> that you install the public key in the correct user account on the
>> remote host, and you can install the same key in as many different
>> accounts as you like.
>>
>> The username only comes into play when you try to login, such as when
>> doing:
>>    rsync -avz files user at host:files
>>    ssh user at host
>>
>> If that's not what you mean, please describe what you are trying to do.
>>
>>
>> ❧ Brian Mathis
>>
>> On Fri, Jan 27, 2012 at 4:47 PM, Wolf Halton <wolf.halton at gmail.com>
>> wrote:
>> > If you have dino user on the recipient.com machine, but don't have a
>> > dino
>> > user on the sending.com machine, you can easily ssh (knowing dino's
>> > password
>> > on the receiver as you do) with ssh dino at recipient.com and when asked,
>> > putting in dino's password.
>> > You are logged in as moose at sending.com
>> > how do you specify that the user you are doing ssh-keygen is the
>> > dino at large
>> > user?
>> > I can see you would be able to do fine if you did an adduser
>> > dino at sending.com and sudo to that user and ssh-keygen.  Is that the only
>> > way
>> > to do this.  The man pages are silent on this issue
>> >
>> >
>> > On Fri, Jan 13, 2012 at 1:56 PM, Jim Kinney <jim.kinney at gmail.com>
>> > wrote:
>> >>
>> >> root user needs to do a keygen and put the pub on wilma.
>> >>
>> >> On Fri, Jan 13, 2012 at 1:40 PM, Tim Watts <tim at cliftonfarm.org> wrote:
>> >>>
>> >>> On Fri, 2012-01-13 at 11:51 -0500, Jim Kinney wrote:
>> >>> > root on fred goes to fredbak on wilma
>> >>>
>> >>> Just to be clear: does this mean that the backup job runs as root but
>> >>> rsyncs as fredbak (via ssh key) to wilma?  As in:
>> >>>
>> >>>        # rsync $OPTS $SRC fredbak@$TGTHOST:$DST
>> >>>
>> >>> I get an error when I try to do something similar:
>> >>>
>> >>> OPTS="-az --delete-during --delete-delay -h --progress --stats"
>> >>>
>> >>> # rsync $OPTS /etc /home/timtw
>> >>> timtw at blueberry:/home/timtw/backups/dellberry
>> >>> Permission denied (publickey).
>> >>> rsync: connection unexpectedly closed (0 bytes received so far)
>> >>> [sender]
>> >>> rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
>> >>> #
>> >>>
>> >>> I am able to ssh to blueberry via my ssh key when I'm timtw but not as
>> >>> root.  Is my key in the wrong place?
>> >>>
>> >> --
>> >> James P. Kinney III