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)
4
  • 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 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 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 at 16:04
  • Thanks @user68186, I know, but I'll definitly try out the LAN method for now. – Stone Scone Feb 25 at 16:17
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.

4
  • 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 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. – user1179897 Feb 25 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 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. – user1179897 Feb 25 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.

1
  • I already changed the config so it was 24 and I still get this from my computer. port 24: Permission denied – Stone Scone Feb 25 at 16:02
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.

8
  • Ok I'll follow this to the tee and see if it works, if not I'm lost. :( – Stone Scone Feb 25 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 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 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 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 at 7:49
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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.