SOLVED - SSH simply will not work !!! Losing my mind ...

[LinWinux]

Hi everyone. Geez, I can't believe that I'm even having to post this, but after 4 days of inexplicable frustration nothing else comes to mind. This here used to be my link of preference for information regarding sharing data between two Linux *buntu machines:
viewtopic.php?f=150&t=214600

EDIT: Just scroll to the bottom of the page if this first post here applies to you !!!

We have a Linux Mint XFCE server machine in our livingroom to which we grant access from our upstairs client machine. The upstairs machine is also Linux Mint XFCE. This used to take place via ssh along with an advanced firewall configuration on the server which required the client's IP and the host's password from the client machine, in order to gain access to the server via our preferred (Caja) file manager.
This worked great on Linux Mint 17.2 XFCE as well as 17.3 XFCE after we upgraded.

On August 2nd Mint 18 XFCE was officially released. That same evening I downloaded and installed a clean fresh copy of Mint 18 XFCE on both of the machines that were using SSH previously. This was done onto formatted EXT4 partitions where none of the computer hardware had been changed. Literally everything was the same as before, with exception to the fact that the old Mint 17.3 was wiped out completely, to be replaced with Mint 18 XFCE.

Our connections are hardwired and not wifi. Following the instructions from the link above, I installed SSH Server & Client as required. I had no problem with the firewall settings and I know for a fact that the client's IP in the server's firewall setting is correct. I have double triple quadruple etc etc etc checked everything. Day before yesterday I got so frustrated between trying to set up SSH while also looking at alternatives such as Samba and NFS, that I somehow bricked the server system. So I re-installed Mint 18 XFCE again from scratch on the server machine and started over.
But no matter what I do, I CANNOT GET SSH TO WORK ANY MORE !!!

There are no error messages ever !!! openssh server is installed as required. openssh client is installed as required. Firewall has advanced setting, requiring client's IP for access. Port number rermained unchanged since those are 22 by default. After configuring the firewall, the server machine gets rebooted. Then upstairs, I reboot the client machine for a clean login, followed by opening the file manager and looking for a connection to the server. So far so good, still no errors.
Server Settings: IP number of the server downstairs
Server Port: 22 (by default)
Remote Folder: /
Client Settings: username of the client machine
Password: password of the server machine (have tried both between reboots)
Tick, checkbox for remember password
Bookmark Name: LIVINGROOM
Connect ...

That's where an error comes up ... please check your user information ... with an exclamation mark in the password field.

I know for a fact that the server's password is correct.
I've even tested sudo terminal commands on both machines to make sure all was well.
But it doesn't even matter if I use the server's or the client's password ...
because I receive the same error either way, then permission denied after 4 attempts.

This is driving me up a friggen' wall.
Four days, and I have no idea what I'm doing wrong.
Today I attempted the same thing with two Xubuntu machines ...
I did not use a firewall at all, just to see what would happen ... identical problem !!!

HELP !!!

.

[altair4]

I went through the same steps to set up an SSH server on a new install of Mint18 XFCE:

Installed ssh

Code: Select all

sudo apt install ssh

Allowed ssh trough the firewall:

Code: Select all

sudo ufw allow OpenSSH

And connected to the server from a Xubuntu 14.04 client:

SSH-Connect4.png

Now since this was the first time I connected I got one of these scary looking things but I just selected Log In Anyway:

SSH-Connect2.png

Here's my guess. You have an old key pointing to the same machine with the same host name or ip address but with the old operating system and therefore the old key. You need to start the verification process over again but first you must remove the old key.

Rename the key file on the client system and try to connect again. Note: this would be on the client system:

Code: Select all

mv $HOME/.ssh/known_hosts $HOME/.ssh/known_hosts.bak

EDIT: Or is you have many keys set up on that client for other boxes just remove the key for the Mint18 box. For example:

Code: Select all

ssh-keygen -R vmint18xfce.local

[LinWinux]

Thanks a bunch. Won't have time to deal with this anymore until tomorrow, but I'll report back. YES, I managed to get that "scary looking" window too, followed by clicking on ignore, but that didn't help. I was thinking something similar, old data trying to push through somehow. That's why I installed the system from scratch. I'll be back tomorrow sometime ...

.

[LinWinux]

Nope, still nothing working as far as ssh goes ...

Part of the confusion after trying so many logins and password switcheroos between the machines, is the uncertainty that begins which makes me feel as if I can't even be certain anymore where which passwords are required. The firewall for example ... has "TO" and "FROM" ... without any explanation which machine is which. Not in the help either, if you click on help. My thinking was always ACCESS FROM the client machine INTO the server.
Although, it could also be PERMITTED ACCESS FROM the server, GIVEN TO the client machine.
Nothing anywhere is written to clarify what "FROM" and "TO" specifically means ???
Using passwords that are known to be 100% correct, also makes this very very confusing.

Another confusing thing is that after following the above instructions for the server, the firewall now shows 3 rules where before I only had one. The other two came about after including the first two commands for the server machine. So does this mean that the original rule which I had in the firewall settings should have been deleted? Also, are those rules supposed to show up in a certain order? I'm asking because the GUI for the firewall states that the new setting/change will follow the previous rule.
Before, my own single rule was at the top of the list. Now there's three ...

Then the commands on the client machine ... no problem with the first one ... which I can actually just delete/move/rename the files with the file manager just as well as with the console. But, regardless how it's done ...
The second command for the client did not work at all.
Received an error when I tried ... ssh-keygen -R vmint18xfce.local

Another issue is the request for a keyring password. I never intentionally set that up when I install Linux Mint. If I'm ever asked to assign a key then I always use the same password as for the rest of the system in order to keep things simple. So after rebooting the server downstairs and making sure everything was fine while noticing the three firewall rules, I then went upstairs to the client. Made sure that the known_hosts was backed up, and the original one deleted (so only the backup existed), then received the error on the second command ... ssh-keygen -R vmint18xfce.local

No problem though, just went ahead and rebooted the client anyway. After the restart I went ahead and tried to access the server via the file manager.

Connect to server: UPPER PORTION = Server machine IP with port 22 and SSH access to /

Client/User: LOWER HALF = username of client - password of server machine for access - bookmark for file manager

Yup, got the scary window, server or IP unknown, log in anyway ... YES.
Asked for the key pass which was required on the client, did that.
Asked for the access password ... which should have been the password to the server downstairs.
Was then asked to confirm the information for some odd reason, so I entered the same password again.
Then received the failure message ... access denied (after two attempts).

Then removed both of the known_hosts as well as the backup file and deleted them altogether from the client.
Rebooted the client machine, followed by opening the file manager.
Clicked on my existing network shortcut for access to the server ...
Was asked for the password again (to the server presumably) ...
Was asked to confirm ... followed by access denied.
This is the game that I've been playing for the past week now.

Sure, I've tried it reversed too ... reboots and then attempting access with the client machine password. This should not have worked, and it didn't.

The thing that's so utterly frustrating in all of this, is that I know that the passwords are correct and they're all working on both machines like they're supposed to. The only thing that simply won't work no matter what I do, is the damn ssh access from the client to the server. Nuts, nuts, nuts ...

.

[altair4]

I'm not sure I followed all that but my suggestion is to disable the firewall on both server and client:

Code: Select all

sudo ufw disable

And try it again.

If you now can access the server you will know your problem is with the firewall.

If you cannot then consider using Xubuntu.

Side note:

The second command for the client did not work at all.
Received an error when I tried ... ssh-keygen -R vmint18xfce.local

Unless the host name of your Mint server is vmint18xfce,
You are allowing mdns through your firewall through port 5353 so that the .local works,
And most importantly you originally accessed the server that way,
that command will never work.

It was an example of what I would have to do on my client machine to remove the key to my Mint ssh server.

[Uranium]

I don't know if you guys are getting side tracked, I assume from altair4's explanation he is trying to ssh from the GUI. Open up a console and

Code: Select all

~$ ssh X.X.X.X

From client to the server assuming local ip scheme (192.168.X.X). I do this all the time with my boxes. And he is correct you have to blow out hidden directory (known_hosts in ~/.ssh).

you could always try ssh (username)@192.168.0.104 see if that lets you from a basic level.

ssh is actually secure shell but can server as a file transfer through scp. Have you tried mounting as NFS mounts and setting up an NFS share for your client server?

Alternately, you could nmap or ping using hostname/ip from client to the server to make sure that traffic isn't blocked somewhere/somehow.

You could always check /etc/sshd_config file and post here (on the server that is). Make sure everything is good to go.

I am a Linux Systems Administrator so I figured I could lend a hand.

[LinWinux]

Geeez, I'm so disgusted about this, I could just spit. My wife is P.O. at me because she can't go upstairs to access stuff from there, and I'm about ready to blow up the dang server machine that we have downstairs. Most frustrating of all is the fact that there isn't some literally "no brainer" point "n" click way of setting this up permanently for us Windows users who learned nothing but point "n" click ... for 18 years (in my case).
We no longer use Windows on any of our machines!

No progress at all. I opened up the firewall on the server and removed my rule which then left in place the two rules that were automatically generated from the commands that were suggested to me by altair4. Rebooted the server ...
Went upstairs to the client, then deleted the contents of .ssh
Rebooted the client ...

Attempted access to the server ... entered required ssh info plus user name of the upstairs machine plus password to the server that's located downstairs. Same as before ... scary warning window ... ignore ... enter password to server from client machine ... ACCESS DENIED.

Alright, back downstairs to the server we go ... screw it, I'm deleting the firewall rules and then I'm removing the firewall app altogether. There, done that, now I'm rebooting the server. Back upstairs to the client we go ...
Remove the non-working bookmark from the file manager ...
Reboot the client for the heck of it ...
Attempt new server access via the file manager ...
Of course same as before ... ACCESS DENIED.

We've never used firewalls in the past, until we started working on two machines in our home with ssh. And then we only ran the firewall on our server ... NOT on any other machines. We've been using Linux Mint for years and initially that's how we had the network working too, just a couple of weeks ago. But because we ran into this SSH problem after two of our machines (not the server) were changed to Xubuntu 16, we then decided to go back to what we already knew to be working, by making another switch to Linux Mint. Only exception is that this time we didn't go back to Linux Mint 17.3 XFCE, but went right ahead to the latest stable long term release, Linux Mint 18 XFCE.

Last week the server machine had a new OS installed as well ... Also Mint 18 XFCE (out of sheer frustration & exasperation). Since our SSH problems started immediately, I'm having a bit of a hard time believing that there are some data/file remnants which are causing the problems. I installed a fresh new Xubuntu on three of our machines (but not the server) which is when the trouble initially started. Because of these problems, I then installed Mint 18 XFCE on the client machine. When that didn't resolve our SSH issues, I went ahead and installed Mint 18 XFCE on the server as well. Since the problem has been ongoing, I don't believe that any of the OS on any of the machines are to blame ...

We do not use WiFi. All of our computers (four of them) are hard wired with gigabit connections and our router is very secure. We're also using commercial VPN services in our home, but we've had those running for over a year without a problem ... same router as well ... so no hardware changes anywhere.

Is it possible that something changed on our router during an automated firmware update?

@Uranium
Thanks for your input. I don't know jack about home networking and never in my wildest dreams thought that something working ... could get this screwed up. With Windows by my side for over 18 years, I'm in real need of some step by step by step hand holding. I have no problem with the console, but I can only follow, since I don't actually understand anything that I'm doing. That's why this whole mess is so frustrating !!!
Last week I tried using NFS ... but between SSH, Samba, and NFS ... only managed to hose one of our systems.
Heck, for all I know there were conflicting files between those 3 networking setups ???

Every time that I find Linux instructions, they're either too complex for us clickers to follow, or the instructions only cover the server, or the (GUI) instructions are old and no longer usable with missing steps and/or files due to the many Linux updates. I'm just at a loss ...

At this point I need to know how to clean anything ssh, samba, nfs related from the server via the console, step by step, without accomplishing anything else! Just a removal of anything & everything that could be causing some type of conflict. Then I need to do the same thing on the client, just to be safe. Then I need to reboot booth machines, knowing there's no longer anything conflicting on the machines.
Only then, can I start over with a clean networking attempt.

.

[altair4]

I'm going to try this one more time:

On the server:

** Turn off the firewall on the server:

Code: Select all

sudo ufw disable

** Make sure the firewall is inactive:

Code: Select all

sudo ufw status

** Make sure ssh is running:

Code: Select all

sudo service ssh status

** Find the ip address of the server

Code: Select all

ifconfig

On the client:

** Turn off the firewall:

Code: Select all

sudo ufw disable

** Make sure the firewall in inactive:

Code: Select all

sudo ufw status

** Before we get any further into this see if you can ping the server from the client in a terminal:

Code: Select all

ping 192.168.0.106 -c4

Change 192.168.0.106 to the ip address of the server that you found above.

** Now open a terminal and connect to the server from the client with a user name known to the server with this syntax:

Code: Select all

ssh username@ip_address

As an example I will show how I just connected to the server with the user name: tester

altair@xub1404:~$ ssh tester@192.168.0.106

This is the first time I connected to this server so I need a key:

The authenticity of host '192.168.0.106 (192.168.0.106)' can't be established.
ECDSA key fingerprint is d5:c2:c8:08:37:88:27:a8:9e:07:62:1e:9d:8c:40:da.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.106' (ECDSA) to the list of known hosts.

Then it will ask for tester's password:

tester@192.168.0.106's password:
Welcome to Linux Mint 18 Sarah (GNU/Linux 4.4.0-21-generic x86_64)

* Documentation: https://www.linuxmint.com
Last login: Tue Aug 9 12:41:57 2016 from 192.168.0.100
tester@vmint18xfce ~ $

Then I will close the connection:

tester@vmint18xfce ~ $ exit
logout
Connection to 192.168.0.106 closed.
altair@xub1404:~$

Side note: "removing the firewall ap" removed gufw. gufw is not a firewall it's an application used to configure the firewall.

EDIT: Just checking on things before I shut down for the day and noticed this in your post:

We're also using commercial VPN services in our home

Um .... I don't think this is going to work ... at least not as I posted it. Maybe Uranium has experience with doing this either as VPN is running or through VPN but I do not.

[LinWinux]

At this point, here's the part that's really confusing me ...
If the user name on the client machine is tester ...

This is the first time I connected to this server so I need a key:

The authenticity of host '192.168.0.106 (192.168.0.106)' can't be established.
ECDSA key fingerprint is d5:c2:c8:08:37:88:27:a8:9e:07:62:1e:9d:8c:40:da.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.106' (ECDSA) to the list of known hosts.

Then it will ask for tester's password:

tester@192.168.0.106's password:
Welcome to Linux Mint 18 Sarah (GNU/Linux 4.4.0-21-generic x86_64)

Then shouldn't the requested password actually be the one from the server machine? I'll use the terminal when I do this, but just for clarification ... when I did this with the GUI and the file manager, after the key message appeared I would get the window with client@serverip showing up on the screen. In other words, the user name of the client was on the left while the IP number of the server machine appeared on the right. That alone looks very confusing. When asked for the password while on the client machine, I would then enter the server' machine's password, since that's what I'm trying to access, right?
(the server wouldn't know what to do with the client machine password anyway)

Not understanding how or why this ssh works, the @ symbol which also implies the word "AT" is confusing. On the left I see the client user which makes sense since I'm sitting at the client machine, while to the right of this the IP of the server is displayed, which "visually" doesn't make any sense at all. Why would it display clientusername@serverIPnumber in my title bar? Just can't wrap my head around that ...
I will follow your instructions to the letter, using the server's password when I do.

Regarding VPN: We had no problem (before), running ssh while our computers were actively using VPN services from PIA. The VPN should only have an impact on what's happening while accessing information outside of the local (home) area network. Browsing the web, emailing, etc.

.

[Zill]

... When asked for the password while on the client machine, I would then enter the server' machine's password, since that's what I'm trying to access, right?

Sorry to interrupt but I hope I can help clarify this situation...
Machines do not have passwords. Only user accounts have passwords. Therefore you must connect to a user account on the server with the correct password for the server user account.

As altair4 advised earlier...

** Now open a terminal and connect to the server from the client with a user name known to the server with this syntax:

Code: Select all

ssh username@ip_address

As an example I will show how I just connected to the server with the user name: tester

altair@xub1404:~$ ssh tester@192.168.0.106

So, yes, just use the correct password for a user account on the server.

[altair4]

First, what Zill said.

Second:

At this point, here's the part that's really confusing me ...
If the user name on the client machine is tester ...

The user "tester" does not exist on the client machine. The user "tester" exists only on the server machine.

I could have set up a user "altair" on the server then accessed the server with altair and whatever password was created on the server for altair. But I did not. Instead I used a user and it's password that I knew were on the server.

As far as the @ symbol. If I were to try to access the server without it in a terminal:

altair@xub1404:~$ ssh 192.168.0.106
altair@192.168.0.106's password:

The system always assumes the user that is currently logged into the client has the same user name on the server. The @ tells the system that you are trying to connect to the server with a different name - one that has to be on the server.

And finally VPN. By design VPN isolates your machine from the local network as long as you are using VPN. Unless you are using VPN between the other members of your LAN which begs the question ... why? In any event it's been too long for me to remember any of this and I try to post only on things I know and can simulate on my own network if necessary to debug a question.

[LinWinux]

I'll be trying out the new information within the next couple of hours. Based on what I just read here, perhaps the problem has been all along the use of the wrong user even though the password was always correct. Remember, I was doing everything with GUI ...

When I use the file manager in order to connect to the server, the small window that comes up is distinctly separated into two different sections. Upper portion for information pertaining to the server, and the lower portion for information pertaining to the user.

Being on the client machine as I'm attempting to access the server, I obviously interpret this to mean that the SERVER IP number and access location of the server are in the top portion of the GUI window, while all of the lower portion has to do with the user/client of the machine that's being used in order to gain access to the server.

The connect to server GUI is literally split into two portions ... Server info and User info.
At the top, the server info of the host is supposed to be entered. Bold letters declare - SERVER.
At the bottom, the user info. of the client is supposed to be entered. Bold letters indicate - USER
Then, when asked for the password, I'm thinking ... why is it asking me for the server password in the user section of the GUI ???
See what I mean? The password requirement is in the section for user info., and not the server.
The server section of that GUI only has the IP & location access requirement, wihout a password.
This is what it looks like (Sorry, I have the German language setup):

ssh_gui_filemanager_connection.png

.

[Zill]

... why is it asking me for the server password in the user section of the GUI ???

... because you are connecting to a user account on the server!

The client user account is irrelevant. You need to authenticate the user account on the server with a password for the server user.

The clue is in your GUI dialog box heading "mit server verbinden". This translates as "connect to server".

[LinWinux]

I understand all that, thank you. The confusion stems from the fact that that gui window is split up into two sections. Someone who wouldn't know any better would figure that the server portion of that window is strictly and exclusively for information that's required about the server. Then, the user section below should consist strictly and exclusively for information that's coming *FROM* the client machine which is trying to gain access to the server. Otherwise, why bother splitting those two sections up in such a distinctly pronounced fashion?
Hence, user name = user name of the client ... ???
Password in user section = password of client machine ... ???
This doesn't make any sense though, at least not to me.
On the other hand, entering the server password in the client user section makes just as little sense to me.

.

[Zill]

LinWinux: I cannot express this any more clearly: The client user account is irrelevant.

If you use the CLI then this should not be a problem. You have chosen to use a GUI which you find confusing. This is one of the problems with GUIs - they can make matters appear to be more complicated than they need to be!

Your GUI seems quite clear to me but, if you still find this confusing then one of the great advantages of FOSS (free and open-source software) is that we are all free to change it. This means that you can either tweak the GUI to your own personal requirements or, preferably, join the appropriate development team and help ensure that future versions are not so "confusing".

[LinWinux]

Thank you everyone !!!

That kick in the head from Zill was really all that I needed all along.

LinWinux: I cannot express this any more clearly: The client user account is irrelevant.

User, user, user ... was the thing that I was hung up on, since every Linux machine has a user and a user password and a user keyring and user this or user that. Just couldn't get the user in the gui of the ssh connection out of my head, or rather ... get it into my head that the entirety of that gui window had nothing at all to do with the user who was on the client machine at that time.

As stated before though ... VPN is all about protecting the incoming and outgoing data-streams which are outside of the LAN. So VPN should not conflict with ssh or a firewall that's inside of the LAN. Anyway, we have VPN set up everywhere and the ssh between the client and the server is working fine once again. I really wish that I didn't feel quite as stupid as I do at the moment, but hey, that's what learning is all about.

@altair4
Dude, you have some incredible patience and I thank you for that.
I tried what you suggested last and everything worked/pinged fine as it should have.
That's when I realized that between the ping and what Zill had to say, there was never a problem in the first place. Just me having myself all screwed up because of that "user" word in the gui.

Anyway, thank you once again !!! I'll be marking this thread as solved.
Peace.

[otadmin]

Could you please explain the steps you took to solve the problem. I would like to have a go trying it here as I have SSH problems too.

[LinWinux]

At the very top of this post I've included this link here from the forum:
viewtopic.php?f=150&t=214600

That has the step by step for ssh access between a client and a server machine on a home network.
If you want step by step instructions, you have to be willing to read. It's fairly simple though.

Near the bottom of this particular post was the solution of why I couldn't get it to work after my own stupidity prevented me from getting it right. All I can say is this ... When you access the server from your client machine, the only ssh access information that you need to enter when you're sitting at the client, is the info. that belongs to the server, i.e. the IP number, server name, and password.
This works with the firewall, and it also works without.
Good luck.

.