[TriEmbed] need some specific help tonight
Pete Soper
pete at soper.us
Mon Oct 9 14:50:52 CDT 2017
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
> <mailto: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
>> <mailto: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 <mailto: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 <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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> --
>> -------------------------------------------------------------------------------
>> Carl J. Nobile (Software Engineer)
>> carl.nobile at gmail.com <mailto:carl.nobile at gmail.com>
>> -------------------------------------------------------------------------------
>
>
>
>
> --
> -------------------------------------------------------------------------------
> Carl J. Nobile (Software Engineer)
> carl.nobile at gmail.com <mailto:carl.nobile at gmail.com>
> -------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20171009/5f567f47/attachment.htm>
More information about the TriEmbed
mailing list