On Sun, 17 Nov 2013 20:43:24 -0800 (PST)
stoici...@aol.com wrote:

> I generated ssh public keys on server, uploaded it to github
> repository, so that I can deploy my project to the server. My
> question is if someone has access to the server and they log in and
> view the ssh keys, can they somehow read or write to the git
> repository on github? The github repository is currently set to
> private and I don't want anyone to read or write to it.

Supposedly you're confused about the concept behind SSH keys (as there
are lots of heavily dumbed-down HOWTOs on generating them which
concentrate on the process rather than on the theory).

You never generate "SSH public keys" -- rather, you generate SSH keys
(usually dubbed "private"), and, from each SSH key its public part may
be derived any time, and it has a property of uniquely identifying the
key it has been derived from.

Pubkey-based authentication in SSH is based on trusting particular
keys: when you "upload your public key to github" you basically make
github grant access to your repository to whoever managed to prove to
the github's SSH server they possess the matching (private) SSH key.

Since pubkey-based authentication is SSH is all about trusting SSH keys
using their public parts, the key management tools built for SSH tend
to derive the public part (and offer to save it separately) right along
with the SSH key itself -- so that's the confusion.  For instance,
OpenSSH, which is the de-facto standard SSH solution on POSIX systems,
writes out two files, usually named id_rsa and id_rsa.pub when
generating an RSA key -- the first one is the key itself and the second
one is the public key extracted from the (private) key.

Now back to your problem: there's no security rooted in a public part
of an SSH key *unless* you make some system trust its matching key and
subsequently grant the owners of the matching (private) key certain
rights on that system.  Conversely, the private key itself must be kept
secret, and unless absolutely necessary [*] it must be protected with a
passphrase (that is, it must be encrypted).  Typically, OpenSSH ensures
the id_rsa file it writes has its owner and group set for your user and
your primary group, and has permission bits set to 0600, and the
directory to store sensitive SSH data, typically ~/.ssh, has similar
access rights set up (plus execution bits, as it's a directory).

Hence unless you have goofed somehow, the access to your keys is
defined by the access rights outlined above:
* The superuser (root).
* The members of your primary group.
* Whoever knows the password of your system account (or has other means
  to log in using your credentials).
* Whoever is granted rights to use your credentials using access rights
  elevation frameworks, such as sudo.
Additionally, if your key is encrypted, whoever gained access to it has
to also know the passphrase used for encryption.

[*] The only legitimate use case for unencrypted SSH keys is automated
    software solutions making use of SSH, such as backup clients.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to