[TriEmbed] need some specific help tonight

[Carl Nobile]

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
-------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20171009/22dbc933/attachment.htm>