[TriEmbed] need some specific help tonight

[Pete Soper]

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. :-)

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.

Thanks, Jon!

-Pete



On 10/09/2017 02:55 PM, Jon Wolfe wrote:
> 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.
>
> 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.
>
> Depending on your needs, that might be simpler.
>
>
>
>
>
>
> -------- Original message --------
> From: Pete Soper via TriEmbed <triembed at triembed.org>
> Date: 10/9/17 2:35 PM (GMT-05:00)
> To: Robert Gasiorowski <rgresume at gmail.com>
> Cc: Triangle Embedded Computing Discussion <TriEmbed at triembed.org>
> Subject: Re: [TriEmbed] need some specific help tonight
>
>
>
> On 10/09/2017 02:07 PM, Robert Gasiorowski wrote:
>> Instead of password, why don't you use rsa keys? That way, you don't 
>> have to give your password away.
>> 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.
>
> 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.
>
> 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.
>
> -Pete
>>
>> On Mon, Oct 9, 2017 at 1:51 PM, Pete Soper via TriEmbed 
>> <triembed at triembed.org <mailto:triembed at triembed.org>> wrote:
>>
>>     Folks,
>>       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.
>>
>>       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).
>>
>>       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.
>>
>>       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.
>>
>>
>>     -Pete
>>
>>
>>     _______________________________________________
>>     Triangle, NC Embedded Computing mailing list
>>     TriEmbed at triembed.org <mailto:TriEmbed at triembed.org>
>>     http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>>     <http://mail.triembed.org/mailman/listinfo/triembed_triembed.org>
>>     TriEmbed web site: http://TriEmbed.org
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20171009/5b72ea17/attachment.htm>