[TriEmbed] need some specific help tonight

[Carl Nobile]

FYI--GitHub and Bitbucket are competitors. GitHub is owned by well GitHub
and BitBucket is owned by Atlassian, both use the GIT repo system invented
by Linus Torvals himself for the Linux project.


On Mon, Oct 9, 2017 at 3:50 PM, Pete Soper <pete at soper.us> wrote:

> Oh, got it. The how-to Robert pointed to via private email is no doubt
> exactly this approach, and that may be very valuable to me some other day,
> but for now I can just treat GitHub as a parent of an Atlassian repo and
> get on with my life.
>
> Thanks again!
>
> -Pete
>
>
> On 10/09/2017 03:43 PM, Carl Nobile wrote:
>
> Pete, they would not be logging into the server with a UNIX shell account,
> this would only be an authenticated request to the git server running on
> your server. Git handles this and it is exactly hos GitHub and Bitbucket
> works.
>
> ~Carl
>
>
> On Mon, Oct 9, 2017 at 3:39 PM, Pete Soper <pete at soper.us> wrote:
>
>>
>>
>> On 10/09/2017 03:28 PM, Carl Nobile wrote:
>>
>>
>> Pete,
>>
>> Here is my two-cents.
>>
>> If you have git running on a local server there is a way to set it up to
>> use ssh. It must be set up on the server side to do this correctly. I've
>> done it before, but it was a few years ago. You would use a URL similar to
>> this, "git at github.com:<path to git repo>.git" to access the repo. After
>> the server is setup then you will need to acquire the public ssh keys,
>> usually in a file named ".ssh/id_rsa.pub" from the user. This can be sent
>> in email, but never send the private key. Once the public key is in the
>> ".ssh/authorized_keys" file of the account used by the git server the
>> person can log in. Sounds more complicated than it really is.
>>
>> Thanks for the extra detail.
>>
>> It's "the person can log in" part that would cause my ISP of the past 17
>> years to fire me as a customer in a New York minute. Anything that could be
>> possibly interpreted as "login to an interactive shell command line
>> session" collides with terms and conditions.
>>
>> -Pete
>>
>>
>>
>> I set this up for the Humanoid robotics project, but I doubt they are
>> still using it. It is really a lot easier to use a GitHub account which I
>> think they use now.
>>
>> ~Carl
>>
>> On Mon, Oct 9, 2017 at 2:35 PM, Pete Soper via TriEmbed <
>> triembed at triembed.org> wrote:
>>
>>>
>>>
>>> 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> 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
>>>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>>>> TriEmbed web site: http://TriEmbed.org
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Triangle, NC Embedded Computing mailing list
>>> TriEmbed at triembed.org
>>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>>> TriEmbed web site: http://TriEmbed.org
>>>
>>>
>>
>>
>> --
>> ------------------------------------------------------------
>> -------------------
>> Carl J. Nobile (Software Engineer)
>> carl.nobile at gmail.com
>> ------------------------------------------------------------
>> -------------------
>>
>>
>>
>
>
> --
> ------------------------------------------------------------
> -------------------
> Carl J. Nobile (Software Engineer)
> carl.nobile at gmail.com
> ------------------------------------------------------------
> -------------------
>
>
>


-- 
-------------------------------------------------------------------------------
Carl J. Nobile (Software Engineer)
carl.nobile at gmail.com
-------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20171009/2a560f1d/attachment.htm>