Error: Repository not found, private repo, but only when in a window over VNC on my CentOS 7 machine #22980
-
This is a new problem on a machine where it all worked up to the last time I tried it. I have not used the machine in this way for a couple of months at least so I don’t know when it started. For any private repo owned by me or my team, I can access it ok except when I use VNC to get to my CentOS 7 GNOME machine. Anything I run inside the VNC window fails to access any of my private repos, getting the Error: Repository not found. I tried this with git clone, git fetch in a directory I cloned already, and using the ssh git@github.com command line that git fetch uses. I have looked at the output from ssh -v -v -v -v and from git using the GIT_TRACE=2 environment variable, and the only error they show is the “Error: Repository not found”. I verified that a simple ssh git@github.com command does use the correct ssh key and authenticates. I have no problem accessing my repos that have pubilc access. When I ssh to the CentOS 7 machine and try the same things, everything works fine, so my ssh key and ssh configuration and my access to the repo all work. I only have had the failure when in the VNC window. I tried restarting the vnc server. Any ideas what might be the cause or what to look at next? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
It’s been a few years since I’ve used VNC but I can’t think of any reason why it wouldn’t work, especially if the SSH test is working and you’re using SSH authentication for git connections. Unfortunately, we don’t support VNC and according to your description, everything is working fine when you are logged in to the system directly. When you connect via |
Beta Was this translation helpful? Give feedback.
-
Hi, I got help from support that led me to the solution and forgot about the thread I started here. It turns out that the difference between the VNC session and not in VNC was that the latter was in a terminal ssh login to my computer that was non-GUI and did not use ssh-agent. When I was in a terminal in the VNC window, it was using ssh-agent. The problem was caused by the key that is specified in ~/.ssh/config for my login to github.com was in a subdirectory of ~/.ssh but only the keys in the first level directory ~/.ssh were automatically added to ssh-agent. When I ssh’d to the machine, not with VNC, ssh to github.com looked up the key to use in ~/.ssh/config In VNC it used ssh-agent which by default did not use any keys in ~/.ssh/subdirectory/ This was revealed by running the command ssh-add -l (that’s a lower case L option) to list what keys it was using. The fix was to run the command ssh-add to add the missing key to the list. |
Beta Was this translation helpful? Give feedback.
Hi, I got help from support that led me to the solution and forgot about the thread I started here.
It turns out that the difference between the VNC session and not in VNC was that the latter was in a terminal ssh login to my computer that was non-GUI and did not use ssh-agent. When I was in a terminal in the VNC window, it was using ssh-agent. The problem was caused by the key that is specified in ~/.ssh/config for my login to github.com was in a subdirectory of ~/.ssh but only the keys in the first level directory ~/.ssh were automatically added to ssh-agent.
When I ssh’d to the machine, not with VNC, ssh to github.com looked up the key to use in ~/.ssh/config
In VNC it used ssh-agent w…