[ale] [ot] Xmpp, ejabberd question

Fri Jan 27 18:08:46 EST 2012

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.comthat 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
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>

-- 
This Apt Has Super Cow Powers - http://sourcefreedom.com
Advancing Libraries Together - http://LYRASIS.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120127/5875e9ac/attachment.html 