Impossible activer service SSH

[oracle7]

Bonjour,

Voulant me connecter comme d'habitude à mon NAS via un terminal en SSH et grand étonnement, je me retrouve avec un message du type :

Citation

[processus terminé avec le code 255 (0x000000ff)]

Je vais donc dans le panneau de configuration vérifier l'activation du service SSH.

Constat : Désactivé 😥

Je le réactive donc et j'applique la modif pour l'enregistrer mais là il se désactive à nouveau. Même problème après plusieurs tentatives de réactivation.

J'active donc le service TELNET et via PuTTY je me connecte au NAS. Sous root je relance le service SSHD (synosystemctl restart sshd.service) et revient sur l'UI du NAS pour réactiver le service SSH.

Mais là toujours pareil, impossible à réactiver ce service SSH. 🙄

Du coup j'en appelle "aux barbus" du site car là je n'ai plus d'idées🥴.

Edit : J'ai aussi reboot le NAS mais sans effet ...

Comment puis-je m'en sortir ?

Je n'ai pas encore osé un reset mode 1, serait-ce d'ailleurs vraiment utile d'en passer par là ?

Il y a sûrement une autre solution, non ?

D'avance MERCI pour vos réponses.

Cordialement

oracle7😉

 

Modifié le 28 mars 2023 par oracle7

[Mic13710]

Je suppose que le port 22 n'est pas bloqué par le parefeu, que tu n'as pas non plus modifié le port par défaut.

Là comme ça, je n'ai rien à proposer. Il semblerait que ce soit DSM le fautif. Mise à jour récente peut-être et qui ne s'est pas correctement passée ?

Sinon, tu peux contacter le support, on ne sait jamais. C'est peut-être un problème connu chez eux.

[oracle7]

@Mic13710

Bonjour,

Tu supposes bien.

Cela a commencé hier avec une impossibilité de me connecter directement sous root via WinSCP ou PuTTY mais cela marchait encore avec mon user avec droits d'admin puis passage sous root (sudo su -) sans problèmes.

Pour finir ce matin après démarrage de mon PC, sur le blocage complet et la désactivation du service SSH.

En plus sur un second NAS qui a reçu en même temps la même MàJ upd4, il n'y a aucun soucis. C'est à rien y comprendre ...

Au passage, un "ps aux | grep ssh" ne me revoit rien malgré que le service sshd semble pouvoir être relancé mais je ne sais vérifier son statut effectif car "synosystemctl" n'a pas cette option.

Je vais donc suivre ton conseil et ouvrir un ticket au support Synology. Ils ont sûrement la solution !

Cordialement

oracle7😉

[PiwiLAbruti]

Tu utilises une clé publique pour te connecter en SSH ?

Sur le client, supprime les entrées relatives au NAS dans le fichier /.ssh/known_hosts (dans C:\Users\oracle7\ sous Windows) puis réessaye de te connecter en SSH.

 

[oracle7]

@PiwiLAbruti

Bonjour,

Oui pour la clé publique et cela marchait très bien jusqu'à mon problème.

Désolé mais aucun effet, après suppression des entrées relatives au NAS dans "C:\Users\oracle7\.ssh\known_hosts".

Sinon je viens de remplacer mon fichier sshd_config dans /etc/ssh par celui qui était présent dans /etc.defaults/ssh.

J'ai ensuite reload puis restart le sshd.service.

Du coup BINGO !!! J'ai pu réactiver le service SSH dans l'UI de DSM et j'ai pu de nouveau établir une connexion SSH au NAS avec mon user  droit d'admin.

Par contre, sous WinSCP lorsque je lance une nouvelle session sous root je récolte ce message :

alors que la connexion sous root se fait sans problèmes depuis WinSCP sur mon second NAS.

Une idée, peut-être ?

Cordialement

oracle7😉

[.Shad.]

Est-ce qu'en changeant le fichier sshd_config, le service SFTP est bien toujours activé ? De souvenir la configuration de SFTP se fait dans le même fichier.

[oracle7]

@.Shad.

Bonjour,

il y a 22 minutes, .Shad. a dit :

Est-ce qu'en changeant le fichier sshd_config, le service SFTP est bien toujours activé ?

Je ne te suis pas bien, changer quoi dans le fichier sshd_config ?

Je ne sais pas comment vérifier si le service SFTP est actif ou non. Je ne vois pas de processus (ps aux | grep sftp) ...

Au niveau de SFTP dans ce fichier il n'y a que cela :

# override default of no subsystems
#Subsystem	sftp	/usr/libexec/sftp-server
Subsystem       sftp    internal-sftp -f DAEMON -u 000

et c'est par défaut.

A tout hasard, mon fichier ssh-conf :

Ciphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
MACs hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com
#	$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.

#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

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile	.ssh/authorized_keys

#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 no to disable s/key passwords
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# 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 no
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#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

# override default of no subsystems
#Subsystem	sftp	/usr/libexec/sftp-server
Subsystem       sftp    internal-sftp -f DAEMON -u 000

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server
Match User root
	AllowTcpForwarding yes
Match User admin
	AllowTcpForwarding yes
Match User anonymous
	AllowTcpForwarding no
	GatewayPorts no

 

Une idée pour éventuellement relancer le serveur SFTP ? " synosystemctl start sftp.service " ne donne rien à part un " Fail to start [sftp] "

Cordialement

oracle7😉

[.Shad.]

Là ?

[oracle7]

@.Shad.

Bonjour,

Oui évidemment 😜

En aparté, juste une question au passage :

Je n'arrive pas à créer un lien symbolique sur un dossier partagé de mon NAS monté par cifs sur mon NUC linux :

mount -t cifs -o credentials=/home/oracle7/.synology/secret,user=oracle7,uid=1000,gid=100,_netdev,vers=2.0 //@IPlocaleNAS/dossierPartageSurNAS /mnt/dossierPartageSurNAS
ln -s /mnt/dossierPartageSurNAS /home/oracle7/fichierLien

Je récupère une erreur du type : " ln: impossible de créer le lien symbolique '/home/oracle7/fichierLien': Opération non supportée "

Une idée peut-être ? Je ne vois pas ce qui bloque la création du lien symbolique, parce que ce serait sur un dossier monté ?

Edit : Finalement j'ai trouvé, il suffisait d'ajouter l'option " mfsymlinks " à la commande de montage.

Cordialement

oracle7 😉

Modifié le 29 mars 2023 par oracle7

[MilesTEG1]

Il y a 3 heures, oracle7 a dit :

Edit : Finalement j'ai trouvé, il suffisait d'ajouter l'option " mfsymlinks " à la commande de montage.

Pour information si quelqu’un cherche de la doc (comme moi un jour dans le futur 😝) :

https://www.jeffgeerling.com/blog/2021/making-sure-symlinks-work-on-cifssmb-mounted-shares

 

https://superuser.com/questions/1337257/clients-cant-create-symlinks-on-samba-share
 

https://www.systutorials.com/docs/linux/man/8-mount.cifs/

[laurenttaieb]

Je pense que j'ai un problème qui ressemble.

J'ai exporté ma clé publique par contre elle n'est pas lue par sshd car je ne peux mettre à jour sshd_config, n'ayant pas le compte root (je n'ai que le compte admin).

Quelqu'un aurait il eu un problème similaire ?

Merci

Laurent

[oracle7]

@laurenttaieb

Bonjour,

Il y a 20 heures, laurenttaieb a dit :

n'ayant pas le compte root (je n'ai que le compte admin)

Bien sûr que oui tu as un compte root. Le compte root n'est accessible qu'en lignes de commandes sous SSH et pas dans l'UI de DSM.

• Dans un terminal, tu te connectes en SSH avec PuTTY (ou autre) et ton compte utilisateur "normal" (pas l'utilisateur "admin" car il devrait être  désactivé si tu as bien suivi les conseils de ce TUTO : Sécuriser les accès à son NAS).
• Tu tapes la commande suivante : " sudo su - " et tu saisis comme MdP, le MdP de ton utilisateur "admin" : c'est le même.
• Et là tu seras sous root, un # en fin de ligne d'invite te l'indique, si c'est un $ alors c'est que tu es connecté sous un utilisateur "normal".
  Donc sous root, tu peux alors faire toutes les actions dévolues à ce type de compte. Mais attention à ce que tu tapes car la moindre erreur peut avoir des conséquences désastreuses pour le bon fonctionnement ton NAS. Tu es prévenu !
   

Il y a 20 heures, laurenttaieb a dit :

J'ai exporté ma clé publique par contre elle n'est pas lue par sshd car je ne peux mettre à jour sshd_config

Pas seulement, il faut aussi que les droits sur le dossier .ssh et le fichier authorized_keys soient corrects i.e. respectivement 700 et 600.

Cordialement

oracle7😉

Modifié le 4 avril 2023 par oracle7