Giving Linux User Git Access But Not Shell Access

Github Authentication Failed - ... GitHub does not provide shell access

Try and redefine the ssh url for remote origin:

git remote set-url origin git@github.com:lut/EvolutionApp.git

And try again.

Only git remote set-url can change an existing remote URL (as opposed to git remote add, to add a new remote name and URL)

Here, the issue was the URL of the existing remote 'origin', EvolutionApp: it needed to be replaced by a valid one.

Using git config url."ssh://git@github.com/".insteadOf https://github.com/ would not have helped, considering there was no HTTPS URL in the first place.

Git thinks I'm a different user, won't give me access to github repo

This most likely is a misunderstanding in what credentials are used for what.

GitHub offers you to use two different protocols to access your repo:

HTTPS
SSH

SSH:

This one uses the ssh keys and settings in your ~/.ssh folder. It is used if you add a remote like this:

git remote add origin git@github.com:bclayman/SquashScraper.git

HTTPS (the one you chose):

This one uses the https credentials that depending on your system could be stored in various places (if at all). As it seems you're using the OS X Keychain, so they are most likely stored there. The https protocol is used if you add a remote like this:

git remote add origin https://github.com/bclayman/SquashScraper.git

So to get this resolved i'd open your OS X Keychain and search for https://github.com and delete all items that come up. Next time you try to push / fetch it should ask you for your username and password again.

Git: How to solve Permission denied (publickey) error when using Git?

If the user has not generated a ssh public/private key pair set before

This info is working on theChaw but can be applied to all other git repositories which support SSH pubkey authentications. (See [gitolite][1], gitlab or github for example.)

First start by setting up your own public/private key pair set. This
can use either DSA or RSA, so basically any key you setup will work.
On most systems you can use ssh-keygen.

First you'll want to cd into your .ssh directory. Open up the terminal and run:
cd ~/.ssh && ssh-keygen
Next you need to copy this to your clipboard.
On OS X run: cat id_rsa.pub | pbcopy
On Linux run: cat id_rsa.pub | xclip
On Windows (via Cygwin/Git Bash) run: cat id_rsa.pub | clip
On Windows (Powershell) run: Get-Content id_rsa.pub | Set-Clipboard (Thx to @orion elenzil)
Add your key to your account via the website.
Finally setup your .gitconfig.
git config --global user.name "bob"
git config --global user.email bob@...
(don't forget to restart your command line to make sure the config is reloaded)
That's it you should be good to clone and checkout.

Further information can be found at https://help.github.com/articles/generating-ssh-keys (thanks to @Lee Whitney)
[1]: https://github.com/sitaramc/gitolite

If the user has generated a ssh public/private key pair set before

check which key have been authorized on your github or gitlab account settings
determine which corresponding private key must be associated from your local computer

eval $(ssh-agent -s)

define where the keys are located

ssh-add ~/.ssh/id_rsa

Git asks for username every time I push

Edit (by @dk14 as suggested by moderators and comments)

WARNING: If you use credential.helper store from the answer, your password is going to be stored completely unencrypted ("as is") at ~/.git-credentials. Please consult the comments section below or the answers from the "Linked" section, especially if your employer has zero tolerance for security issues.

Even though accepted, it doesn't answer the actual OP's question about omitting a username only (not password). For the readers with that exact problem @grawity's answer might come in handy.

Original answer (by @Alexander Zhu):

You can store your credentials using the following command

$ git config credential.helper store
$ git push http://example.com/repo.git
Username: <type your username>
Password: <type your password>

Also I suggest you to read

$ git help credentials

git file permissions over ssh/git-shell?

See git config --help and search for core.sharedRepository.

If I understood it correctly for your configuration you have to put this in the config-file:

[core]
    sharedRepository = 0666

git pushes with wrong user from terminal

Despite all the great options given by other users, the only way to fix this was to reinstall git completely and type git config --global push.default simple to rewrite good credentials.

git/ssh - Having trouble with ssh authentication with multiple users

This part:

#Default GitHub
Host github.com-home
  HostName github.com
  User git
  IdentityFile /Users/rob/.ssh/home-01
  IdentitiesOnly yes

#wearenv-git
Host github.com-work
  HostName github.com
  User git
  IdentityFile /Users/rob/.ssh/work-01
  IdentitiesOnly yes

is correct, assuming the identities are in the named files, i.e., .ssh/home-01 and .ssh/work-01 in your home directory which is /Users/rob. You can make this simpler by writing:

    IdentityFile ~/.ssh/home-01

for instance as ~ means "my home directory" and hence this is automatically the right ~/.ssh/ directory and all you have to get right is the file name.

But this part is wrong:

ssh -i~/.ssh/work-01 git@github.com

Well, wrong is too strong: it works fine, it's just overkill. What you want is much simpler:

ssh github.com-home

to "log in" to git@github.com using your home identity, and

ssh github.com-work

to "log in" to git@github.com using your work identity. That is, instead of github.com we use the faked up "host name". I would spell this gh-work and gh-home for short myself:

Host gh-work
    User git

[etc] so that the "host name" is the unqualified string gh-work or gh-home, which is shorter and easier to type.

On your Mac, you may first need to run:

ssh-add ~/.ssh/work-01

and:

ssh-add ~/.ssh/home-01

(though just once after you've rebooted).¹ Use ssh-add -l to list the IDs that your agent knows about.

¹This makes use of the fact that macOS starts the ssh agent for you when you log in, providing the right environment variables to each shell opened in each terminal window. This way every terminal window opened from the time you log in shares a single agent process. There's no need to start one. Linux systems typically require you to start one as you log in, which in turn requires some fancy footwork in a .bashrc or .profile or other startup file. The macOS environment makes this much easier.

Making Git uses the right URL

Once the above works—you can easily test it with ssh -Tv github.com-home and so on, as you've written things—you simply need to convince Git to clone from, and push to, repositories stored on ssh://github.com-home/personal/repo and ssh://github.com-work/work/repo for instance.

This is where this kind of trick comes in:

[includeIf "gitdir:~/work-repos"]
    path = ~/work-repos/.gitconfig

(Note that I have added a ~ character that I think you dropped).

What we can do with includeIf is:

set user.name and user.email for work vs personal repos
make Git use an insteadOf rule for ssh://github.com/ URLs

and (this is the reason for the includeIf part) make the actual substitution conditional on whether this is a "work" or "home" repository based on where it lives in our home directories.

If you put your work repositories in ~/work-repos/* (as indicated here) and your personal ones elsewhere (perhaps ~/home-repos/? use whatever you like; as you've set this up only the ~/work-repos/ones get the work treatment), *and* add these lines to~/work-repos/.gitconfig`:

[url "ssh://github.com-work/"]
    insteadOf = ssh://github.com/

Now if you run:

git clone ssh://github.com/company/repo.git

Git will take that and change it to read:

git clone ssh://github.com-work/company/repo.git

This in turn will cause Git to run:

ssh github.com-work git-upload-...

That is, Git will ask ssh to connect to a host named github.com-work and run the smart protocol to access the company repository in company/repo.git.

We already know (and have tested) that ssh github.com-work actually connects to github.com, not github.com-work, and logs in as the work user using the work-user public-key so that your ssh command is correctly identified as "you-at-$company". This user therefore has access to the company repo and can clone it.

If you don't mind typing in the "wrong" URL (including the home/work distinction) in the first place, you don't need the insteadOf trick. The fact that you're using a fake host name will trigger ssh into using the desired identity on the real (github.com) host. But adding the insteadOf trick makes this even more convenient.

Since many people may use git@github.com:user/repo.git instead of ssh://github.com/user/repo.git, or add git@ in front of github.com to get ssh://git@github.com/user/repo.git, you may want multiple insteadOf rules here, e.g.:

[url "ssh://github.com-work/"]
    insteadOf = ssh://github.com/
    insteadOf = ssh://git@github.com/
    insteadOf = git@github.com:

There are many ways to work this, of course. Pick one that suits you best. Start by getting ssh to work the way you want, without adding Git into the mix at all. Then add Git, knowing that ssh is working the way you want.