Trying to ssh a switch from Putty through a Router that works when doing if I connect first to the router via console cable and when there I SSH the switch then it works but when trying to do it from putty it says Network error: connection timeout
I just found the solutions. In windows Just went to the Inbounds rule for in Windows Defender Firewall with Advanced Security and then set inbounds and outbounds rules allowing TCP port and another rule for Allowing another subnet witch the one you want to SSH.
On Mac Using terminal type sudo nano /etc/ssh/ssh_config then Un-comment the line: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
Press Ctrl + X. Press Enter to save and exit.
Related
I need to open port#42474 on my Windows 10 system for penetration testing purposes.
I added it to the inbound list of my Windows Defender Firewall (both TCP and UDP protocol), and it is enabled.
However, whenever I am trying to ping this port on my machine using telnet it is throwing an error as
Connecting To localhost...Could not open connection to the host, on port 42474: Connect failed
I am able to use telnet to ping other sites such as google.com. But not this port on my machine. Below is the command I am running to test the port and the error:
Port
Telnet error
telnet localhost 42474
Do I need to do anything else to open port#42474?
How do I verify if this port is available for use?
TCP ports are bi-directional, so check these tips:
Verify your service on this port is running: netstat -a
Be sure your firewall isn't blocking (try to deactivate it: if it works well, your rule isn't correct)
Search for your service log: maybe,
it receive information, but it's not able to reply. I recommend you to use PuTTY or Kitty (which is my favorite, because it's portable without registry keys modification), and try to connect on this port.
If you need a tool that able to listen on the port, see this post: Utility to open TCP port to listen state and netcat.
You can use the Python programming language. More specifically, the socket library:
import socket
hote = "localhost"
port = 4444
socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
socket.connect((hote, port))
print "Connection on {}".format(port)
socket.send(u"Hey my name is Abdx!")
print "Close"
socket.close()
I have Windows 10 as host with a Manjaro installation as Guest on Virtualbox.
I have set a Debian server on another house with ssh installed. I have setup a dyndns on Debian's network so I can access it remotely.
For example..
From address 12.34.56.78 I ssh to foo.dyndns.org:1234. This port redirects me to 192.168.1.5:22 always as this is my Debian machine and the connection is established. I am able to do this from Windows 10 as well as my android and any other device in 12.34.56.78 or by 3G.
But..
When I try to do this
$ ssh foo.dyndns.org:1234
from the Manjaro Guest in Virtualbox I get the following error:
ssh: Could not resolve hostname foo.dyndns.org:1234: Name or service not known
So I did ifconfig and I saw my inet address was 10.0.2.15. I changed virtualbox's network adapter from NAT to Bridged so I can get a lan ip and I got the host's ip, 192.168.2.4. So I gave it another try and still didn't work.
Also, if i try to connect from vm to server while I'm in the same network
$ ssh user#192.168.2.5:22
it works. In this case virtualbox's network adapter was NAT.
This command works if I try from my android (connectbot).
I can connect the same way from PuTTY from Windows.
So my questions are:
Can it be done?
If so, how? (and why?)
Can a VBox Guest get lan ip that's not the same as the host's?
Is there any more information I should provide?
I have searched for a couple of days in here and on google and all I found where solutions on how someone can ssh INTO a vm. No one (from what I saw) asked the opposite.
Checking manual page for ssh reveals the format of command-line options:
ssh [...] [-p port] [...] [user#]hostnamessh
This simply describes, that you need to change
ssh foo.dyndns.org:1234
to
ssh -p 1234 foo.dyndns.org
if the domain resolves correctly to the ip address.
My last update on Fedora 22 Workstation simply broke my OS, it won't log in, crashing before it.
I want to download and install some new files to fix it. I'm plugging ethernet cable, but I can't connect to Internet.
In Gnome it's like wifi, just clicking on Enable or something like that
How can I enable ethernet connection in CLI mode (ctrl+alt+f2)?
The up flag with interface name (eth0) enables a network interface. For example, the following command will activates the eth0 network interface.
sudo ip link set eth0 up
I'm trying to use NETSH PORTPROXY command to forward packets sent to my XP PC (IP 192.168.0.10) on port 8001 to port 80 (I've a XAMPP Apache server listening to port 80).
I issued the following:
netsh interface portproxy add v4tov4 listenport=8001 listenaddress=192.168.0.10 connectport=80 connectaddress=192.168.0.10
Show all confirms that everything is configured correctly:
netsh interface portproxy show all
Listen on IPv4: Connect to IPv4:
Address Port Address Port
--------------- ---------- --------------- ----------
192.168.0.10 8001 192.168.0.10 80
However, I'm not able to access apache website from http://localhost:8001. I'm able to access through the direct port at http://localhost as shown below.
Additionally, I've also tried the following:
1. Access the Apache website from a remote PC using the link: http://192.168.0.10:8001. Firewall turned off.
2. Changing listenaddress and connectaddress to 127.0.0.1.
Without further information, I can't find a way to resolve the problem. Is there a way to debug NETSH PORTPROXY?
Note: By the way, if you're wondering why I am doing this, I actually want to map remote MySQL client connections from a custom port to the default MySQL Server port 3306.
I managed to get it to work by issuing:
netsh interface ipv6 install
Also, for my purpose, it is not required to set listenaddress and better to set connectaddress=127.0.0.1, e.g.
netsh interface portproxy add v4tov4 listenport=8001 connectport=80 connectaddress=127.0.0.1
If netsh's port proxying is not working as expected, then you should verify the followings, preferably in that order:
Make sure the port proxy is properly configured
Start or restart the related Windows service
Ensure support for IPv6 is installed
Make sure the port is not blocked by a firewall
Make sure the port proxy is properly configured
This might seems to be trivial, but just in case, take the time to review your configuration before you go any further.
From either a command prompt or PowerShell prompt, run the following command:
netsh interface portproxy show all
The result should look something like this:
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- ---------- --------------- ----------
24.12.12.24 3306 192.168.0.100 3306
24.12.12.24 8080 192.168.0.100 80
Carefully review those settings. Make sure that you can indeed connect to the addresses on the right side of that list, from the local computer. For example, can you locally open a web browser and reach 192.168.0.100:80? If the protocol is not HTTP, then use telnet: telnet 192.168.0.100 3306 (see here for how to install the Telnet client on Windows).
Then, are the values on the left side correct? Is the IP address valid for your machine? Is that the port number you are trying to connect to, from the external machine?
Start or restart the related Windows service
On latest versions of Windows, netsh's port proxying is handled by a Windows service named "IP Helper" or "iphlpsvc". Proxying will obviously not work if that service is stopped. I have also faced situations that turned out to be resolved by restarting that service.
To do that in latest versions of Windows:
Open the Task manager, then go to the Services tab.
In the "Name" column, find the service named either "iphlpsvc" or "IP Helper".
Right click on that service, then select Restart. If restart is not available, then the service is probably stopped, and actually has to be started, so select Start.
On previous versions of Windows, look for Services in Administrative Tools, inside the Control Panel.
Ensure support for IPv6 is installed (older releases of Windows only)
On earlier versions of Windows (that is Windows XP, for sure, upto some early releases of Windows 10, apparently, though this is not clear), netsh's port proxying feature (including for IPv4-to-IPv4 proxys) was actually handled by a DLL (IPV6MON.DLL) that was only loaded if IPV6 protocol support was enabled. Therefore, on these versions, support for the IPv6 protocol is required in order to enable netsh's port proxying (see Microsoft's support article here).
From either a command prompt or PowerShell prompt, run the following command:
netsh interface ipv6 install
If you get an error indicating that command interface ipv6 install was not found, then it means that you are using a recent release of Windows, in which netsh's IPv6 support is implicit and cannot be disabled.
Make sure the port is not blocked by a firewall
A local firewall may potentially block the port even before they reach the IP Helper service. To make validate this hypothesis, temporarily disable any local firewall (including Windows' native firewall), then retest. If that works, then simply add a port exclusion to your firewall configuration.
I have the problem with you. I have solve it just now. There is a Windows Service named "IP Helper" that supplies the funcions tunnel connections. You should ensure it has been started.
You must Run Command.exe as Administrator first, by right-clicking the Command Prompt icon and choosing Run as Administrator. You will asked to confirm.
Paste your netsh Command in the command.exe window and press Enter.
If no error message is shown, the command worked.
In your web browser go to http://your-up:8001 to see it works.
The Windows Event Log might have information to help find the cause of a failure.
I have the Xming X Window Server installed on a laptop running Windows XP to connect to some UNIX development servers.
It works fine when I connect directly to the company network in the office. However, it does not work when I connect to the network remotely over a VPN.
When I start Xming when connected remotely none of my terminal Windows are displayed.
I think it may have something to do with the DISPLAY environment variable not being set correctly to the IP address of the laptop when it is connected.
I've noticed that when I do an ipconfig whilst connected remotely that my laptop has two IP addresses, the one assigned to it from the company network and the local IP address I've set up for it on my "local network" from my modem/router.
Are there some configuration changes I need to make in Xming to support its use through the VPN?
Chances are it's either X authentication, the X server binding to an interface, or your DISPLAY variable. I don't use Xming myself but there are some general phenomenon to check for. One test you can do to manually verify the DISPLAY variable is correct is:
Start your VPN. Run ipconfig to be sure you have the two IP addresses you mentioned (your local IP and your VPN IP).
Start Xming. Run 'netstat -n' to see how it's binding to the interface. You should see something that either says localIP:6000 or VPNIP:6000. It may not be 6000 but chances are it will be something like that. If there's no VPNIP:6000 it may be binding only to your localIP or even 127.0.0.1. That will probably not work over the VPN. Check if there are some Xming settings to make it bind to other or all interfaces.
If you see VPNIP:6000 or something similar, take note of what it says and remote shell into your UNIX host (hopefully something like ssh, if not whatever you have to get a text terminal).
On the UNIX terminal type 'echo $DISPLAY'. If there is nothing displayed try 'export DISPLAY=VPNIP:0.0' where VPNIP is your VPN IP address and 0.0 is the port you saw in step 3 minus 6000 with .0 at the end (i.e. 6000 = 0.0, 6010 = 10.0).
On the UNIX host run something like 'xclock' or 'xterm' to see if it runs. The error message should be informative. It will tell you that it either couldn't connect to the host (a connectivity problem) or authentication failed (you'll need to coordinate Xauth on your host and local machine or Xhosts on your local machine).
Opening Xhosts (with + for all hosts or something similar) isn't too bad if you have a locally protected network and you're going over a VPN. Hopefully this will get you started tracking down the problem. Another option that is often useful as it works over a VPN or simple ssh connectivity is ssh tunneling or X11 forwarding over ssh. This simulates connectivity to the X server on your local box by redirecting a port on your UNIX host to the local port on your X server box. Your display will typically be something like localhost:10.0 for the local 6010 port.
X can be ornery to set up but it usually works great once you get the hang of it.
Thanks for the help #Stephen and #Greg Castle, using it I've managed to resolve my problem.
To provide a basic guide for others (from scratch):
Using Xwindows on a Windows PC to connect to a UNIX server over a VPN
What you need to start with:
The Putty Telnet/SSH client, download putty.exe (for free) from:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
The Xming X server, download Xming (for free) from:
http://sourceforge.net/project/showfiles.php?group_id=156984
What to do:
Install both of the above on your Windows PC
From the Windows start menu select: Programs -> Xming -> Xming
Run the Putty.exe program in the location you downloaded it to
In the PuTTY configuration screen do the following:
Set the IP address to be the IP address of your UNIX server
Select the SSH Protocol radio-button
Click the SSH : Tunnels category in the left hand pane of the configuration screen
Click the Enable X11 forwarding check-box
Click the Open button
Logon as usual to your UNIX server
Check the directory containing the X windows utilities are in your path, e.g. /usr/X/bin on Solaris
Run your X Windows commands in your putty window and they will spawn new windows on your desktop
I got Xming and PuTTY working with Cisco VPN by replacing the PuTTY configuration in Connection > SSH > X11 > X display location, localhost:0.0, with VPNIP:0.0. VPNIP can be seen in the VPN statistics client address information by left-clicking on the VPN client lock icon and choose Statistics....
I didn't muck with the DISPLAY environment variable on the remote host. But, like others, I modified sshd_config on the remote host, adding these lines:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AddressFamily inet
I have got same issue with Xming and Putty on a Windows 10 machine and found the solution here. I have overcome the problem just adding Tunnels to the session in PuTTY. But first you need to check;
sshd_config under /etc/ssh (in rhel7).
Enable X11 forwarding at left navigation pane Connections > SSH > X11
iptables under /etc/sysconfig/ (in rhel7). If ports are blocked and you have permission, open the ports for 6000. I have added below line before first reject line to open ports from 6000 to 6003. It may be more specific in your case.
-A INPUT -m state --state NEW -m tcp -p tcp -m multiport --dports 5901:5903,6000:6003 -j ACCEPT
Then;
Go to Connections > SSH > Tunnels in PuTTY and add a tunnel with Source Port=6000, Destination=127.0.0.1:6000 and check Remote radio button. Then click the Add button.
After your SSH connection established, set your DISPLAY variable manually with the command below:
export DISPLAY=127.0.0.1:0.0
More Information;
If you set DISPLAY variable as 127.0.0.1:1.0, it will communicate over 6001 port . In this case, you need to add another tunnel for port number 6001.
I had nothing but problems with Xming. When I could get it to work it was extremely slow (this is over a VPN). IMO X is not designed to run over slow connections its too chatty. And by slow connection I mean anything less then a LAN connection.
My solution was to use x11vnc. It lets you access your existing X11 session through VNC. I just ssh into my box through the VPN and launch:
$ x11vnc -display :0
That way I can access everything I had opened during the day. Then when I don't I just exit (Ctrl-C) in the terminal to close x11vnc.
Haven't have the exact problem, but I think you need to look at the xhost and make sure that the vpn remote is allowed to send data to the x server.
This link might help:
http://www.straightrunning.com/XmingNotes/trouble.php
You may have better luck doing X11 Forwarding through SSH rather than fiddling with your DISPLAY variable directly. X11 Forwarding with SSH is secure and uses the existing SSH connection to tunnel, so working through a VPN should be no problem.
Fortunately this is fairly straightforward with Xming. If you open your connection from within Xming (e.g. the plink option) I believe it sets up X11 forwarding by default. If you connect using another SSH client (e.g. PuTTY) then you simply need to enable X11 forwarding (e.g. 'ssh -X user#host'). In PuTTY the option is under Connection -> SSH -> X11 -> click on 'Enable X11 Forwarding'.
Make sure Xming is running in the background on your laptop and do the standard X test, 'xclock'. If you get a message like 'X connection to localhost:19.0 broken (explicit kill or server shutdown).' then Xming is most likely not running.
Also, make sure you're not explicitly setting your DISPLAY variable in any startup scripts; SSH will set up an alias (something like localhost:10 or in the example above localhost:19) for the X11 tunnel and automatically set DISPLAY to that value. Overwriting DISPLAY will obviously mean you will no longer be pointing to the correct X11 tunnel. The flip side of this is that other terminals that don't have SSH X11 Forwarding set can use the same DISPLAY value and take advantage of the tunnel.
I tend to prefer the PuTTY option but several of my coworkers use plink from within Xming.
putty + XMing - I had to set the DISPLAY environment variable manually to get things running (alongside with checking "Enable X11 forwarding" in putty - Connection/SSH/X11)
export DISPLAY=0:10.0
(it was set to "localhost:10.0", which did not work)
You have to add the Linux machine's DNS name(s) and IP address to the C:\Program Files\xming\X0.hosts file. File should contain:
LinuxBox.mydomain.com
LinuxBox
192.168.1.25
This is the right answer: https://www.slackwiki.com/X_Windows:_Remote_X_to_Windows_with_Xming