Again ssh connection problem

Usually I don’t think that reinstalling a package will help. This is not windows, with stuffs in the registry that (hopefully) will be removed uninstalling a program.
Usually the problems are in the user home directory, or in some configuration file. Uninstalling a package doesn’t clean anything in the user home directory, and sometimes the configuration files are preserved also in the case of a reinstallation.

BTW, could you try to issue the ssh command locally?
I mean, on piwigoserver, could you try to to issue ssh giuseppe@localhost ?

In addition, as said by @vits95, if there is nothing private, could you show us the /etc/ssh/sshd_config file?

This shouldn’t have effect… :thinking: Since tcp wrappers was deprecated in F28

thanks for your precious help.
Now ssh works fine.
Maybe there was something corrupted in the ssh install.
the fresh install solved the problem. I just used this magic command you mentioned:
dnf reinstall dnf list --installed | grep ssh | awk ‘{print $1}’``

Best Regards.

:face_with_monocle: Be careful with copy and paste there: Command your’d posted shouldn’t work, as it’s misses a ` (Grave accent) after dnf reinstall (before dnf list), and have two unneeded ` (Grave accents) at the end.


:flying_saucer: *Loud laughts form a saucer…*

+1 for this

reinstalling restore ssh directories and file permision:

The OpenSSH server and client require strict permissions:

Both the host and the client should have the following permissions and owners:

  • ~./ssh permissions should be 700
  • ~./ssh should be owned by your account
  • ~/.ssh/authorized_keys permissions should be 600
  • ~/.ssh/authorized_keys should be owned by your account

Client environments should additionally have the following permissions and owners:

  • ~/.ssh/config permissions should be 600
  • ~/.ssh/id_* permissions should be 600


1 Like

Yes @vits95, I’m glad you are happy :slight_smile: The important thing is that @myagfedora resolved his problem.

However, if you have an issue with a configuration file under your home, reinstalling the package doesn’t help, this is guaranteed.

And also system configuration files, sometimes, aren’t removed when you uninstall a package. It depends in what manner the software was packaged (sometimes if you made a change to the original file, it will be renamed configfile.rpmsave when you uninstall the package) and it depends if the configuration uses included files, and probably other things. Or if some files are created during the first run of the software and then unhandled by the package manager, so the old files persist to live around even if you reinstall the package (i.e. mysql/mariadb).

Indeed I wrote: Usually I don’t think that reinstalling a package will help.
Also because, if reinstalling the package solves the issue, you didn’t understand what happened and…

and this issue was closed and resolved but for some strange reason after recovering my machine from a backup […] now I am still not able to ssh to my fedora 31 server


1 Like

Impressive community action to help resolve myagfedora’s issue.
While ssh is working, may be good to backup.

And have some LTS Live DVD / USB, and enough computer’s RAM (at least for basic operations).

boot parameters:

copytoram        -- Arch, Ubuntu    -- Fedora

Hello friend,

Also, I want to isolate the problem and collect more data regarding the issue.

  • Could you share your sshd.config?

  • As I understood you prefer to use password authentication. Correct me if I wrong.

  • I ask you to create a new user on your “test” Verify that this user has /bin/bash shell. You can just send us the output of cat /etc/passwd | grep test - as root. Don’t forget to create the password for the user, it won’t work without. sudo passwd test

  • If you have something like “Allow Users” options in your sshd config please temporarily disable it for the following test.

  • Connect to the server with -vvv option ssh -vvv test@server.ip and share the output. In the server-side do journalctl -u sshd -f and send us logs for a particular session.



  I am sorry because now I have solved the problem by reinstalling

ssh and now it is running perfectly.

  I thing the config files are ok now, so, it has no meaning to

send you my sshd.config and so on.

Best Regards.

Giuseppe Angelini

It is probably a good thing that you did not send/post your /etc/passwd file.

Doing so gives a bad guy the opportunity to know ALL the users (system as well as live users) user names, and a wealth of other data about them that should not be known outside yourself (if personally owned) or the system administrators (in a business).
It opens your system(s) up to potential attacks from those who wish harm.

In extremely rare cases and only if you personally know and thoroughly trust the individual it might be ok for troubleshooting, but NEVER in a public environment.

1 Like

:wink: This was this way (as of today nicholas’s post was never edited).

1 Like