[TriEmbed] need some specific help tonight

Pete Soper pete at soper.us
Mon Oct 9 14:39:56 CDT 2017



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>
> -------------------------------------------------------------------------------

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


More information about the TriEmbed mailing list