<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Those last few steps might involve a merge. I want the other party
to have the honor of learning how to do merges. Even the kind of
painful, hairy merges that cause your hair to change color in a
single weekend and an oath to never, every agree to be a gatekeeper.
No wait, not those. :-) <br>
<br>
But I just checked Atlassian's terms and conditions. H E Y B I N G
O. We can use this directly and push to GitHub or GitLab or my
neighbor's dog house as a separate issue.<br>
<br>
Thanks, Jon!<br>
<br>
-Pete<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/09/2017 02:55 PM, Jon Wolfe
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:508vy63r3q22bfnjn0fdj5js.1507575339804@email.android.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
There's a good chance I won't be able to make it tonight, but if
you cant figure out a solution, ill be happy to help offline, I'm
somewhat of a git whiz.
<div><br>
</div>
<div>Git excells at decentralization, why even bother with giving
a 3rd party acess, just push the whole repo to a 2nd remote on
say, a private bit bucket repo? You can then take whatever they
push to bitbucket, and pull that locally, and then push to your
personal domain as needed.</div>
<div><br>
</div>
<div>Depending on your needs, that might be simpler.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<br>
-------- Original message --------<br>
From: Pete Soper via TriEmbed <a class="moz-txt-link-rfc2396E" href="mailto:triembed@triembed.org"><triembed@triembed.org></a> <br>
Date: 10/9/17 2:35 PM (GMT-05:00) <br>
To: Robert Gasiorowski <a class="moz-txt-link-rfc2396E" href="mailto:rgresume@gmail.com"><rgresume@gmail.com></a> <br>
Cc: Triangle Embedded Computing Discussion
<a class="moz-txt-link-rfc2396E" href="mailto:TriEmbed@triembed.org"><TriEmbed@triembed.org></a> <br>
Subject: Re: [TriEmbed] need some specific help tonight <br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/09/2017 02:07 PM, Robert
Gasiorowski wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEU50hX-Z03-8W8N7wrPoUnjWrXKBkat-U+W=Uf0DTiK_RFp8w@mail.gmail.com">
<div dir="ltr">Instead of password, why don't you use rsa keys?
That way, you don't have to give your password away.
<div>Create two sets of rsa keys, one for you and one for the
user, then add both private keys to authorized_keys on the
server, you keep your private key, and the user will get the
second private key.</div>
</div>
</blockquote>
<br>
Thanks, Bob! This is what I meant by "second ssh password". I'm
98% sure I can follow some detailed steps to accomplish this, but
it isn't sufficient: somebody could simply log into the server and
do anything at all with the session. I think I need for the login
program (i.e. typically a shell) to somehow know what password was
used for the login. <br>
<br>
But while dealing with a phone call private msg got here. If that
works I'll publish a cheat sheet in case anybody is interested.<br>
<br>
-Pete
<blockquote type="cite"
cite="mid:CAEU50hX-Z03-8W8N7wrPoUnjWrXKBkat-U+W=Uf0DTiK_RFp8w@mail.gmail.com">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Oct 9, 2017 at 1:51 PM, Pete
Soper via TriEmbed <span dir="ltr"><<a
href="mailto:triembed@triembed.org" target="_blank"
moz-do-not-send="true">triembed@triembed.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Folks,<br>
I have a problem that is off topic, but there is past
precedent for us helping each other with whatever. I'm
hoping somebody can sit with me and my laptop for a few
minutes at tonight's meeting and help me implement a
secure but strictly limited access scenario with my
personal domain server.<br>
<br>
I have a git repo on my personal domain server and can
push/pull remotely using my user account id and password
on a server running an old version of CentOS (2.6 kernel).<br>
<br>
What I need is to enable alternate access by a second
party where the person doing the access a) cannot use it
for anything except a git push or pull, b) uses a
different password from my regular one, and c) can
instantly lose this access if I'm told by my ISP that this
dog won't hunt in regards to his terms of service.<br>
<br>
My simple minded understanding of this is that I need to
arrange a second ssh password, which I think I can figure
out, and somehow only allow that password to be used for
git commands (which I have no clue about). I think this
latter detail is either impossible without a second user
account on the server, and that isn't an option, or else
with some additional authentication magic that recognizes
my regular password and proceeds or this other password
that redefines PATH or something to make all but git
inaccessible. Or maybe somebody knows of a virtually
nearby log I can fall over.<br>
<br>
<br>
-Pete<br>
<br>
<br>
______________________________<wbr>_________________<br>
Triangle, NC Embedded Computing mailing list<br>
<a href="mailto:TriEmbed@triembed.org" target="_blank"
moz-do-not-send="true">TriEmbed@triembed.org</a><br>
<a
href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mail.triembed.org/mailm<wbr>an/listinfo/triembed_triembed.<wbr>org</a><br>
TriEmbed web site: <a href="http://TriEmbed.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://TriEmbed.org</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>