Connection ssh impossible depuis la Mise a jour

,

Bonjour,
J’ai un serveur chez OVH et depuis que j’ai fais la MAJ de Débian et de YunoHost je ne peux plus me connecté en SSH. En revanche j’ai accès au serveur via le KVM. L’interface WEB fonctionne correctement. Par chance j’ai un systeme de BackUp automatique. J’ai donc remis une ancienne version.
Si vous avez une solution, merci beaucoup.

L’incident est survenu Mardi (Hier) et 2 BackUp sont avec de défaut celle de Lundi et Mardi, celle qui est monté est celle de Dimanche.

Ma Config du Serveur :

  • OS : Debian 10 serv.
  • Ref. OVH du serveur : VPS vps2020-essential-2-4-80

Bonjour et bienvenue! J’ecrire en Anglais, par ce que ma Francais est tres mal, excuse!

Can you still reproduce the error after restoring the backup?
Which error did connecting via SSH give?
Which user do you use to connect via SSH?
When using KVM access, can you then ssh admin@localhost?
Do you access SSH via password or via key?

1 Like

Je ne peux pas reproduire l’erreur depuis que j’ai restauré la sauvegarde.
L’erreur de connextion est : Permission Denie
Je n’ai pas fais admin@localhost avec la version coronpue.
J’utilise le SSH avec un mot de passe

My guess would be: fail2ban

Are you familiar with fail2ban?

Je vois se que c’est. Je ne pense pas l’avoir sauf si il est installé de basse

Il est, so that could be the cause. I am not sure how many attempts it allows, not more than 3 I think. After that, your IP gets blocked. It can be configured to unblock after a while, or manually with an unban-command.

A safe way to prevent it from happening is creating an SSH key pair, with ssh-keygen on your computer/laptop, and then ssh-copy-id admin@yunodejules.fr.
If you make key without passphrase, you can log into your Yunohost as admin without a password, and without password errors, from then on.

Ok je vois l’idée. Mais le problème qu’il y a est que des que je faits les Mise a Joursle problème revien, je suis donc obligé de remètre ma backup.
Donc pour moi le PB ne vient pas de fail2ban.

Ah, so, if you update again, the problem returns? Hmm, that is strange! If it says ‘Permission Denie’, I expect a firewall issue. That would mean the update changes the firewall.

My Yunohosts are up to date, without SSH problems, so it is not a problem in general Yunohost packages.

Sorry not to be of more help!

C’est pas graves j’espere que quelqu’un pourra.
Merci Quand même.

1 Like

Je Viens de testé de reconfiguré le ssh et quand je le redémare j’ai cette erreur :

● ssh.service - OpenBSD Secure Shell server
   Loaded: loade Preformatted textd (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2021-10-13 18:57:07 UTC; 2min 7s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 22585 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255/EXCEPTION)
    Tasks: 0 (limit: 4603)
   Memory: 2.6M
   CGroup: /system.slice/ssh.service

Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Control process exited, code=exited, status=255/EXCEPTION
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Failed with result 'exit-code'.
Oct 13 18:57:07 [ServerName] systemd[1]: Failed to start OpenBSD Secure Shell server.
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
Oct 13 18:57:07 [ServerName] systemd[1]: Stopped OpenBSD Secure Shell server.
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Start request repeated too quickly.
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Failed with result 'exit-code'.
Oct 13 18:57:07 [ServerName] systemd[1]: Failed to start OpenBSD Secure Shell server.

[ServerName] Correspomd au nom de mon serveur /addres WEB

Does the diagnosis give any warning about a config file deviating from default?

Does running sshd -t from the shell directly give any clue?

man sshd mentions -t : Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change.

It also mentions -T as an option, Extended test mode. Does running sshd -T give a clou?

In case it is of any help comparing, my (correctly running) sshd gives this as status:

service ssh status
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2021-10-03 15:11:49 UTC; 1 weeks 3 days ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 584 (sshd)
    Tasks: 1 (limit: 38288)
   Memory: 28.4M
   CGroup: /system.slice/ssh.service
           └─584 /usr/sbin/sshd -D

(cut logging about connections etc)

J’ai lu auparavant qu’il y a eu des problèmes avec les mots de passe contenant des caractères spéciaux. Je ne sais pas si ça correspond à ce que tu as

Non j’ai un mot de passer que je connais et qui est correcte car je peux me connecte avec dans le KVM.

That is good: you still can connect, even if SSH does not work.

After you upgrade you can not use SSH anymore, it is not running:

Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Control process exited, code=exited, status=255/EXCEPTION
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Failed with result 'exit-code'.
Oct 13 18:57:07 [ServerName] systemd[1]: Failed to start OpenBSD Secure Shell server.
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
Oct 13 18:57:07 [ServerName] systemd[1]: Stopped OpenBSD Secure Shell server.
Oct 13 18:57:07 [ServerName] systemd[1]: ssh.service: Start request repeated too quickly.

So, we don’t look at fail2ban.

The error is not so clear, it only says ‘255, exception’, but not what exception.

Standard, with service sshd start, the system calls sshd -t in the background.

Now, could you do this:

  • use KVM to log into your server
  • run sudo sshd -T

That will check the config, and hopefully give a better/clear error.