Ubuntu-fr

boutou49

[Résolu] Le serveur refuse le partage ssh

Suite à ce problème https://forum.ubuntu-fr.org/viewtopic.php?id=2068287
le serveur refuse les connexions ssh.
Y compris avec Fillezila.
Remina et vino eux fonctionnent.

Dernière modification par boutou49 (Le 18/11/2021, à 22:15)

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

bruno

Re : [Résolu] Le serveur refuse le partage ssh

Bonjour,

Il faut indiquer ta commande ssh et son retour complet. Idéalement an mode verbeux avec l'option -v :

ssh -v utilisateur@serveur

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

Bonjour,
je ne savais pas ce qui était intéressant à transmettre.

Voilà la cmde :

etienne@etienne:~/Bureau$ ssh -v serveur@192.168.1.30
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.1.30 [192.168.1.30] port 22.
debug1: connect to address 192.168.1.30 port 22: Connection refused
ssh: connect to host 192.168.1.30 port 22: Connection refused
etienne@etienne:~/Bureau$ 

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

bruno

Re : [Résolu] Le serveur refuse le partage ssh

La connexion est refusée par le serveur. C'est soit un pare-feu, soit une directive Match Address du fichier ssd_config qui bloque l'accès.

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

Le pare-feu est désactivé.

C'est quoi une directive Match Address du fichier ssd_config ?

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

bruno

Re : [Résolu] Le serveur refuse le partage ssh

Je ne l'avais pas précisé, mais il faut déjà regarder si le service est actif sur le serveur :

systemctl status ssh

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

Voila :

serveur@serveur:~/Bureau$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2021-11-15 17:37:48 CET; 2h 39min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 779 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=1/FAILURE)

nov. 15 17:37:47 serveur systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
nov. 15 17:37:48 serveur systemd[1]: Stopped OpenBSD Secure Shell server.
nov. 15 17:37:48 serveur systemd[1]: ssh.service: Start request repeated too quickly.
nov. 15 17:37:48 serveur systemd[1]: ssh.service: Failed with result 'exit-code'.
nov. 15 17:37:48 serveur systemd[1]: Failed to start OpenBSD Secure Shell server.
serveur@serveur:~/Bureau$ 

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

bruno

Re : [Résolu] Le serveur refuse le partage ssh

C'est clair. Le service ssh n'a pas réussi a démarrer.
Tu peux essayer de le relancer avec :

sudo systemctl restart ssh

Si cela ne fonctionne pas il faudra nous montrer le contenu du fichier /etc/ssh/sshd_config sur le serveur.

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

Voila :

serveur@serveur:~/Bureau$ sudo systemctl restart ssh
[sudo] Mot de passe de serveur : 
Job for ssh.service failed because the control process exited with error code.
See "systemctl status ssh.service" and "journalctl -xe" for details.
serveur@serveur:~/Bureau$ 

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

bruno

Re : [Résolu] Le serveur refuse le partage ssh

J'ai demandé le contenu de /etc/ssh/ssd_config

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

J'avais pas vu ta demande.
Comment je fais ça?

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

bruno

Re : [Résolu] Le serveur refuse le partage ssh

cat /etc/ssh/sshd_config

et donne aussi le retour de :

journalctl -xe -u ssh

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

serveur@serveur:~/Bureau$ cat /etc/ssh/sshd_config
#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server
serveur@serveur:~/Bureau$ 

serveur@serveur:~/Bureau$ journalctl -xe -u ssh
-- An ExecStartPre= process belonging to unit ssh.service has exited.
-- 
-- The process' exit code is 'exited' and its exit status is 1.
nov. 15 20:41:45 serveur systemd[1]: ssh.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- The unit ssh.service has entered the 'failed' state with result 'exit-code'.
nov. 15 20:41:45 serveur systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: L'unité (unit) ssh.service a échoué
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- L'unité (unit) ssh.service a échoué, avec le résultat failed.
nov. 15 20:41:45 serveur systemd[1]: ssh.service: Scheduled restart job, restart counter is at 4.
-- Subject: Le redémarrage automatique d'une unité (unit) a été planifié
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Le redémarrage automatique de l'unité (unit) ssh.service a été planifié, en
-- raison de sa configuration avec le paramètre Restart=.
nov. 15 20:41:45 serveur systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: L'unité (unit) ssh.service a terminé son arrêt
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- L'unité (unit) ssh.service a terminé son arrêt.
nov. 15 20:41:45 serveur systemd[1]: Starting OpenBSD Secure Shell server...
-- Subject: L'unité (unit) ssh.service a commencé à démarrer
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- L'unité (unit) ssh.service a commencé à démarrer.
nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open.
nov. 15 20:41:45 serveur sshd[4575]: It is required that your private key files are NOT accessible by others.
nov. 15 20:41:45 serveur sshd[4575]: This private key will be ignored.
nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: Permissions 0644 for '/etc/ssh/ssh_host_ecdsa_key' are too open.
nov. 15 20:41:45 serveur sshd[4575]: It is required that your private key files are NOT accessible by others.
nov. 15 20:41:45 serveur sshd[4575]: This private key will be ignored.
nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: Permissions 0644 for '/etc/ssh/ssh_host_ed25519_key' are too open.
nov. 15 20:41:45 serveur sshd[4575]: It is required that your private key files are NOT accessible by others.
nov. 15 20:41:45 serveur sshd[4575]: This private key will be ignored.
nov. 15 20:41:45 serveur sshd[4575]: sshd: no hostkeys available -- exiting.
nov. 15 20:41:45 serveur systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- An ExecStartPre= process belonging to unit ssh.service has exited.
-- 
-- The process' exit code is 'exited' and its exit status is 1.
nov. 15 20:41:45 serveur systemd[1]: ssh.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- The unit ssh.service has entered the 'failed' state with result 'exit-code'.
nov. 15 20:41:45 serveur systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: L'unité (unit) ssh.service a échoué
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- L'unité (unit) ssh.service a échoué, avec le résultat failed.
nov. 15 20:41:45 serveur systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
-- Subject: Le redémarrage automatique d'une unité (unit) a été planifié
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Le redémarrage automatique de l'unité (unit) ssh.service a été planifié, en
-- raison de sa configuration avec le paramètre Restart=.
nov. 15 20:41:45 serveur systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: L'unité (unit) ssh.service a terminé son arrêt
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- L'unité (unit) ssh.service a terminé son arrêt.
nov. 15 20:41:45 serveur systemd[1]: ssh.service: Start request repeated too quickly.
nov. 15 20:41:45 serveur systemd[1]: ssh.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- The unit ssh.service has entered the 'failed' state with result 'exit-code'.
nov. 15 20:41:45 serveur systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: L'unité (unit) ssh.service a échoué
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- L'unité (unit) ssh.service a échoué, avec le résultat failed.
lines 3082-3124/3124 (END)

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

Coeur Noir

Re : [Résolu] Le serveur refuse le partage ssh

Y-a-t-il eu un usage inopportun de la commande chmod récemment ?

Quelque chose comme

chmod a-rwx,u+rw,g+r ~/.ssh/*

devrait régler ce problème.

[ edit : oups, non, car ce n'est pas dans le répertoire perso que se situe le problème mais côté système dans /etc/ssh ce qui est plutôt alarmant ]

Dernière modification par Coeur Noir (Le 15/11/2021, à 23:43)

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

soshy

Re : [Résolu] Le serveur refuse le partage ssh

C'est des clés dans /etc/ssh qu'il faut chmod et pas ~/.ssh/*

Donc sur le serveur pour réparer les droits :

sudo chmod 600 /etc/ssh/ssh_host_rsa_key
sudo chmod 600 /etc/ssh/ssh_host_ecdsa_key
sudo chmod 600 /etc/ssh/ssh_host_ed25519_key

puis démarrer ssh

sudo systemctl start ssh.service

Edit: remplacement des droits 300 par 600.

Dernière modification par soshy (Le 15/11/2021, à 23:29)

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

Pour  résoudre l'autre pb j'ai passé cette commande

sudo chmod 440 /etc/sudoers

Dernière modification par boutou49 (Le 15/11/2021, à 22:08)

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

@soshy : super. J'ai fait ces changements et ça fonctionne.
Génial.
Bonne soirée à tous.

Dernière modification par boutou49 (Le 15/11/2021, à 22:24)

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

Coeur Noir

Re : [Résolu] Le serveur refuse le partage ssh

Euh… comment on en vient à toucher à /etc/sudoers ? La démarche m'intrigue.

Quant à @soshy avec chmod 300 tu proposes des droits -wx------ or c'est rw-r----- ( 640 ) qui est conseillé à cet endroit là.
Et c'était bien ce que je proposais, une seule commande pour régler correctement les droits de tout le contenu de ~/.ssh/
Ou en mode parano r-------- ( 400 soit lecture seule, à l'utilisateur proprio uniquement ).

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

soshy

Re : [Résolu] Le serveur refuse le partage ssh

avec chmod 300 tu proposes des droits -wx------ or c'est rw-r----- ( 640 ) qui est conseillé à cet endroit là.

Je n'ai fait que reprendre les droits attribuée par défaut sur une install clean :

ls -la /etc/ssh/
total 584
drwxr-xr-x   4 root root   4096 mars  12  2021 .
drwxr-xr-x 141 root root  12288 nov.  12 06:14 ..
-rw-r--r--   1 root root 535195 févr. 26  2020 moduli
-rw-r--r--   1 root root   1603 févr. 26  2020 ssh_config
drwxr-xr-x   2 root root   4096 févr. 26  2020 ssh_config.d
-rw-r--r--   1 root root   3288 oct.  28  2020 sshd_config
drwxr-xr-x   2 root root   4096 févr. 26  2020 sshd_config.d
-rw-------   1 root root    525 mai   11  2020 ssh_host_ecdsa_key
-rw-r--r--   1 root root    191 mai   11  2020 ssh_host_ecdsa_key.pub
-rw-------   1 root root    419 mai   11  2020 ssh_host_ed25519_key
-rw-r--r--   1 root root    111 mai   11  2020 ssh_host_ed25519_key.pub
-rw-------   1 root root   2622 mai   11  2020 ssh_host_rsa_key
-rw-r--r--   1 root root    583 mai   11  2020 ssh_host_rsa_key.pub
-rw-r--r--   1 root root    342 mai   11  2020 ssh_import_id

Pour les 3 fichiers mentionnés, c'est du 300 600.

Et c'était bien ce que je proposais, une seule commande pour régler correctement les droits de tout le contenu de ~/.ssh/

Justement, le problème c'est pas les droits dans ~/.ssh mais des 3 fichiers mentionnés dans /etc/ssh

Edit: je me suis planté ça aurait dû être 600 et non 300. Après comme c'est root, j'imagine qu'il peut lire même sans avoir les droits...

Dernière modification par soshy (Le 15/11/2021, à 23:30)

Coeur Noir

Re : [Résolu] Le serveur refuse le partage ssh

My bad !

J'avais pas vu qu'il s'agissait de /etc/ssh/
C'est pourtant écrit en assez gros là :

nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
nov. 15 20:41:45 serveur sshd[4575]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
nov. 15 20:41:45 serveur sshd[4575]: Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open.

Je pensais que c'était juste un pépin côté utilisateur ( donc dans /home/$USER/.ssh ).

Ce qui renforce mon interrogation : comment on en vient à « dérégler » des droits à cet endroit là : /etc/ssh ?
Soit le système est corrompu, soit il y a eu manipulation volontaire mais terriblement suspecte.

Dernière modification par Coeur Noir (Le 15/11/2021, à 23:37)

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

bruno

Re : [Résolu] Le serveur refuse le partage ssh

Cela suggère que des commandes de changements de droits on été précédemment lancés sur le répertoire /etc (problème sudoers + problème ssh). Si c'est le cas d'autres problèmes vont survenir.

P.S. : @soshy c'est pour aussi cela qu'il vaut mieux éviter d'utiliser chmod en mode octal.

Coeur Noir

Re : [Résolu] Le serveur refuse le partage ssh

il vaut mieux éviter d'utiliser chmod en mode octal.

Je plussoie à 1000% la méthode littérale est plus « fine » notamment pour le traitement de l'exécution x sur les fichiers, X sur les dossiers.

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

Euh… comment on en vient à toucher à /etc/sudoers ? La démarche m'intrigue.

Quant à @soshy avec chmod 300 tu proposes des droits -wx------ or c'est rw-r----- ( 640 ) qui est conseillé à cet endroit là.
Et c'était bien ce que je proposais, une seule commande pour régler correctement les droits de tout le contenu de ~/.ssh/
Ou en mode parano r-------- ( 400 soit lecture seule, à l'utilisateur proprio uniquement ).

J'ai eu un problème avec "sudo" : voir cette discussion : [Résolu] Commande sudo impossible à executer.
Et on m'a fait changer les droits à certains endroits. Je suis, dans ce cas, un pur exécutant incapable de comprendre ce qu'il fait.
Attention, c'est super d'être aidé et même si on me fait faire une mauvaise manip, je ne blâmerais jamais quelqu'un qui prend de son temps pour aider les autres.

Et c'est sûrement l'interface chaise / clavier qui est en cause comme souvent !

Dernière modification par boutou49 (Le 16/11/2021, à 07:23)

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

boutou49

Re : [Résolu] Le serveur refuse le partage ssh

Cela suggère que des commandes de changements de droits on été précédemment lancés sur le répertoire /etc (problème sudoers + problème ssh). Si c'est le cas d'autres problèmes vont survenir.

P.S. : @soshy c'est pour aussi cela qu'il vaut mieux éviter d'utiliser chmod en mode octal.

Tout seul, je n'utilise chmod que lorsque je suis absolument sûr de ce que je fais : c'est à dire jamais.

---

Sous Ubuntu depuis Hardy Heron et Xubuntu depuis Xenial Xerus

Coeur Noir

Re : [Résolu] Le serveur refuse le partage ssh

Humour et humilité, c'est bon ça ;-)

Avant ce pépin avec ssh, tu as apparemment eu des pépins avec sudo.

Et avoir des pépins avec sudo ça n'est pas anodin du tout : il faut comprendre si c'est la conséquence d'une manip' volontaire de l'utilisateur ( volontaire mais pas forcément consciente ni opportune )
ou si la situation était bancale dès l'installation du système et son premier démarrage ( auquel cas on peut s'interroger sur l'image iso qui a servi à l'installation, sa provenance et son intégrité ).

C'est vital dans un système utilisant sudo que ce mécanisme soit en bonne santé, bien réglé car il donne ± accès à l'utilisateur root qui a les pleins pouvoirs :
c'est un mécanisme d'élévation de privilèges qui doit rester circonscrit ( à certaines tâches, certains usages ).
Si ce mécanisme est « abîmé » ou n'est plus correctement circonscrit, la sécurité du système et des données n'est plus garantie.

---

Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >