When Using git clone, I come into an error.
Here is the command and the error information.
[user#linux]$ git clone git#github.com:username/repertory.git
FATAL: failed to begin relaying via HTTP.
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Except for git#github, git clone https://...... and git clone git://...... works well. So i guess there is something wrong with ssh protocal, then i checked ssh.
[user#linux]$ ssh -T git#github.com
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
It seems that I can connect to github through ssh protocol properly. But what's wrong with git clone through ssh?
This error message comes from connect.c from SSH
It is a SSH Proxy Command -- connect.c, the simple relaying command to make network connection via SOCKS and https proxy: You can make SSH session beyond the firewall with this command.
So check if such a connection is needed: it could very well be needed if you are in an enterprise, behind firewall, but in that case do contact your IT support team to check the validity/approval of such a solution.
And that error message indicates that even this SSH mode (relay through https proxy) might be blocked.
If you are not in an enterprise setting, and don't need proxy, do remove them (HTTPS(S)/PROXY) from your environment variables and your git config file.
If you're using a Proxy, many corporate firewalls block access to the CONNECT method on ports other than 443. GitHub operates an SSH server listening on port 443, using the host "ssh.github.com".
First, configure your SSH ~/.ssh/config with the following:
Host github.com, ssh.github.com
User git
Hostname ssh.github.com
Port 443
ProxyCommand socat - PROXY:localhost:%h:%p,proxyport=3128
in the example above I'm assuming you're running a web proxy on host localhost and port 3128 (e.g. cntlm).
You may also substitute socat with nc or connect-proxy with slightly different syntax.
Test with:
ssh -T git#ssh.github.com
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
then with:
git clone git#ssh.github.com:username/repository.git
Related
Essentially I cannot connect to an SSH server anymore. Whenever I try to connect I get the following error:
ssh: connect to host HOSTNAME port 22: Connection refused
Note that I am able to connect from a different machine. Hence, the issue seems to be client side. Furthermore, I also cannot pull/push to git repositories that are cloned via ssh. Again, when pulling I get the following error:
ssh: connect to host github.com port 22: Connection refused
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists
It seems like I somehow nuked my SSH installations/config files. I have reinstalled SSH but this did not fix the problem. Any ideas?
Note that you never "connect" to github.com directly (no interactive shell)
As mentioned here, "Connection refused" means
invalid IP address for github.com (manual entry in /etc/hosts or your resolver)
firewall along the way to github.com which blocks the ssh traffic (eg. local firewall or corporate firewall)
So is the other machine (where you do succeed) on the same network?
Check if the other machine SSH config file was not using ssh.gthub.com port 443 (instead of the default github.com:22, typically blocked in a corporate environment).
I can clone over https just fine but after I connect my ssh key, I keep getting the following error:
ssh: connect to host gitlab.example.com port 22: Operation timed out
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I've tried deleting and recreating the ssh key and adjusting the config port to 443 and nothing has worked.
If this is an on-premise GitLab installation (meaning not gitlab.com), chances are port 22 is should not be blocked.
Double-check that with:
curl -v telnet://gitlab.example.com:22
Switching to 443 would rather involve HTTPS. (github.com does have an SSH listener on port 443 or ssh.github.com, but that is probably not the case for your own GitLab server), unless your server is configured to do so on altssh.gitlab.example.com.
I am tyring to create a local git repository with this command on ubuntu 14.10, but it fails with error "you don't have correct access rights". Any idea what could be the problem?, is it a firewall issus?
$git clone -o khronos git#gitlab.khronos.org:vulkan/LoaderAndTools.git .
Cloning into '.'...
ssh: connect to host gitlab.khronos.org port 22: Connection timed out
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Thanks
The Connection timed out message indicates that your machine cannot connect to port 22.
As I can reach gitlab.khronos.org port 22 fine, my conclusion would be that it is a firewall in your local network that is the problem.
I'd like to copy my config.yml file from my local django app directory to my heroku server, but I'm not sure how to get the user#host.com format for heroku.
I've tried running 'heroku run bash'
scp /home/user/app/config.yml
I'm not sure how I can get it in the
scp user#myhost.com:/home/user/dir1/file.txt user#myhost.com:/home/user/dir2'
format
As #tamas7 said it's firewalled, but your local machine is probably also firewalled. So unless you have a private server with SSH accessible from the Internet, you won't be able to scp.
I'm personally using transfer.sh free and open source service.
Upload your config.yml to it:
$ curl --upload-file ./config.yml https://transfer.sh/
https://transfer.sh/66nb8/config.yml
Then download it back from wherever you want:
$ wget https://transfer.sh/66nb8/config.yml
According to http://www.evans.io/posts/heroku-survival-guide/ incoming connections are firewalled off. In this case you need to approach your local machine from the Heroku server.
heroku run bash
scp user#mylocalmachine:/home/user/dir/file.txt .
This is a bit late to answer this question, but I use services like localtunnel - https://localtunnel.github.io/www/ to copy files from local machine to heroku.
First, run a python HTTP server in the directory where the file is located.
cd /path/to/file
python3 -m http.server
This starts a server in port 8000. Configure localtunnel to connect to that port.
lt -s mylocal -p 8000
Now from your heroku machine, you can fetch the file via curl.
curl -XGET http://mylocal.localtunnel.me/myfile.txt > myfile.txt
You could also use a service like https://ngrok.com/ to open up a TCP tunnel into your local machine.
You will need to enable Remote Login as in simlmx answer.
On your local machine open the TCP tunnel just like this:
$ ngrok tcp 22
And then, on the Heroku console, just use SCP with the PORT and HOST that Ngrok provided.
$ scp -P [PORT] username#[HOST]:~/path/to/file.ext .
If you need to download your entire repo, for example to recover an app that you no longer have locally, use heroku git:clone -a myapp. Docs.
Expanding on tamas7's answer:
You can connect to your computer from the heroku server.
If your computer is behind a router, you'll also need to forward the connection to your computer.
1. You computer must accept ssh connections
On my mac it was as simple as enabling it in the Preferences / Sharing panel.
2. Your router needs to forward the connection to your computer.
Go to your router's settings page in your browser (typically 192.168.0.1 but varies depending on the router). Find the port forwarding section and forward some port to your computer on port 22.
This is how it looked on my tp-link:
Here I am making sure that port 22000 is forwarded to my computer (192.168.0.110) on port 22.
3. Find your external IP
Simply google "what is my IP".
4. Scp your file from heroku
heroku run bash
scp -P 22000 your_user#your_external_IP:/path/to/your/file .
5. Undo everything!
Once you're done it's probably good practice to disable the port forwarding and remote login.
I am using agent forwarding, it works fine. But the ssh client is sharing all registered (ssh-add) keys with the remote server. I have personal keys that I don't want to share with the remote server. Is there a way to restrict with keys are being forwarded?
I have multiple github accounts and aws accounts. I don't want to share all the ssh-keys.
Looks like it is possible with OpenSSH 6.7 - it supports unix socket forwarding. We could start secondary ssh-agent with specific keys and forward it's socket to remote host. Unfortunately this version is not available for my server/client systems at the time of writing.
I have found another possible solution, using socat and standard SSH TCP forwarding.
Idea
On local host we run secondary ssh-agent with only keys we want to see on remote host.
On local host we set up forwarding of TCP connections on some port (portXXX) to secondary ssh-agent's socket.
On remote host we set up forwarding from some socket to some TCP port (portYYY).
Then we establish ssh connection with port forwarding from remote's portYYY to local portXXX.
Requests to ssh agent go like this:
local ssh-agent (secondary)
^
|
v
/tmp/ssh-.../agent.ZZZZZ - agent's socket
^
| (socat local)
v
localhost:portXXX
^
| (ssh port forwarding)
v
remote's localhost:portYYY
^
| (socat remote)
v
$HOME/tmp/agent.socket
^
| (requests for auth via agent)
v
SSH_AUTH_SOCK=$HOME/tmp/agent.socket
^
| (uses SSH_AUTH_SOCK variable to find agent socket)
v
ssh
Drawbacks
It is not completely secure, because ssh-agent becomes partially available through TCP: users of remote host can connect to your local agent on 127.0.0.1:portYYY, and other users of your local host can connect on 127.0.0.1:portXXX. But they will see only limited set of keys you manually added to this agent. And, as AllenLuce mentioned, they can't grab it, they only could use it for authentication while agent is running.
socat must be installed on remote host. But looks like it is possible to simply upload precompiled binary (I tested it on FreeBSD and it works).
No automation: keys must be added manually via ssh-add, forwarding requires 2 extra processes (socat) to be run, multiple ssh connections must be managed manually.
So, this answer is probably just a proof of concept and not a production solution.
Let's see how it can be done.
Instruction
Client side (where ssh-agent is running)
Run new ssh-agent. It will be used for keys you want to see on remote host only.
$ ssh-agent # below is ssh-agent output, DO NOT ACTUALLY RUN THESE COMMANDS BELOW
SSH_AUTH_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982; export SSH_AUTH_SOCK;
SSH_AGENT_PID=22983; export SSH_AGENT_PID;
It prints some variables. Do not set them: you will loose your main ssh agent. Set another variable with suggested value of SSH_AUTH_SOCK:
SSH_AUTH_SECONDARY_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982
Then establish forwarding from some TCP port to our ssh-agent socket locally:
PORT=9898
socat TCP4-LISTEN:$PORT,bind=127.0.0.1,fork UNIX-CONNECT:$SSH_AUTH_SECONDARY_SOCK &
socat will run in background. Do not forget to kill it when you're done.
Add some keys using ssh-add, but run it with modified enviromnent variable SSH_AUTH_SOCK:
SSH_AUTH_SOCK=$SSH_AUTH_SECONDARY_SOCK ssh-add
Server side (remote host)
Connect to remote host with port forwarding. Your main (not secondary) ssh agent will be used for auth on hostA (but will not be available from it, as we do not forward it).
home-host$ PORT=9898 # same port as above
home-host$ ssh -R $PORT:localhost:$PORT userA#hostA
On remote host establish forwarding from ssh-agent socket to same TCP port as on your home host:
remote-host$ PORT=9898 # same port as on home host
remote-host$ mkdir -p $HOME/tmp
remote-host$ SOCKET=$HOME/tmp/ssh-agent.socket
remote-host$ socat UNIX-LISTEN:$SOCKET,fork TCP4:localhost:$PORT &
socat will run in background. Do not forget to kill it when you're done. It does not automatically exit when you close ssh connection.
Connection
On remote host set enviromnent variable for ssh to know where agent socket (from previous step) is. It can be done in same ssh session or in parallel one.
remote-host$ export SSH_AUTH_SOCK=$HOME/tmp/ssh-agent.socket
Now it is possible to use secondary agent's keys on remote host:
remote-host$ ssh userB#hostB # uses secondary ssh agent
Welcome to hostB!
The keys themselves are not shared by forwarding your agent. What's forwarded is the ability to contact the ssh-agent on your local host. Remote systems send challenge requests through the forwarding tunnel. They do not request the keys themselves.
See http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd for a graphical explanation.