Force git pull and clone to not prompt for password

From Gitosis' point of view, your name is just the name, in keydir, of the public key that you authenticated with. No configuration on your local machine matters, except as it affects what public key you use, and the string at the end of the key doesn't matter -- just the filename.

You've given your public key two names, so when you authenticate with that key it is undefined which one of them it finds when it looks for a name for that key. When you changed some other things in Gitosis, presumably it happened to change the arbitrary choice of which name it found.

(Specifically, I believe Gitosis generates its own authorized_keys to contain all the keys in keydir, one per line, with options to tell sshd to only let the user run Gitosis, only in a controlled manner, and telling Gitosis the name of the key. If multiple lines have the same key, I'm not sure which one sshd ends up using -- maybe the first, maybe the last, maybe it's arbitrary. The order in which Gitosis writes them may also be arbitrary. But really the details of how the arbitrary choice happens are beside the point, because nobody guarantees they won't change in the next update to sshd or gitosis.)

You should pick which name you want to use to refer to yourself in the Gitosis config, and keep in keydir only the copy of your key under that name.

Are you able to clone locally on the VM using a file: protocol repository URL?

git clone file:///srv/repos/git/myProj /tmp/myProj-clone

The file: protocol forces local operations to use a protocol that is very close to the normal smart protocol used by git:/ssh:/smart-http: remote URLs. Specifically, it uses a pack-based protocol instead of taking advantage of the normal optimization for local operations (hardlinking/copying of repository objects).

You may not have enough memory for the server to generate the pack required for your pull operation. Doing a trial, local, file:-based clone/pull will exercise the pack generation capabilities of your VM without dragging in any kind of networking components to confuse the issue.

There are several configuration variables that control the generation of packs:

• pack.window
• pack.depth
• pack.windowMemory
• pack.deltaCacheSize
• pack.deltaCacheLimit

You might be able to tune your repository to generate its packs in a less memory intensive fashion (the packing efficiency will likely suffer as a result though).

My guess is that 256MB (for OS and applications?) is just too small to expect (potentially) memory hungry applications (like Git's pack operations) to work quickly or even correctly.