I am trying to ssh into a ubuntu machine from my mac
but I am getting
setsockopt SO_KEEPALIVE: Invalid argument
write: Broken pipe
as soon as I type in ssh address
and changing ssh_config including TCPKeepAlive, ServerAliveInterval do not fix my issue.
Does anyone know what might be happening?
Server is running on ubuntu
I found that server and client are on different network
Therefore my machine was unable to find the target server machine of the given ip address.
(ya I know.. such failure should be more descriptive)
I hope this answer helps the other people experiencing similar issue
I saw this when the connection was dropped straight away (a firewall it seems).
Presumably it ends up calling setsockopt() on a socket that just closed.
Related
I am not able to connect to vulnserver using netcat.
I type this to connect
nc -nv 192.168.70.130 9999
(UNKNOWN) [192.168.70.130] 9999 (?) open
and it says this forever and doesn't happen anything
I have disabled real time protection, allowed in firewall and also VM is set to NAT mode.
Is there any other way to connect or what might be the possible issue.
I have also encountered the same issue. I thought it was my VM acting up, so I restarted the network access. I tried allowing vulnserver.exe through my windows firewall. Neither of them solved the issue. Finally, I disabled windows defender firewall and now it works like a charm. But before doing this, try to ping the windows machine from the linux box. If there's a response it should work. If there is no response however, try enabling file and printer sharing in windows. For more info, read this...https://superuser.com/questions/1137912/ping-to-windows-10-not-working-if-file-and-printer-sharing-is-turned-off
Immunity Debugger and vulnserver has to run as administrator, then Immunity Debugger can see vulnserver, otherwise Im..Deb can't see because of less privileged then vulnserver.
Also we need run Immunity Debugger
That's mean port 9999 has already been opened which is expected if you're already executed vulnserver
wolf#linux:~$ nc -nv 127.0.0.1 9999
(UNKNOWN) [127.0.0.1] 9999 (?) open
Welcome to Vulnerable Server! Enter HELP for help.
It also means that you've already connected to the server. Go ahead and type HELP to see more info.
Try to setup using different network mode such as internal or host-only mode.
I just had a similar issue - I'm not sure if you are using it in conjunction with Immunity Debugger like me (as part of an ethical hacking course) but I kept getting that situation because I forgot to hit 'play' on the debugger.
I am trying to connect into an EC2 instance (i am using a mac) which has a Security Group allowing all inbound traffic over ssh (port 22) but i'm unable to access. I'm having a little delay before getting an Operation timed out.
I already tried it over other devices such a raspberry pi and another macbook and the connection was successful.
I got access to the raspberry pi over ssh and tried the connection to my EC2 from the terminal; thought my ssh client or the port status could be the issue but after doing this i'm not really sure if this is the case.
This is the message i get when trying to connect:
ssh: connect to host x.x.x.x port 22: Operation timed out
One thing I noticed is that I used a different .pem file which is supposed to not work for that instance and the error was the same, it looks like my Mac cannot reach it.
Things already verified:
Security Group allowing traffic over port 22.
Instance rebooted/recreated.
DNS and Public IP address changed after instance reboot.
SSH connection successful over other devices.
SSH connection to other devices from this mac successful.
Firewall turned off.
DNS flushed.
Ping performed with success.
Any help is really appreciated it.
-- UPDATE --
This issue rose in my work machine. Got a different laptop due to other issues and problem fixed, looks like it might have been something related to ports or some sort of configuration. Thought it was a problem with AWS but now it's working fine. Sadly I couldn't debug enough to know what the exact issue was. Thanks to everyone who helped out!
It seems that you can remote by other devices and this issue is only still happening on your MAC. Try this on your MAC and try to remote again:
Flush your DNS
I don't know which Mac OS you are using so I put the link here: (https://help.dreamhost.com/hc/en-us/articles/214981288-Flushing-your-DNS-cache-in-Mac-OS-X-and-Linux)
If still cannot, you can try to open some protocol ports on that instances like:
ICMP, Echo Reply, ...
then try to reach by that protocol commands:
Ping, telnet, ...
If the result is cannot too, so it must be that your MAC cannot even reach to that instance network, then try to ensure that your MAC can reach the instance's network first.
I'm trying to login to docker from the Docker Quickstart Terminal but it doesn't work.
I always get an error saying: "Error response from daemon: Server Error: Post https://index.docker.io/v1/users/: dial tcp: i/o timeout"
I have been working with docker the last few days and was always able to login and push/pull stuff. The only thing different I can think of is that I'm currently on a different Wifi.
Any help is greatly appreciated, thanks.
Karsten
This is a known issue, and is probably related to VirtualBox; after switching networks, boot2docker/VirtualBox sometimes looses connectivity or uses incorrect DNS settings.
DNS confused when switching WiFi networks
Container connectivity lost after switching wireless networks
Manual restart required everytime network connectivity changes (contains some workarounds)
Docker Machine 0.5.3 adds two new options that may circumvent this;
--virtualbox-dns-proxy
--virtualbox-host-dns-resolver
After restarting the machine it worked again, don't know what caused the problem though...
I am using Putty to ssh into some of the servers that I work on. I am able to connect all others except the one. Although I was able to connect to it before. Whenever I try connecting to it, it always give me error:
Unable to open connection on myhost: Host does not exist
My firewall is off and I have even re-installed putty but that did not fix it. When I tried connecting to the same server using putty on some other windows system, I was able to do so. I searched regarding this on Internet but did not find much relevant.
I am running putty on Windows 7.
What can be the possible issue?
As I understand you have three computers involved. At the same time one connection is working and the other one fails. So we can exclude that the ssh daemon on your linux box is hanging.
In lack of knowing their real names I will call your computers linuxbox (this is the computer you want to ssh into), win7ok (that is the computer that you are able to ssh from using putty) and win7fail (that obviously is the computer you can't connect from).
Please do a tracert from both Win7 computers:
tracert linuxbox.your.domain
tracert linuxbox
Add the results to your question as it will help us find out what is happening.
Perhaps it is also a good idea to determine the ip address of the linuxbox from win7ok:
ping linuxbox
or
nslookup linuxbox
Then try to connect from win7fail by using the ip address of the target computer, perhaps it is only a DNS problem (which might be as nmap is failing too).
To make all of this easier to understand for us please provide the real names of the computers as you use them in putty.
For me the problem was with the Url of the reposity. Check remote URL. It must start with git#github.com, not https://.
I used nslookup and then used the ip address it gave me to connect and it worked
I had a similar problem with GitExtensions. The solution was to remove the https url and replace it with git#gitlab....
WRONG:
GOOD:
I just went through this. I have a Cisco VPN I need to use to get through to the Linux machine I wanted to login to and check.
No Putty session would get through using the machines name.
An nslookup on the windows machine yielded the correct address.
I too connected right in via the ip address.
I tried to Google the error and it failed, so I suspected the wireless.
Disconnected and reconnected my WiFi and all was good.
I did it fast enough that open connections stayed open.
And new connections refering to DNS names worked fine.
Seems like maybe some cached DNS addresses were stale.
Your DNS cache stores the locations (IP addresses) of web servers that contain web pages which you have recently viewed. If the location of the web server changes before the entry in your DNS cache updates, you can no longer access the site.
Following CLI command will do the trick:
ipconfig /flushdns
We have oracle 10g running on windows server 2003. A machine which runs an application using that database has as of a few weeks ago suddenly started having connectivity problems. Today we ran the automatic updates for windows server and the problem has only gotten worse. I realize this isn't enough information for anyone to diagnose the problem but perhaps you can get me pointed in the right direction with the following more specific scenario:
From this machine we can ping the server with absolutely no problem and, being physically close and on an intranet the return is very fast.
However, when we run tnsping I have seen 3 different results within a few minutes of each other.
tnsping returns just fine and in a reasonable amount of time
tnsping returns but only after a real long time (several seconds)
tnsping results in an ora-12560 protocol adapter error
At the same time I can tnsping the server from my machine with no problem.
Can anyone point me in the right direction?
I'd try to check the following:
do traceroute from the app server and from your machine check for anything abnormal
check tnsping from various other machine and try to identify a pattern
try a tcp/ip sniffer to see what is going on at both ends of the connection
get oracle support involved
To help eliminate DNS issues from the equation, specify the host's IP address in the TNSNAMES.ora file for your connection instead of a hostname. Are you using DHCP?
Have you eliminated hardware as the problem - have you tried a different NIC?
Before calling Oracle, I would create a trace file for a Fail case.
TNSPING.TRACE_LEVEL
Purpose
Use the parameter TNSPING.TRACE_LEVEL to turn TNSPING utility tracing on, at a specific level, or off.
Default
off
Values
* off: for no trace output
* user: for user trace information
* admin: for administration trace information
* support: for Oracle Support Services trace information
Example
TNSPING.TRACE_LEVEL=admin
Before involving oracle in this issue, get some help from your network administrator for the following test. First enable verbose logging on the database in the listener. Enable logging on the client via sqlnet. Go to the machine that is having trouble with tnsping, have the network administrator run a network tool to trace tcp packets from there. Perform the tnsping and see if what packet are being sent, what dns lookup are being made, what route is being taken. On the database see if the listener actually receives a ping from the client. If not then see where along the network to the database the problem is. Is it nameserver resolution? Is it a bad network cable, bad switch port, etc. Your network admin is your best friend for this problem. Do the same test via sqlplus with a simple connection and see what the client is logging.
Make sure there is no other machine on the network with the same IP address. A method would be unplug your machine from the network and see if you can still ping it. If you can then this is the problem.
If the server doesn't have a domain-name setup at a dns server, then add it's ip address and name to the host file on the server; this (the server not being able to find itself in dns) has been known to cause tns timeouts.