SSH Verbindungsprobleme

[schreckag]

Hej liebe Gemeinde,

ich versuche mich via Terminal nach dem Schema
ssh -p 22 nutzer@server

bei einem Server anzumelden. Ich gebe das Passwort ein, es wird als falsch abgewiesen.

Wenn ich mich auf einem anderen Mac anmelden möchte, klappt das. Woran kann das liegen?

weiterhin habe ich auf bei meinem FTP Client (Cyberduck) Probleme mich via SSH/ SFTP zu verbinden.

System ist OSX 10.15.2
LG

 

[oneOeight]

eventuell lässt der server keine passwort anmeldung zu und nur pubkey?
oder passwörter nur von bestimmten IP ranges, um diese ganze brute force passwort attacken abzumildern.
schon mal mit ssh -v (je mehr v desto mehr infos gibt es) anzumelden?
vielleicht kann man aus den debug meldungen was lesen, warum das passwort nicht angenommen wird.

 

[schreckag]

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: /etc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to server [xxx.xxx.xxx.xx] port 22.
debug1: Connection established.
debug1: identity file /Users/Nutzer/.ssh/id_rsa type -1
debug1: identity file /Users/Nutzer/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Nutzer/.ssh/id_dsa type -1
debug1: identity file /Users/Nutzer/.ssh/id_dsa-cert type -1
debug1: identity file /Users/Nutzer/.ssh/id_ecdsa type -1
debug1: identity file /Users/Nutzer/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/Nutzer/.ssh/id_ed25519 type -1
debug1: identity file /Users/Nutzer/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/Nutzer/.ssh/id_xmss type -1
debug1: identity file /Users/Nutzer/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to server:22 as 'benutzer'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-ed25519
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: Server host key: ssh-ed25519 SHA256:SnrnL8/yjWkgdQrQdOnm070w/qq7dynDnj1itHeQGxE
debug1: Host 'servername' is known and matches the ED25519 host key.
debug1: Found key in /Users/Nutzer/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /Users/Nutzer/.ssh/id_rsa
debug1: Will attempt key: /Users/Nutzer/.ssh/id_dsa
debug1: Will attempt key: /Users/Nutzer/.ssh/id_ecdsa
debug1: Will attempt key: /Users/Nutzer/.ssh/id_ed25519
debug1: Will attempt key: /Users/Nutzer/.ssh/id_xmss
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/Nutzer/.ssh/id_rsa
debug1: Trying private key: /Users/Nutzer/.ssh/id_dsa
debug1: Trying private key: /Users/Nutzer/.ssh/id_ecdsa
debug1: Trying private key: /Users/Nutzer/.ssh/id_ed25519
debug1: Trying private key: /Users/Nutzer/.ssh/id_xmss
debug1: Next authentication method: password
benutzer@server's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.

Was kann ich mit dieser Information anfangen?

 

[cyberfeller]

Ich würd mal in das Log vom Server schauen
"Permission denied" kann im Prinzip ne Menge Gründe haben

 

[oneOeight]

wenn du dich beim passwort jetzt nicht vertippt hast, dann liegt es eventuell an der sshd config auf dem server bzw dessen PAM config?
muss man halt da mal auf dem server gucken, aber wenn du nicht drauf kommst, geht das ja eh nicht.

 

[schreckag]

ich habe das Problem auf einen Mac eingegrenzt. Wenn ich einen anderen Mac nehme klappt das. Also ich bin in der gleichen Netzwerkumgebung. Es geht nur nicht auf diesem einen. Also kann ich das Problem Server doch ausschließen, oder liege ich das falsch? Tippfehler kann ich sicher ausschließen. Also es einmal falsch eingeben, klar, aber nicht 30 Mal

 

[oneOeight]

könnte man meinen, auf dem mac wo es geht, läuft auf auch die die gleiche OS X version bzw die ssh version?
könnte eine inkompabilität zwischen den ssh versionen sein.
oder mit der locale im terminal, falls du sonderzeichen oder umlaute im passwort hast.

kannst ja mal ssh -vvv machen, da kriegst noch mehr debug output, vielleicht steht da ja was drin.
aber falls das hier posten willst, dann bitte mit code tags, geht mit dem plus symbol/einfügen über der antwort box und dann dort code auswählen.

 

[bowman]

...bei der Anmeldung probiert der Mac ja alle möglichen Keys durch - warum eigentlich so viele? Und: Ist der Richtige dabei? Vergleiche mal die Keys im .ssh-Verzeichnis (versteckt) auf dem Mac, bei dem es geht, mit den Keys auf dem Mac bei dem das scheitert.

Überhaupt finde ich den Server komisch konfiguriert: Wenn man ssh-Key-Anmeldungen konfiguriert, schaltet man üblicherweise die Anmeldemöglichkeit per Passwort ab die bei deinem Server wohl noch aktiv ist, sonst ist der Sicherheitsgewinn durch die Keys irgendwie für die Füsse (damit ist nicht die Abfrage eines Passwortes bei der Key-Anmeldung gemeint)...

 

[schreckag]

. .ssh-Verzeichnis (versteckt) auf dem Mac, bei dem es geht, mit den Keys auf dem Mac bei dem das scheitert.
...

du meinst die known_hosts? Die habe ich schon leergemacht

 

[bowman]

du meinst die known_hosts? Die habe ich schon leergemacht

...nein, ich meine die private keys die in .ssh im Homeverzeichnis des Nutzers liegen, deren Dateinamen meist mit id_rsa anfangen und die nicht mit .pub enden...

 

[maceis]

Vergleich doch mal die ssh config Datei des Mac, bei dem es geht mit der bei dem es nicht geht.
Verwende ggf. mal testweise die selbe config Datei auf beiden Rechnern (die "alte" dabei nicht löschen).

Gruß
maceis

PS: das -p 22 kannst Du weglassen, weil 22 ohnehin der Standardport ist.

 

[schreckag]

...nein, ich meine die private keys die in .ssh im Homeverzeichnis des Nutzers liegen, deren Dateinamen meist mit id_rsa anfangen und die nicht mit .pub enden...

in diesem Verzeichnis liegt lediglich die known_hosts

Ich habe es heute wieder auf dem anderen Mac versucht, nun geht das auch nicht. Ging also genau einmal. Könnte der Fehler durch die Fritzbox verursacht werden, weil sie vielleicht ssh verhindert? SFTP Verbindung funktioniert im übrigen

 

[win2mac]

Du schreibst irgendwie wirres Zeug, sorry. Du schreibst dochh bei #6, dass du in der gleichen Netzwerkumgebung bist. Was soll das mit der Fritzbox jetzt zu tun haben? Bist Du jetzt local oder soll es übers Internet gehen?
Versuch mal vernünftig zu erklären was Du genau machen willst und welche Rechner/OS beteiligt sind, etc.
Der Rest ist nur Rumraterei

 

[oneOeight]

Ich habe es heute wieder auf dem anderen Mac versucht, nun geht das auch nicht. Ging also genau einmal. Könnte der Fehler durch die Fritzbox verursacht werden, weil sie vielleicht ssh verhindert? SFTP Verbindung funktioniert im übrigen

du kriegst doch eine verbindung hin, was halt nicht klappt ist der login.
die fritzbox unterbindet ssh nicht, wie du siehst.
tendenziell scheint mir das immer noch ein problem auf dem server zu sein.
lässt der klartext passwörter getunnelt nicht zu (PasswordAuthentication no)?
oder du musst auf der client seite noch irgendein modul laden, dass das passwort halt als hash übertragen wird.

ohne die entsprechenden configs und log files, ist das aber alles nur reines raten.

 

[schreckag]

Lieben Dank,
habe den Fehler gefunden. Üblicherweise sitzt der Fehler häufig vor dem Bildschirm. Ich habe einen Schreibfehler mitgeschleppt so das der Benutzname falsch war. Auf dem anderen MAC hatte ich das mit der Hand abgetippt also hat das logischerweise geklappt. Danke für die Anregungen, habe gleich mal einiges gelernt.

LG und einen angenehmen Start ins Jahr 2020