I am in AWS and i have two VPCS between virgina and oregon and I am trying to SSH from either region.
My rules allow everything needed and I can ping
Virgina
IPSEC-Machine 10.10.1.47
Host-Machine-V 10.10.4.125
Oregon
IPSEC-Machine 10.20.0.97
Host-Machine-O 10.20.1.190
I can ping between regions
[ec2-user#ip-10-20-0-97 ~]$ ping 10.10.1.47
PING 10.10.1.47 (10.10.1.47) 56(84) bytes of data.
64 bytes from 10.10.1.47: icmp_seq=1 ttl=64 time=60.5 ms
--- 10.10.1.47 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1002ms
rtt min/avg/max/mdev = 60.560/60.560/60.560/0.000 ms
SSH seems to work
[ec2-user#ip-10-10-1-47 ~]$ nc -v -w 1 10.20.1.190 -z 22
Connection to 10.20.1.190 22 port [tcp/ssh] succeeded!
[ec2-user#ip-10-10-1-47 ~]$
But when on 10.10.1.47 and I type ssh 10.20.1.190 it just hangs and I get nothing. The keys are all correct but even if I get a permission denied at this point I would be happy.
I'm not really sure what could be causing this, but here are a few things to try:
Use the EC2 hostname to connect - it's possible that something in the addressing is causing problems between the regions. My only guess at the moment is that the IP address is actually someone else's server in the Virginia region, and not your server in Oregon.
Run the nmap portscanner to ensure that the port is open. I saw that you used netcat, but a proper portscan may help.
Run ssh -vvv to get verbose output, this may give you some information to figure out what the problem is.
Related
For a project, I need to access the faculty server
Remotely through ssh after connecting the faculty VPN with my credentials.
Before,I log in quietly until recently with:
ssh my_name_user#147.163.26.244
it appeared to enter the password and entering the credentials I accessed the server (actually a virtual machine mounted on the server for me).
Now with the command above nothing happens and after waiting a bit I get:
ssh: connect to host 147.163.26.244 port 22: Connection timed out
What may have happened?
Yesterday I changed my password to access University services (mandatory after 3 months for security reasons). After doing so I had to change that new password in the VPN configurations and I was able to have access to the VPN and also to the server, until this all ok. From today at 13.00 this problem occurs.
Does anyone have any idea what this is all about?
(I'm on Ubuntu. The server(the virtual machine is a Lubuntu system))
Thanks for your attention.
Update:
The command
ping 147.163.26.244
gives me:
PING 147.163.26.244 (147.163.26.244) 56(84) bytes of data.
and
telnet 147.163.26.244 22
gives:
Trying 147.163.26.244...
and it remain running. What can I deduce?
As ssh shows connection timeout its nothing to do with your credentials. It hasn't go to the authentication level but failing before that itself.
First of all check if the IP is accessible from you machine using Ping (hoping ICMP should be allowed by the Firewall).
ping server_ip
If it shows not accessible- then make sure there is a route for the IP/IP subnet of the server IP through the vpn tunnel. You can do it by using route/netstat
example
netstat -nr | grep "147.163"
If route is not present you may have to add a route for this IP through the VPN tunnel. You can find the "route add.." or "ip route add ... " commands for this from google depending on your machine platform.
If the Ping shows the IP is pinging, we need to make sure the ssh service is running on the port 22. Just do a telnet and check
telnet <server_ip> 22
if the connection shows UP, in your case which shouldn't show UP btw :)as you got a timeout already. Then problem can be
(1) ssh service not running
(2) any firewall blocking your connection
You may have to get in touch with the ADMIN in that case.
===== Update =========
I guess your ping itself is failing.
Ping should show it is getting response.
example :
XXXXXXX$ ping 216.58.217.174
PING 216.58.217.174 (216.58.217.174): 56 data bytes
64 bytes from 216.58.217.174: icmp_seq=0 ttl=43 time=273.068 ms
64 bytes from 216.58.217.174: icmp_seq=1 ttl=43 time=317.405 ms
64 bytes from 216.58.217.174: icmp_seq=2 ttl=43 time=361.682 ms
64 bytes from 216.58.217.174: icmp_seq=3 ttl=43 time=266.436 ms
Check for the routes in your machine using route or netstat.
Possibilities :
server is down
Proper route is not present for the IP/subnet of the ssh server through VPN tunnel
I have found a partial answer to this question, and it is successfully setting the machine at the desired IP address. But the network is unreachable from inside a docker-machine created with the Hyper-V driver.
The TLDR on the answer above is to create a script, /var/lib/boot2docker/bootsync.sh:
sudo cat /var/run/udhcpc.eth0.pid | xargs sudo kill
sudo ifconfig eth0 192.168.XXX.YYY netmask 255.255.255.0 broadcast 192.168.XXX.255 up
Once I make the script, I restart the machine.
When I restart the machine, the IP is set to my desired address (expected). I can remote in at the address, so it is at least available through the host. But when I test for connections, there is no connection to the internet (unexpected).
Boot2Docker version 17.05.0-ce, build HEAD : 5ed2840 - Fri May 5 21:04:09 UTC 2017
Docker version 17.05.0-ce, build 89658be
docker#machine:~$ docker pull ubuntu
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:48331->[::1]:53: read: connection refused
docker#machine:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
If I remove the script and restart again, I am reassigned a new/random IP address (expected), remote in at that new IP address, and can do network connections (expected):
docker#pm:~$ docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
aafe6b5e13de: Pull complete
0a2b43a72660: Pull complete
18bdd1e546d2: Pull complete
8198342c3e05: Pull complete
f56970a44fd4: Pull complete
Digest: sha256:f3a61450ae43896c4332bda5e78b453f4a93179045f20c8181043b26b5e79028
Status: Downloaded newer image for ubuntu:latest
docker#pm:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=18.424 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=27.638 ms
The accepted answer has several up votes, but it reads like this is a confirmed work around on VirtualBox. Not sure what about Hyper-V would be causing the IP assignment to cut off internet access.
I had the same problem, and I solved it by adding the following to the end of bootsync.sh:
route add default gw <address>
There was no default route to the gateway or the internet, so it must be set manually.
Let me explain my very strange problem. I have one server (Linux Debian Jessie) which had access to my git repository on gitlab.com
Two days ago, I tried to pull some modifications on this server with a simple git pull. I received an error message :
ssh: connect to host gitlab.com port 22: Connection timed out
Si I have done some tests
1. TELNET
To understand why, I have tried a telnet on 22 port = TIMEOUT
2. IPTABLES
I checked my iptables to be sure that SSH port was allowed. It is. If I try a telnet on another service for example like github.com, it works. So I'm allowed in OUTPUT on this port.
3. PING
I thought a ip translation problem. I have done a ping, I obtain this message :
PING 104.210.2.228 (104.210.2.228) 56(84) bytes of data.
--- 104.210.2.228 ping statistics ---
87 packets transmitted, 0 received, 100% packet loss, time 86534ms
4. FAIL2BAN
I use fail2ban, so I have checked if gitlab was in jail address, but it seems not.
So my problem is that I can't reach gitlab.com
If I try from my local machine or from another server, I don't have this problem. It works.
I can't reach gitlab.com only from this server but I don't know why. Maybe someone has an idea which cans be very precious to help me ?
Probably some modification of firewall caused this. For a quick solution use http protocol instead of ssh. Change your url in the git config file to http.
git config --local -e
change entry of
url = git#gitlab.com:username/repo.git , to
url = https://gitlab.com/username/repo.git
You need to give your username and password to authenticate yourself while making a push or pull though as it's http based.
I'm having a bit of an issue with a Virtual Machine (VM) I have. Basically, I was trying to log into FTP on my web-server, but forgot the logins. As such, it has now blocked the VM's IP. I found it with:
iptables -L -n --line | grep "xxxxx"
Turns out it was blocked in the ALLOWIN and ALLOWOUT chains. So, I removed it with:
iptables -D ALLOWIN -s x.x.x.x -j DROP
iptables -D ALLOWOUT -s x.x.x.x -j DROP
The saved the config:
service iptables save
I even tried a reboot , using:
/etc/init.d/iptables restart
Then I try it on the VM, but it times out:
D:\Users\Andy>ping chambresdhotes.org
Pinging chambresdhotes.org [216.38.63.234] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 216.38.63.234:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
I'm at a bit of a loss as to what else I can try. Any suggestions are much appreciated.
FWIW, I have also done an:
iptable -L | grep 123.123.123.123
..but it gives no results (which I assume means there are no matching rules!)
Ok, I'm deciding if I should delete this question or not - but think it may be good to leave up, in case anyone else has a similar issue.
I found the problem. The VM is with Amazon, so I thought I'd just do a search for "amazon" in the iptable -L. Turned out there was an IP that was blocked:
LOGDROPOUT all -- anywhere ec2-52-210-49-189.eu-west-1.compute.amazonaws.com
I removed that one from both the DENYIN and DENYOUT, saved + restarted iptables, and voila... it works now!
I stopped and restarted an ubuntu 14.04 Google Cloud Compute Engine instance, and now my ssh connection is refused with:
ssh: connect to host 146.148.114.98 port 22: Connection refused
This already happened a previous time, I thought there was a problem with the machine, I deleted it and recreated and it started working again. I don't want to be recreating instances every time. The ssh troubleshooting page of google cloud is quite messy. My firewall rules seem to be ok. Anyone has a solution for this?
NAME NETWORK SRC_RANGES RULES SRC_TAGS TARGET_TAGS
default-allow-http default 0.0.0.0/0 tcp:80 http-server
default-allow-https default 0.0.0.0/0 tcp:443 https-server
default-allow-icmp default 0.0.0.0/0 icmp
default-allow-internal default 10.128.0.0/9 tcp:0-65535,udp:0-65535,icmp
default-allow-rdp default 0.0.0.0/0 tcp:3389
default-allow-ssh default 0.0.0.0/0 tcp:22
This is the output for: ps aux | grep ssh
root 29 0.0 0.4 55184 2860 ? Ss 11:26 0:00 /usr/sbin/sshd -p 22 -o AuthorizedKeysCommand=/google/devshell/authorized_keys.sh -o Author
izedKeysCommandUser=root
root 183 0.0 0.9 82692 5940 ? Ss 11:26 0:00 sshd: fbeshox [priv]
fbeshox 218 0.0 0.7 82692 4424 ? S 11:26 0:00 sshd: fbeshox#pts/0
fbeshox 522 0.0 0.3 12728 2200 pts/1 S+ 12:12 0:00 grep ssh
Here the verbose results of the ssh connetion attempt.
ssh -i .ssh/keyname username#130.211.53.51 -vvv
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/xxxx/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 130.211.53.51 [130.211.53.51] port 22.
debug1: connect to address 130.211.53.51 port 22: Connection refused
ssh: connect to host 130.211.53.51 port 22: Connection refused
It is possible that sshguard, a security tool installed on Ubuntu by default, is interfering with your connection. Basically sshguard might have incorrectly decided that your IP address is 'attacking' your instance and blocked the IP.
If you can log in from a different location, such as the Web SSH provided by the Cloud Console, try using sudo iptables -S to see if there are any firewall rules on the instance (different than the GCE firewall) created by sshguard. If so try disabling sshguard or adding your IP address on the whitlelist (http://www.sshguard.net/docs/whitelist/).
I know this is an old question but today I had similar issue and the problem was very simple - IP of the instance is changed after restart - so I had to update ssh string accordingly
This issue often happens after you changed your default zone or region.
Then, you must update the ssh keys in your metadata by
sudo gcloud compute config-ssh
You can see also the changes in the web interface under Compute Engine | Metadata | SSH Keys.
Try to SSH into the instance with a different username .Google Compute is a bit shaky at times . Try to SSH into the instance using VM instance page in Compute Engine . If SSH takes too much time and refuses connection, then login with a different username in SSH . You can login with a different name using a settings icon on top right corner of SSH window . If these all these doesn't go well, I will advise you to re create one more instance, as it has also been my experience that Google Compute Engine instances are not stable in terms of SSH accessibility and tend to create problems .It's better to use putty as a client to SSH into Compute Engine than the SSH terminals Google provides . Let me know if that helps you :)
I understood that my problem raised after detaching a disk from the console when the machine was stopped with that disk mounted. First unmount the disk, then detach it. Never seen the problem again.
Also make sure you did not recursively modify permissions for the /etc folder.
For example:
chmod -R 775 /etc
This will prevent you from logging back into the VM, even from the Web console and gcloud cli.
Instead, modify permissions on a more granular level e.g. /etc/nginx, etc.
I had the same problem and solved it by first connecting to the VM via browser SSH (from the "VM instances" web overview), which also fails, then choose the offered option of retrying without Cloud Identity-Aware Proxy which worked.
Afterwards all SSH-connections work again (both in browser and local shell).