QTS 5.2.x: kein Zugriff per ssh/sftp mehr

Zuletzt sind die Probleme wegen veralteten SSH clients aufgetreten, die die in der Version von QNAP erlaubte Verschlüsselung nicht beherrschten... Keine Ahnung wie sich das bei Mac verhält...

Moin,

auf meiner 251D hab ich nach einer neu Initialisierung und Neu aufteilen der hdd´s auf QTS 5.2.0.2860 kein Problem mit ssh gehabt. Vieleicht einfach nochmal die neuste Firmware flashen.

Aktuelles Linux Arch

Gruß Arnulf

Ich hatte bei keiner der vielen Beta/RC-Versionen ein Problem mit SSH-Zugriff auf meinem TS-264

Ich nutze unter Windows putty 0.78

Auch mit der WinSCP Version 6.3.4 gibt es keine Probleme.

Komme auf meinen mit Terminus 5.8.7 problemlos drauf.

Welche Version nutzt du aktuell?

Grad heute 5.2.0.2860 auf nem TS-853BU installiert und auch hier meckert der SSH Client von Windows

Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 192.168.168.30 port 22: message authentication code incorrect

Wenn man dann folgendes in das SSH Kommando einfügt, geht's

ssh -m hmac-sha2-512 user@NASIPoderNAME

Zitat von dolbyman

Wenn man dann folgendes in das SSH Kommando einfügt, geht's

Habe es gerade noch mit dem SSH-Zugriff der Powershell von Windows 10/11 getestet.

Der Zugriff wurde bei meinen NAS (QTS 5.1.8 + QTS 5.2) verweigert.

Mit dem Zusatz -m hmac-sha2-512 hat es dann auch mit der Powershell von Windows funktioniert.

Da ich normalerweise nur putty nutze. habe ich das Problem mit der Powershell gar nicht bemerkt.

Scheinbar ist putty dem Windowstool doch etwas überlegen.

Ja, ein sshd-Prozess müsste laufen und auf Port 22 horchen:

[~] # ps aux | grep sshd
 7268 admin      8032 S   sshd: admin [priv]
 7366 admin      7688 S   sshd: admin@pts/4
 8663 admin       456 S   grep sshd
17049 admin      4416 S   /usr/sbin/sshd -f /etc/config/ssh/sshd_config -p 22
[~] # netstat -lntp | grep -e :22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      17049/sshd
tcp        0      0 :::22                   :::*                    LISTEN      17049/sshd
[~] # 

Zitat von Shifter

/etc/init.d/login.sh restart bringt auch nichts.

Was heißt "bringt nichts"? Was war die Ausgabe?

Was gibt getcfg LOGIN "SSH Enable" aus?

IMG_0514.jpeg

Das hatte ich auch in Verdacht Becker2020 aber so klappt es auch nicht

Eine connection stellt der client her aber meckert an der mangelnden Verschlüsselung

tgsbn meiner horcht auf 580

Das würde ich gerne ändern:

#       $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker 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 change a
# default value.

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 1h
ServerKeyBits 4096

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

LoginGraceTime 2m
#PermitRootLogin yes
StrictModes yes
MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and 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 yes

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

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
UseDNS no
PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

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

AllowUsers admin
# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server

Stimmt deine Eingabe

Bei Win sieht es so aus ssh -m hmac-sha2-512 admin@192.xxxx

Bei deinem MAC sieht es so aus ssh:// -m hmac-sha2-512 user@192

Ich nutze für SSH eigentlich nur den admin.

Du scheinst einen anderen Nutzer (alternativer Admin) zu verwenden.

Hast Du es mal mit dem richtigen admin versucht ?

Zitat von florit

Das würde ich gerne ändern:

Du hättest besser ein neues Thema aufmachen sollen, weil das nichts mit der ursprünglichen Frage zu tun hat.

Ändern kannst du die Datei gerne, aber es bewirkt nichts. Das Problem ist, dass die Konfigurationsdatei bei jedem Start des Dämonen neu zusammengebaut wird und damit alle Änderungen in der Datei überschrieben werden. Wenn deine Änderungen aktiv werden sollen, wird es kniffelig, insbesondere wenn die Änderungen auch einen Reboot überleben sollen (Datei in autorun.sh ändern hilft nicht).

Lösungsmöglichkeiten:

1. Die Dateien ändern, aus denen die SSH-Konfigurationsdatei beim Start des Dämonen zusammengebaut wird.

Ich weiß nicht, welche Dateien das sind, und diesen Weg habe ich nicht weiter verfolgt.

2. Man jubelt dem Dämonen den Pfad zu einer eigenen Konfigurationsdatei unter.

Dazu kopiert man die Datei /etc/ssh/sshd_config

in ein Verzeichnis, das schon zum Boot-Zeitpunkt zur Verfügung steht (ich habe /mnt/HDA_ROOT/boot genommen) und ändert sie nach Belieben ab.

In /etc/daemon_mgr.conf befindet sich eine Liste von Dämonen inklusive ihrer Aufrufparameter. Diese ändert man in autorun.sh (oder in einer aus autorun.sh aufgerufenen Batchdatei, das ist flexibler) so, dass für ssh unsere Konfigurationsdatei als Parameter eingetragen wird, und startet den ssh-Dämonen neu. Das ergibt folgenden Code, der dort eingetragen wird:

cp -p /etc/daemon_mgr.conf /etc/daemon_mgr.conf.bak
sed '/^DAEMON[0-9]* = sshd,.*$/s/-f  *[^ ][^ ]* /-f \/mnt\/HDA_ROOT\/boot\/sshd_config /' /etc/daemon_mgr.conf.bak >/etc/daemon_mgr.conf
killall sshd

Nach dem nächsten Reboot nutzt der ssh-Dämon unsere Konfigurationsdatei. Wenn man nicht auf den Reboot warten will, führt man die drei Kommandos mit sudo per Hand aus.

Bei der Gelegenheit kann man in die neue ssh-Konfigurationsdatei die Authentifizierung ausschließlich per ssh-Key einschalten (Authentifizierung per Passwort ausschalten) und die Liste der zulässigen Benutzer setzen.

Wenn man Murks macht und nicht mehr ins System kommt, muss man Telnet einschalten und sich darüber einloggen (bitte nur im eigenen LAN; Telnet ist sehr unsicher).

Zitat von Becker2020

Du scheinst einen anderen Nutzer (alternativer Admin) zu verwenden.

Das ist kein Problem. Mit sudo -i bekommt man jederzeit eine vollwertige Admin-Shell. Nur für Telnet ist der echte Admin unverzichtbar.

Zitat von Anthracite

Das ist kein Problem.

Ich wollte nur wissen, welchen Benutzer er nutzt. Der alternative ADMIN ist ja nur eine Vermutung meinerseits.

Der alternative Admin muss aber erst in QTS die SSH-Berechtigung erhalten.

Becker2020 den Alternativen admin user den ich angelegt habe … nicht “admin”

Und mittels sudo erlange ich admin rechte