0

I own a refurbished HP Proliant DL380 G7, for a small project I've been working on (It’s the first time using a server and setting it up). But after I set up Ubuntu 20.04 on it, the first thing I did was check if SSH worked. I went into the config and changed the port, forwarded the ports I was using. I pinged on multiple ports and IP’s in and out the system, all of them were sending packages, but still had 100% packet loss (I did switch off the ufw firewall for the port I was using). So there may be a possibility that the router was causing this, and so I went through all the settings to see if there was a possibility that some kind of firewall was stopping my SSH request, I checked it all and it didn’t work. And so that’s what got me here. To ask if there was something that could stop my request not going through due to the router or the internet service. Here’s a list of thing I already tried (shortening what I already said with some extra stuff):

  • Changing SSH port through config.
  • Both triggering the port, and using Virtual Server to forward it.
  • I put my server IP on Address Reservation to make it static.
  • Disabled the firewall stopping it working.
  • Tried multiple applications on my computer including: MobaXterm, PuTTY, and Windows Terminal Preview with a copy of Ubuntu 20.04 on it so I can use it as an Ubuntu terminal to SSH from.
  • I have both my computer and my server plugged in via Ethernet.
  • Uninstalling SSH on the server and then reinstalling it manually.

I've tried diffrent things that use ports or internet connections that didn't work including:

  • FTP
  • Mumble server
  • Minecraft server

I just want to ask if there is some kind of internet regulation that is blocking traffic from my server, port, or if you could give me some advice on what to do next, that would be great.

Sorry that I couldn't give any exact commands I've used. Whenever I try to connect via SSH to my server it says: Permission denied. And when I used the iptable command sudo iptables -S I get:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

I also tried

sudo losf -nP -iTCP -sTCP:LISTEN | grep 24

And got:

SSHD 905 root 3u IPv4 507 0t0 TCP *:24 (LISTEN)
SSHD 905 root 4u IPv4 509 0t0 TCP *:24 (LISTEN)
muru
  • 197,895
  • 55
  • 485
  • 740
  • Where are you trying to get to this from? Within your network behind the router or from outside? If from Outside you have to forward your ports from your router to your computer. – Thomas Ward Feb 25 '21 at 14:08
  • @ThomasWard So if I got this right, I have to forward the port to the computer that I'm trying to SSH to the server from or both? And to answer the question I am doing it from inside my network for now, but I want to be able to do it from outside later. – Stone Scone Feb 25 '21 at 15:15
  • If both your computer and the server are in the same LAN you don't need any port forwarding at the router level. Is your server running inside a virtual machine, or running on a real (bare metal) machine? Before you change port, make sure ssh works. See Connect two computers with SSH in a home LAN on how to make sure ssh works with the default port. – user68186 Feb 25 '21 at 16:04
  • Thanks @user68186, I know, but I'll definitly try out the LAN method for now. – Stone Scone Feb 25 '21 at 16:17

4 Answers4

0

Every time time I see the problems with ssh it is I changed the port in the description. My standard pasted response next.

Now I see the security through obscurity yet again with that port used. If this machine is outside of the local network trying this port moving technique for security is useless. The machines that scan the internet looking for open ports do not care if you have changed it. They go through every port in existence on every IP in existence, god only knows how many times a day. They will find your service with its changed listening port without any trouble at all. Or do you think they do not know there are other ports these services can run on? They are that stupid, right. My pasted blurb for just this circumstance.

The last one responded "but we see less attempts by doing it", I said I modify the statement then, only some are not that stupid, but I stand by it. The default configuration just works. Do the failtoban that is done and keep the no password login setting enabled and on, only allowing the keys and they will not be getting into your machine, unless you somehow leak the key(s) used. In short the solution is leave it alone and allow it to function as intended.

  • 1
    This doesn't really answer their question - this is something that you should state in comments not as an answer. Or save as a post on a blog or other site. – Thomas Ward Feb 25 '21 at 15:53
  • It certainly does answer the question it tells them to do it the way it was intended to be done and it will work without fail. And for a comment you put an opinion, nothing to add to the solution.. The entire problem is these people who think they know better than the designers/programmers who do this the put in place with a sensible secure configuration then the blog people get on their, change the port that is the answer. Not leave it alone and secure like it is, edit that file I know better than them. –  Feb 25 '21 at 15:56
  • @HappyTux In my question I stated that I have already tried to uninstall and reinstall it manually and of course I tried it with its basic settings but it still didn't work. So I think it's more of a network problem, because packages are sent from my server when I pinged, but are not being picked up from any other machine in my system. – Stone Scone Feb 25 '21 at 16:14
  • You definitely have messed up settings then, you need to check everything in the chain of the connections does what it is supposed to. The router actually routing the packets, the machines are the cables connected correctly on both ends at it and the next place they go into if switches are involved. If switches are the smart so called managed ones and not just the dumb actual switch, is the routeing being done in them correctly. All them things, doing a netstat -tulpn to confirm your services run on the ports you think they are, are listening for the connections. A few ideas to check on. –  Feb 25 '21 at 16:22
0

Make sure you give SSH the proper port - you indicate you changed the SSH port so you need to tell SSH the port to use.

In Ubuntu, you would tell the SSH client the port by ssh -p PORT user@remoteip and then that would connect on the port you specify (replace PORT with the actual port).

How you do this on other SSH clients is a bit beyond the scope - but make sure you're using the right post.

Thomas Ward
  • 74,764
0

There are a few things you need to setup at minimum to have SSH working, and this configuration then changes down the line depending on what you wanna do.

Lets assume for everything right now, that you are on your own internal network and are keeping all the values default, for now until we know this works. then we will continue with an advanced config.

For now, no port forwarding is needed, that is the final step. For now we only need to know the service is enabled, what IP the remote machine has, and on what port the ssh-server daemon listening, and if the remote firewall is blocking incoming requests for SSH.

step 1 -install and enable the openSSH-server service (on the remote machine)

step 2-Disable firewall (on the remote machine)

If you're not 100% sure if you disabled the remote firewall or not, do:

sudo service ufw status

there you will see its status, when active, let's disable it for now.

sudo service ufw disable

If you have just installed openssh-server and you didn't change the config, the default port is set to 22. If you have changed the SSH config to listen on another port, restarting ssh-server service is required. The spawned SSH process is still cached in memory and will only start serving on a different port the moment a new SSH-server daemon process is spawned.

As such, do:

sudo service ssh restart

now move over to the client PC. Ping the remote machine. That is step one for basic connectivity, but ping is a bad tool for testing protocol or service issues. They exist on different OSI layers. now open your ssh client, this can be putty or something else, or just a terminal window in linux works fine too.

After doing above steps, this should really work to connect, if not, repeat previous steps or ask more questions.

If you kept things default, and its working, now would be the time to switch over the ssh port if desired. so for example let's say you changed the port from 22, to 2200 in the ssh-server config on remote machine, the next step would be to enable the firewall on remote machine, but this time add some rules after. As soon as the rules are loaded-in and the firewall is enabled, for good measure restart ufw service and ssh service once more, then try to connect.

If you changed the SSH port from 22 to 2200, you would have to

ALLOW a rule for TCP rule for PORT 2200 from ANY adress

it will add the same rule for ipv6 automatically.

if you are comfortable turning off UFW on remote machine for now that is fine too.

Now that SSH is working on your local network, you can start configuring remote access. This is different for each router but about the same process.

Find in the menu of your modem/router a category for port forwarding, usually under firewall/internet or IP configuration. when you found port forwarding, what you wanna do is forward an external port (this can be any port, comes down to personal preference and security) for example a random port, 8422. This would be the remote port that we connect to whenever we are outside. We forward this port, to the internal port 2200 that we have set on the machine.

so instead of internal IP and port, now we use the external IP adress, and the external port. this is now configured to tunnel directly to the 2200 port on internal network, and should be reachable. if this last step gives you issues, restart modem/router and remote server completely. if that still doens't work, but the internal ssh does, you can be sure the configuration is not yet correct. Permission denied error sounds like you're trying to access SSH on the wrong port. so you can reach the machine, but the port that is requested for SSH is not serving that, so the permission is denied.

Hope this helped.

  • Ok I'll follow this to the tee and see if it works, if not I'm lost. :( – Stone Scone Feb 25 '21 at 16:25
  • You can always hit me back with another question, I dont mind helping you. No problem, just take it step by step. verify ssh on internal network first with default settings, then move on. good luck! – DruidicBearClan Feb 25 '21 at 16:27
  • What does it mean if when I ping the server from my client it says "ping: sendmsg: Invalid argument" and has transmitted packets but has 100% packet loss. – Stone Scone Feb 25 '21 at 18:01
  • that sounds like a weird problem. I am reading things about ipv6, and about a bug in ping but that's on an older ubuntu version. Start basic network troubleshooting: Can both machines ping the default gateway on the network? Are u using IP adress for ping or pinging to the hostnames? start with only pinging IP adresses and not the hostnames. see if you ipv6 config is turned off, or that its properly configured on all nodes. that means router>all other devices in the chain. – DruidicBearClan Feb 25 '21 at 23:14
  • This is intregeing my server can ping my gateway but my computer can't, even though it's connected directly, and i've been using the internet on it for the past couple months. – Stone Scone Feb 26 '21 at 07:49
  • And when I went into my default gateway to the router config screen I pinged the server and the computer from there and both of them returned as: Request timed out! – Stone Scone Feb 26 '21 at 08:14
  • Sounds like a much broader network issue that you have to resolve before you continue your SSH journey. Usually when I start running into issues like this, I go back to the basics. Basically I would reset my modem/router to factory defaults, clear the IP config of all clients and servers. First set your desired subnets and ranges for DHCP etc in the modem/router, let the servers and clients obtain IP address through DHCP first, when that works then set static IP configuration. Best way is BOTH the server have static IP on their own interface is well as static from the router, both same IP ofc – DruidicBearClan Feb 26 '21 at 11:24
  • Before you do the static IP config for the devices but after all the resets, you should test the ping with the IP's obtained from DHCP first, if those pings are working, move on and set static ones. I would suggest rebooting all your devices again completely after settings new IP's, the modem/router also. then try to ping those. once you have restored normal network connectivity probably ssh will be working too. The restarts are important because of incorrect mac adress table or arp caching., it sounds like this is the problem. – DruidicBearClan Feb 26 '21 at 11:26
0

One of my ethernet cables wasn't being registered by the server so, I swapped out ethernet cables, and I realized that my Windows computer wasn't connected to the LAN even though it was pluged in to the correct router. So I used a laptop and it allowed me to connect to the server no problem. Thanks for trying to help me!