DS918+ - SSH nicht aktivierbar

[mak_xxl]

Guten Morgen ins Forum,

auf einer der hier mehrfach vorhandenen DS918+ (DSM 7.2.1-69057 Update 4) lässt sich SSH nicht starten aktivieren.

Wird der Haken (GUI) gesetzt und anschließend gespeichert, verschwindet sofort der Haken, es wird gelegentlich eine Netzwerküberlastung etc. gemeldet, aber in keinem Fall kann SSH aktiviert werden.

Mehrere Reboots oder die Änderung der Portnummern änderten an dem Verhalten nichts.

Um ein evtl. Hardwareproblem auszuschließen, wurde der Plattensatz in eine andere DS918+ verbracht - gleiche Misere.
Der andere Plattensatz (speziell SSH) funktioniert in der o.a. NAS einwandfrei.

Da Telnet normal funktioniert, wurde auf der Konsole etwas gestöbert:

root@NAS-xxxxx:netstat -tulpen | grep :22 Nix - auch für andere Ports

root@NAS-xxxxx:systemctl status sshd â sshd.service - OpenBSD Secure Shell server Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled) Drop-In: /usr/local/lib/systemd/system/sshd.service.d ââsynorelay-service-handler.conf Active: failed (Result: start-limit) since Tue 2024-03-19 06:59:35 CET; 28min ago Process: 19392 ExecStopPost=/bin/sh -c [ "active" = "$(/usr/syno/bin/synosystemctl get-active-status synorelayd)" ] && /usr/syno/bin/synosystemctl reload synorelayd || exit 0 (code=exited, status=0/SUCCESS) Process: 19384 ExecStartPost=/bin/sh -c [ "active" = "$(/usr/syno/bin/synosystemctl get-active-status synorelayd)" ] && /usr/syno/bin/synosystemctl reload synorelayd || exit 0 (code=exited, status=0/SUCCESS) Process: 19383 ExecStart=/usr/bin/sshd -D (code=exited, status=255) Process: 19379 ExecStartPre=/usr/bin/ssh-keygen -A (code=exited, status=0/SUCCESS) Process: 19367 ExecStartPre=/usr/lib/systemd/scripts/sshd_checker.sh (code=exited, status=0/SUCCESS) Main PID: 19383 (code=exited, status=255) Mar 19 06:59:34 NAS-xxxxx systemd[1]: Unit sshd.service entered failed state. Mar 19 06:59:34 NAS-xxxxx systemd[1]: sshd.service failed. Mar 19 06:59:35 NAS-xxxxx systemd[1]: sshd.service holdoff time over, scheduling restart. Mar 19 06:59:35 NAS-xxxxx systemd[1]: start request repeated too quickly for sshd.service Mar 19 06:59:35 NAS-xxxxx systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 19 06:59:35 NAS-xxxxx systemd[1]: Unit sshd.service entered failed state. Mar 19 06:59:35 NAS-xxxxx systemd[1]: sshd.service failed.

Hat jemand eine Idee, wo hier die Säge klemmt? Für Lösungshinweise bin ich dankbar.

Freundliche Grüße - M. Kuhn

 

[framp]

Sieh doch mal im Log nach mit

journalctl -u sshd

 

[Benie]

Kannst Dich ja mal hier durch ähnliche Threads wühlwn.

https://www.synology-forum.de/search/4677398/?q=ssh++nicht+aktivieren&o=date

 

[mak_xxl]

Mahlzeit ins Forum,

Dank für den Hinweis, er war entscheidend! Und ich schäme mich, nicht selbst im Journal geschaut zu haben ...

Also, ein journalctl -u sshd ergibt folgendes (nur die wesentlichen Zeilen):
Mar 19 12:23:07 NAS-xxxxx systemd[1]: Starting OpenBSD Secure Shell server... Mar 19 12:23:07 NAS-xxxxx systemd[1]: Started OpenBSD Secure Shell server. Mar 19 12:23:07 NAS-xxxxx sshd[9669]: /etc/ssh/sshd_config: line 4: Bad configuration option: CiphertRootLogin Mar 19 12:23:07 NAS-xxxxx sshd[9669]: /etc/ssh/sshd_config: terminating, 1 bad configuration options Mar 19 12:23:07 NAS-xxxxx systemd[1]: sshd.service: main process exited, code=exited, status=255/n/a Mar 19 12:23:07 NAS-xxxxx systemd[1]: Unit sshd.service entered failed state. Mar 19 12:23:07 NAS-xxxxx systemd[1]: sshd.service failed.

Das Editieren vi /etc/ssh/sshd_config zeigt einen völlig unformatierten Beginn der Datei:
Ciphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.comKexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512MACs 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.comCiphersRootLogin yesPermitRootLogin yesm 3des-cbc,aes128-cbc,aes128-ctr,aes128-gcm@openssh.com,aes192-cbc,aes192-ctr,aes256-cbc,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,rijndael-cbc@lysator.liu.se # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
Die Zeilenumbrüche stammen hierbei aus der Forensoftware.

Das Ganze etwas gebändigt sieht so aus:
1. Zeile: Ciphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com 2. Zeile: KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512 3. Zeile: 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 4. Zeile: CiphertRootLogin yes 5. Zeile: PermitRootLogin yes 6. Zeile: # m 3des-cbc,aes128-cbc,aes128-ctr,aes128-gcm@openssh.com,aes192-cbc,aes192-ctr,aes256-cbc,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,rijndael-cbc@lysator.liu.se 7. Zeile: 8. Zeile: # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

Die Zeilen-Nr. ist nur zur besseren Nachvollziehbarkeit angegeben.
Der Text der 6. Zeile hing direkt hinter 'PermitRootLogin=yes' und erschließt sich mir nicht - deshalb auskommentiert. Die 8. Zeile ist der reguläre Beginn des Config-Files - in diesem Beitrag zur Orientierung immer mit angegeben.

Mit dieser Config startet SSH immer noch nicht, also Zeile 4 auch auskommentiert, weil 'CiphertRootLogin yes' wohl nicht hierher gehört.

Nun startet der sshd wieder:
Mar 19 12:46:18 NAS-xxxxx systemd[1]: Starting OpenBSD Secure Shell server... Mar 19 12:46:18 NAS-xxxxx systemd[1]: Started OpenBSD Secure Shell server. Mar 19 12:46:18 NAS-xxxxx sshd[16497]: Server listening on 0.0.0.0 port 22. Mar 19 12:46:18 NAS-xxxxx sshd[16497]: Server listening on :: port 22.

Der Inhalt des weiter oben erwähnte Zeichenhaufens deutet auf Sicherheitskonfigurationen hin, die unter 'Terminal' -> 'Erweiterte Einstellungen' ausgewählt werden.

Also wurde aus dem Config-File der ganze Block (Cipher-KES-MAC) gelöscht und dann im GUI die Einstellungen 'Hoch' gewählt und gespeichert.

Diesmal sah der am Beginn des Config-Files eingefügte Block schon besser aus:
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 $
Damit startet der sshd wieder ohne Probleme, auch nach Reboots, der Zugriff über SSH funktioniert erwartungsgemäß.

Fazit: Es bleibt im Nebel, wie die Einträge 'CiphertRootLogin yes' und 'PermitRootLogin yes' in den Schlüsselblock kamen und warum genau derselbe so unformatiert im 'sshd_config' landete.

Nochmals Dank an alle, die mitgelesen haben und spezieller Dank an @framp.

Freundliche Grüße M. Kuhn

 

[Benares]

Hier mal zum Vergleich meine /etc/ssh/sshd_config. Ich hab da nie was dran gemacht. Die Datei ist vom 30.08.2022.

#       $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

Keine Ahnung, wer/was dir da reingespuckt hat.

 

[framp]

Und ich schäme mich, nicht selbst im Journal geschaut zu haben ...

Ein jeder ist nur ein Mensch und manchmal vergisst der eben Dinge mal