Newbunto
Anmeldungsdatum: 11. September 2017
Beiträge: 71
|
Liebe alle,
nach dem Update auf Ubuntu 20.04 kann ich leider mit einigen Clients keine sftp-Verbindung mehr herstellen. Wenn ich den Status des Dienstes Abfrage erhalte ich folgende Fehlermeldung: Unable to negotiate with xx.xx.xx.xx port 34444: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 Wenn ich das richtig verstehe gelingt es schon gar nicht den Verbindungsaufbau zu verschlüsseln, da Client und Server unterschiedliche Methoden verlagen. Ich stehe aber leider nicht so weit im Thema, dass ich die verschiedenen Methoden auch bewerten könnte. Daher hoffe ich auf euren Rat - wie sollte ich am besten damit umgehen ohne Sicherheitsmaßnahmen so weit runter zu schrauben, dass zwar der Verbindungsaufbau gelingt, dafür die Verschlüsselung aber obsolet ist? Auch erhalte ich neuerdings die Mitteilungen Jan 05 23:07:19 NAS sshd[2869]: rexec line 16: Deprecated option UsePrivilegeSeparation
Jan 05 23:07:19 NAS sshd[2869]: rexec line 19: Deprecated option KeyRegenerationInterval
Jan 05 23:07:19 NAS sshd[2869]: rexec line 20: Deprecated option ServerKeyBits
Jan 05 23:07:19 NAS sshd[2869]: rexec line 33: Deprecated option RSAAuthentication
Jan 05 23:07:19 NAS sshd[2869]: rexec line 40: Deprecated option RhostsRSAAuthentication Was genau ist denn mit "Veralteter Option" gemeint? - Besteht hier Handlungsbedarf? Vielen Dank für die Unterstützung
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13315
|
Newbunto schrieb: nach dem Update auf Ubuntu 20.04 ... Jan 05 23:07:19 NAS sshd[2869]: rexec line 16: Deprecated option UsePrivilegeSeparation
Wie ist auf dem sshd-Server die Ausgabe von:
sudo sshd -t
Von welcher Version hast Du auf Ubuntu 20.04 updatet? Hast Du die alte sshd_config, nach dem update benutzt?
|
Newbunto
(Themenstarter)
Anmeldungsdatum: 11. September 2017
Beiträge: 71
|
sudo sshd -t
gibt
/etc/ssh/sshd_config line 16: Deprecated option UsePrivilegeSeparation
/etc/ssh/sshd_config line 19: Deprecated option KeyRegenerationInterval
/etc/ssh/sshd_config line 20: Deprecated option ServerKeyBits
/etc/ssh/sshd_config line 33: Deprecated option RSAAuthentication
/etc/ssh/sshd_config line 40: Deprecated option RhostsRSAAuthentication
aus. lubux schrieb: Von welcher Version hast Du auf Ubuntu 20.04 updatet? Hast Du die alte sshd_config, nach dem update benutzt?
Ich habe von 18.04 geupgraded und die vorhandene config-datei beibehalten.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13315
|
Newbunto schrieb: sudo sshd -t
gibt
/etc/ssh/sshd_config line 16: Deprecated option UsePrivilegeSeparation
/etc/ssh/sshd_config line 19: Deprecated option KeyRegenerationInterval
/etc/ssh/sshd_config line 20: Deprecated option ServerKeyBits
/etc/ssh/sshd_config line 33: Deprecated option RSAAuthentication
/etc/ssh/sshd_config line 40: Deprecated option RhostsRSAAuthentication
aus.
Dann kommentieren in der sshd_config diese Zeile und versuche erneut mit/nach:
sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17279
|
Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 Wenn du das bekommst, hat die Gegenseite entweder manuell fragwürdige/veraltete Cipher, oder aber eine steinalte SSH Version. Welche SSH Version läuft auf dem Server? Die von Ubuntu 20.04 hat das Problem so nicht, können wir mal deine gesamte sshd_config bekommen?
|
Newbunto
(Themenstarter)
Anmeldungsdatum: 11. September 2017
Beiträge: 71
|
Die Versionsabfrage ergibt folgende Ausgabe: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, 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 localhost [::1] port 22.
debug1: connect to address ::1 port 22: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: connect to address 127.0.0.1 port 22: Connection refused
ssh: connect to host localhost port 22: Connection refused und meine sshd_config beinhaltet das # Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port xxxx
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
AllowUsers user1, user2 ...
PrintLastLog no
# Authentication:
LoginGraceTime 180
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
MaxStartups 5
ClientAliveInterval 900
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
#Subsystem sftp /usr/lib/openssh/sftp-server -l INFO
# Enable to built-in implementation of SFTP.
Subsystem sftp internal-sftp
# 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
Match group sftp
ChrootDirectory /NAS
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Match user user2
ForceCommand internal-sftp
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17279
|
https://www.openssh.com/txt/release-8.2 Beschreibt dein Problem, dein Server hat OpenSSH 8.2, dort wurde z.B. diffie-hellman-group14-sha1 entfernt. Welche SSH Version hat der Client, denn laut Logfile bietet dieser nur dieses alte Zeugs an? Du sagst ja das nur einige Clients Probleme haben, was sagt bei denen ssh -V ? Verwendest du zur Authentifizierung RSA Keys, oder auch ecdsa/ed25519?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13315
|
encbladexp schrieb: Welche SSH Version hat der Client, ...
BTW: Ich habe jetzt mit einem "steinalten" ssh-Client
:~$ ssh -V
OpenSSH_7.3p1, OpenSSL 1.0.1f 6 Jan 2014
und den 3 Servern:
:~# ssh -V
OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n 15 Mar 2022
:~ $ssh -V
OpenSSH_9.1, LibreSSL 3.6.0
:~ % ssh -V
OpenSSH_8.8p1, OpenSSL 1.1.1o-freebsd 3 May 2022
erfolgreich getestet, wenn der alte ssh-Client das:
Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes256-ctr
IdentityFile ~/.ssh/id_ed25519
benutzt.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17279
|
Korrekt, Hintergrund: RSA Keys werden von alten Clients nicht mehr SHA256 oder ähnlichem Angeboten, was moderne SSH Versionen ablehnen. Am besten ist es wenn du ecdsa oder ed25519 Keys verwendet, in jedem anderen Fall müsstest du dem Server gestatten SHA1 zu erlauben, wovon ich abraten würde. Ich will lieber nicht wissen wo du einen SSH Client von 2014 hast.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13315
|
encbladexp schrieb: Am besten ist es wenn du ecdsa oder ed25519 Keys verwendet, ...
Das habe ich doch, siehe oben:
IdentityFile ~/.ssh/id_ed25519 encbladexp schrieb: ... wo du einen SSH Client von 2014 hast.
Aus meinem Archiv. 😉
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17279
|
lubux schrieb: Aus meinem Archiv. 😉
😀 Hab dich mit dem TE verwechselt. m(
|
E-Lyptus
Anmeldungsdatum: 17. Dezember 2017
Beiträge: 149
|
|
Newbunto
(Themenstarter)
Anmeldungsdatum: 11. September 2017
Beiträge: 71
|
Das werde ich mir erst einmal in Ruhe zu Gemüte führen, vielen Dank soweit!
Wobei sich das Problem sicher auch mit einer kompatiblen AndroidApp klären ließe - z.Z. nutze ich noch ein wirklich alte und vom Playstore zugelassene esFileexplorer-Version. Kennt ihr einen anderen Fileexplorer mit weitgehend ähnlichen Funktionen? Vielen Dank für die Hilfe!
|
Newbunto
(Themenstarter)
Anmeldungsdatum: 11. September 2017
Beiträge: 71
|
Vielen Dank für die Hinweise. Ich wollte natürlich nach Möglichkeit auf dem aktuellen Sicherhheitsstand bleiben. Ich habe daher einmal versucht die Verbindung mit dem Solid Explorer (https://play.google.com/store/apps/details?id=pl.solidexplorer2&pli=1) aufzubauen. Aber zumindest in der Testversion wird auch diese abgelehnt. Nutzt den vielleicht jemand oder hat jemand einen Alternativvorschlag? Anderes Thema: Auch die Verbindung über FTPS wird seit neustem nicht mehr akzeptiert, sodass ich mit meinem Handy nun gar nicht mehr auf meinen Server zugreifen kann, was schon sehr ärgerlich ist. Ich bin für jede Hilfe sehr dankbar, denn so macht es leider keinen Spaß ☹
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17279
|
FTPS hat mit SSH nichts zu tun, ganz anderes Protokoll.
|