ths for your post response, but I have some questions and comments
(embedded within your post)
On Saturday, July 21, 2012 6:56:50 AM UTC-7, Konstantin Khomoutov wrote:
>
>
>
> First, SSH and SSL have nothing in common except for the word [S]ecure
> and the naturally following fact they secure something (SSH secures the
> [SH]ell access and SSL secures the [S]ocket [L]ayer). These are
> completely disjoint protocols invented for differing needs.
>
> These protocols also use different approach for what you call "keys".
> SSH uses "shallow" approach to keys: a client generates a pair of
> keys -- one public and one private, -- then transfers the public part to
> the server and adds it to an *explicit* list of trusted keys. Hence the
> server either trusts that key or not; nothing else. The client actually
> does the similar thing by checking the server's key's fingerprint to see
> if it's known and trusted.
> SSL uses hierarchical approach to its "keys", which it calls
> "certificates": this stuff involves certification authotities (CAs) and
> trust chains they create. The whole topic is too deep to cover here but
> the end result is that usually either side or both explicitly trust some
> CA, and through this fact they tust each other.
> In either case, the wire format of the keys used by these protocols and
> the semantics of their usage is different.
>
Despite SSL support for hierarchical CAs, compared to your "shallow"
definition that is likely only an additional feature. x509 certs can be
self-signed, generated on the host itself, without a CA or levels of
hierarchy. In both cases the use of certs for identification,
authentication and authorization seems to me only a case of details when
the handshakes for both protocols sre actually similar.Also AFAIK the keys
for each protocol are similar, the containers for storage and exchange may
be different.
>
> One last thing to note is that while SSL/TLS is based solely around
> those X.509 certificates, SSH defines various methods for authentication
> of the client to the server: besides the "pubkey" method we've just
> discussed, it supports the very popular "keyboard interactive" method,
> Kerberos authentication and GSSAPI (SSPI in Microsoft lingo) which can
> also do Kerberos.
>
Agreed, but I think that for the purposes of establishing trusted sessions
with Github, we're only talking about two methods... Username/password and
cert keys. What prompted me to ask this question is that I've observed that
setting up Git to github requires generating clientside keys, but also
seems to require username/password... Am trying to verify my observation
that
- Trying to authenticate to Github even using SSL requires generating SSH
keys and entering the pubkey into your github Admin account
- Even after properly configuring your Github account with your pubkey, you
will still be prompted for Username/Password on each connetion, but can be
partially addressed clientside by modifying the credential helper caching
timeout.
So, this leads me to believe that SSH keys and Username/Password are
required for authentication
(And looking for verification)
>
> So no, the same keys can't be used for both SSL and SSH.
>
For the reasons I've described, I guess I'm still not convinced. You may be
correct, but not likely for the reasons you've given.
I think I'm not just being stubborn, and allow that perhaps I could be
fundamentally mistaken somewhere, but to me an RSA key is a generic key
that's only specific to the way the key is generated, and can be used by
any given application or protocol for proving identity and possibly
encryption.
>
> As to github, I think they implement two modes:
> 1) SSH keys are used to access the repo via SSH. You associate your SSH
>key with your github account and so when you're trying to
>authenticate the next time, Git knows who you are from your key.
> 2) SSL is used to simply encrypt the conversation with the server, and
>then HTTP (which tunnelled over SSL) uses simple password-based
>authentication method called "basic" to verify your identity.
>See https://github.com/blog/642-smart-http-support for hints on this.
>
What you state may be true for SSH, but regarding SSL doesn't seem to be
consistent with what I've experienced. But then, maybe I can try more
experiments with SSL to prove that the SSH pubkey that's now configured
isn't necessary or used for SSL.
Thx,
Unless a post describes where my obeservations and/or reasoning may be
flawed, I may just devote some time to experimenting with what may or may
not work with github.
TSU
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/git-users/-/uQB6N2AjPzgJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, s
