Ich habe jetzt die neueste Powershell 7.2.11 installiert. Jetzt kann ich ohne Probleme mit ssh auf mein NAS zugreifen.
Somit habe ich jetzt 2 Möglichkeiten, PuTTY und die Powershell.
Ich habe jetzt die neueste Powershell 7.2.11 installiert. Jetzt kann ich ohne Probleme mit ssh auf mein NAS zugreifen.
Somit habe ich jetzt 2 Möglichkeiten, PuTTY und die Powershell.
Und wie ist nun der Stand? Klappt jetzt alles?
SSH noch nicht. Ich belasse es dabei. Hab schon genug aufwand betrieben.
UPnP ist deaktiviert, keinerlei Portfreigaben mehr, QuFirewall runter und vor allem auch Software von QNAP die dauerndes Schreiben auf der HDD ermöglicht hat.
In diesem Sinne. VIelen dank für eure Mühe.
Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Becker2020 Was sollen solche kommentare? So großes MItteilungsbedürfnis?
Da bei Dir der SSH-Zugriff über die Powershell nicht funktioniert hat, wollte ich nur testen, ob der Zugriff grundsätzlich möglich ist (wie von anderen geäußert). Die älteren Versionen der Powershell konnten kein SSH.
Da bei meinen NAS der Zugriff problemlos möglich ist, liegt das Problem bei deiner Hard-/Software.
Da Du aber auf den SSH-Zugriff verzichtest, hat sich die Sache für mich erledigt.
Da bei Dir der SSH-Zugriff über die Powershell nicht funktioniert hat, wollte ich nur testen, ob der Zugriff grundsätzlich möglich ist (wie von anderen geäußert). Die älteren Versionen der Powershell konnten kein SSH.
Sry ich dachte dein Kommentar war Ironisch gemeint. Verzichten....ich hab ja keine Wahl. Mir gehen die möglichkeiten aus. Alle anderen SSH Verbindungen gehen in der PowerShell nur die zur QNAP NAS nicht. Hardware kann es doch nicht ernsthaft sein? Wenn alle anderen SSH Verbindungen gehen. Das Passwort habe ich ja auch überprüft ob es so eingegeben wird wie es soll.
(Edit: Dieser Mod ist ein kleiner nerviger Diktator....)
Wir haben hier ja nun X Probleme gleichzeitig lösen wollen... dann machen wir doch jetzt mal im Detail mit SSH weiter:
1. Bitte Screenshots von den SSH Einstellungen seitens QNAP und beim Client Verbindungsaufbau, belasse es erstmal bei Putty
2. Was genau passiert jetzt nochmal, wenn SSH Zugriff erfolgen soll?
3. Wird der richtige admin verwendet?
4. Aktiviere auch mal SFTP und versuche mit WinSCP zu verbinden... was passiert?
Evtl. wäre es hilfreich, die Ausgabe von ssh -v admin@... oder ssh -vvv admin@... zu posten.
Gruss
Auch gut... Was würde eigentlich passieren wenn man den fingerprint einmal versehentlich abgelehnt hat? Wird man beim nächsten Mal wieder gefragt oder wird die Verbindung erst gar nicht mehr aufgebaut?
... Wobei man nach dem IP Wechsel ja eigentlich erneut gefragt werden müsste...
Bin ich mir auch nicht sicher, aber ein IP-Wechsel erfordert keinen neuen Fingerprint.
Dann müsste ich alle Nase (die im Gesicht ) neue Fingerprints haben.
Wenn man auf dem Host die SSH Keys neu erstellt, dann passt der Fingerprint nicht mehr. Je nach Einstellung wird dann die Verbindung abgelehnt oder man muss den Fingerprint neu zulassen.
Beim TE könnte es auch sein, das die KEX (Key exchange algorithm) nicht stimmt und zu alt ist (oder zu neu), das habe ich in neueren Putty Versionen, da muss man dann in den Session Einstellungen die KEX Reihenfolge ändern.
Aber das steht in der Ausgabe - wenn man sie genau liest.
Gruss
1. Bitte Screenshots von den SSH Einstellungen seitens QNAP
2. Was genau passiert jetzt nochmal, wenn SSH Zugriff erfolgen soll?
3. Wird der richtige admin verwendet?
4. Aktiviere auch mal SFTP und versuche mit WinSCP zu verbinden... was passiert?
Screenshot ist beigefügt.
Es passiert das im Windows Terminal nach der Passwort eingabe Permission Denied kommt. Und wir hatten auch schon getestet ob nicht vielleicht die Sonderzeichen anders belegt sein könnten dem war aber nicht so.
SFTP ist aktiviert aber bitte nicht noch mehr Software auf meiner Kiste.
Mit admin@ kann ich mich ja nicht einloggen da dieses Konto durch das erstellen eines neuen Benutzers deaktiviert wurde und sämtliche Rechte übertragen wurden.
PS C:\Users\ghost> ssh ghost@192.168.178.237
The authenticity of host '192.168.178.237 (192.168.178.237)' can't be established.
RSA key fingerprint is SHA256:zHe8LPxPPwQkMPMHYpOMF2gx2xemT1aM4fs0yJJDrMc.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.178.237' (RSA) to the list of known hosts.
ghost@192.168.178.237's password:
Permission denied, please try again.
ghost@192.168.178.237's password:
Evtl. wäre es hilfreich, die Ausgabe von ssh -v admin@... oder ssh -vvv admin@... zu posten.
Hier einmal die Ausgabe:
PS C:\Users\ghost> ssh -v ghost@192.168.178.237
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.178.237 [192.168.178.237] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\ghost/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ecdsa_sk type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ed25519_sk type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_ed25519_sk-cert type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\ghost/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.178.237:22 as 'ghost'
debug1: load_hostkeys: fopen C:\\Users\\ghost/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:zHe8LPxPPwQkMPMHYpOMF2gx2xemT1aM4fs0yJJDrMc
debug1: load_hostkeys: fopen C:\\Users\\ghost/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.178.237' is known and matches the RSA host key.
debug1: Found key in C:\\Users\\ghost/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\ghost/.ssh/id_rsa
debug1: Will attempt key: C:\\Users\\ghost/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\ghost/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\ghost/.ssh/id_ecdsa_sk
debug1: Will attempt key: C:\\Users\\ghost/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\ghost/.ssh/id_ed25519_sk
debug1: Will attempt key: C:\\Users\\ghost/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\ghost/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\ghost/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\ghost/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\ghost/.ssh/id_ecdsa_sk
debug1: Trying private key: C:\\Users\\ghost/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\ghost/.ssh/id_ed25519_sk
debug1: Trying private key: C:\\Users\\ghost/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
Alles anzeigen
Für den User ghost hast Du SSH auch explizit erlaubt?
Und aus irgendeinem Grund wird eine (nicht existierende) Datei known_hosts2 gesucht. Eigentlich heißt die nur known_hosts.
Gruss
Jo, klingt danach, als wäre der User nicht für SSH freigegeben.
Auf dem Screenshot unter "Zugriffsberechtigung bearbeiten" muss der User gewählt werden (es sind nur admins wählbar), per Default ist es glaube ich nur admin, den alternativen admin muss man extra freigeben.
Dennoch ist das ja nur eine Art Workaround, da man mit dem alternativen admin ja nichtmal manche Diagnose (zB mdadm) durchführen kann... daher würde ich es gleich richtig machen und den admin wieder aktivieren, wenn schon SSH gewünscht ist, sonst ist das witzlos.
Die known_hosts2 sucht er bei mir übrigens auch vergeblich...
Mod: Unnötiges Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Danke für deine/eure weitere Unterstützung erstmal.
Also, ich habe das Admin Konto wieder aktiviert und dort funktioniert der Zugriff einwandfrei via SSH.
Die Zugriffsberechtigungen für Ghost stehen alle auf Grün. Trotzdem klappt der SSH Zugriff bei dem Nutzer immer noch nicht. Es könnte mir ja jetzt egal sein. ABER da is jetzt der Wurm drin und ich möchte den Raus haben. Vegan ist zwar nicht meins aber im Apfel geht mir das zu Weit.
Ok, welchen Wurm müssen wir denn jetzt aufpicken?
Falls das "grün" nicht allegorisch gemeint war: Hast Du das an der richtigen Stelle kontrolliert? Dort, wo wir meinen, ist nichts "grün".
Da gibt es nur einen Haken, der den Zugriff per SSH erlaubt.
Controlpanel - Netword and Fileservices - Telnet/SSH - Edit Access Permissions ?
Gruss
Mod: Unnötiges Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Davon hab ich gesprochen ja.
Du weißt schon, das Linux case-sensitiv ist und das ghost etwas anderes ist als Ghost?
Das gilt auch für Usernamen.
Gruss
Screenshot ist beigefügt.
...CodePS C:\Users\ghost> ssh ghost@192.168.178.237 The authenticity of host '192.168.178.237 (192.168.178.237)' can't be established. RSA key fingerprint is SHA256:zHe8LPxPPwQkMPMHYpOMF2gx2xemT1aM4fs0yJJDrMc. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.178.237' (RSA) to the list of known hosts. ghost@192.168.178.237's password: Permission denied, please try again. ghost@192.168.178.237's password:
Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Ich verschwinde dann mal und gehe in deckung..... Problem gelöst....
***Kreisch***...
Mod: Unnötiges Volltext-/Direktzitat entfernt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Hätte euch auch auffallen können
Ich muss selbst lachen... 😂.. Ich hab das so verpeilt selbst..
In diesem Sinne vielen Dank für eure Hilfe und Mühe und vor allem Geduld.
Achja und an den Mod sry fur das "Vollzitat" 🤣
Ohje
Gibt es eine Zusammenfassung für die ganzen Probleme und Lösungen?
Oder ist noch was offen?