ComputerBase Menü
Aktuelles

ssh ohne Passwortabfrage funktioniert nicht

Crunkmaster

Crunkmaster

Lt. Commander
Registriert
Aug. 2003
Beiträge
1.867
Moin,

Ich hab nen kleines Problem, undzwar wollte ich einen ssh-Zguriff auf einen anderen Rechner realisieren, jedoch ohne Passwort-Abfrage.

Ich hab eine passende Anleitung gefunden und diese auch strikt befolgt, jedoch muss ich trotzdem ein Passwort eingeben wenn ich mich per ssh verbinde...

also ich hab zuerst mal 3 Keys erstellt (-N für keine Passphrase)

ssh-keygen -t dsa -N ""

ssh-keygen -t rsa -N ""

ssh-keygen -t rsa1 -N ""

dann hab ich die 3 ".pub" Dateien auf den 2. Rechner kopiert per

scp *.pub remote@IP:~/.ssh/ (in diesem Ordner lag nur die known_hosts)

Anschließend per ssh auf den 2. Rechner eingeloggt und

cat ~/.ssh/id*.pub >> ~/.ssh/authorized_keys
cat ~/.ssh/*sa.pub >> ~/.ssh/authorized_keys2

ausgeführt. die 2 authorized_keys dateien wurden erstellt und es steht auch was drin.
Aber nach nem Logout und anschließendem ssh login wird trotzdem das Passwort abgefragt.

was mache ich falsch, bzw. an was könnte es liegen?
Ich bin noch recht neu in der Linux Welt :)
 
Ist in der SSH config eingestellt, dass das authorized_keys File den default Keychallange beinhaltet?

Welche Version von SSH nutzt du? Welche Linux Version?
 
Da das Passwort abgefragt wird und nicht die Passphrase funktioniert etwas mit dem pubkey Verfahren noch nicht.

Außerdem solltest du deinen private key mit einem passphrase schützen.

Gib die Option -vv beim verbinden mit ssh an, um zu sehen woran es liegt.
 
also der Rechner der den Zugriff benötigt läuft mit OEL 5.2, die anderen Systeme haben unterschiedliche OS, von OEL 4.6 bis zu CentOS 5.2. Ist das wirklich ausschlaggebend? Ich dachte diese Möglichkeit wäre universell einsetzbar, da wir hier wie gesagt 2-4 unterschiedliche (, ältere) Systeme haben...

also in der ssh_config finde ich keinen entsprechenden Eintrag, muss ich da evtl. noch Zeilen hinzufügen?

Code: 
#       $OpenBSD: ssh_config,v 1.21 2005/12/06 22:38:27 reyk Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL

@arterius:
also mit dem parameter -vv kommt folgendes raus:
Code: 
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.9.201.191 [192.9.201.191] port 22.
debug1: Connection established.
debug1: identity file /home/nagios/.ssh/identity type 0
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/nagios/.ssh/id_rsa type 1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/nagios/.ssh/id_dsa type 2
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 131/256
debug2: bits set: 506/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.9.201.191' is known and matches the RSA host key.
debug1: Found key in /home/nagios/.ssh/known_hosts:1
debug2: bits set: 494/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/nagios/.ssh/id_rsa (0x900fe58)
debug2: key: /home/nagios/.ssh/id_dsa (0x900fe70)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Offering public key: /home/nagios/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /home/nagios/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
 
Zuletzt bearbeitet:
Anscheinend probiert er die Public keys durch, aber akzeptiert sie nicht.

Ich vermute, dass er das Schlüsselformat nicht akzeptiert. Probier mal openssh-keygen.

ssh-keygen und openssh-keygen erzeugen verschiedene Schlüsselformate. Das erste hat mehrere Zeilenumbrüche im Schlüssel das zweite nicht.

Wieso brauchst du eigentlich drei verschieden Schlüssel und warum nutzt du keinen passphrase in Verbindung mit ssh-agent/keychain ?
 
sorry ich hatte zwischenzeitlich ein anderes wichtiges Projekt, und schier keine Zeit mehr dafür...

Ich habe mich an dieses Tutorial gehalten.
Ich will mit Nagios einen Check über SSH auf einem Remote Rechner machen, da ich auf manche Systeme keine Plugins installieren kann. Leider habe ich 0 Ahnung von diesem SSH Key-Prinzip, da ich selbst praktisch noch Linux-Laie bin.
Zum Thema Passphrase siehe Tutorial, dort stand dass man es so machen soll und es gewollt ist (Vermutlich, da der Check-Befehl von Nagios sonst nicht richtig funktioniert?).
Warum ich 3 Schlüssel benötige kann ich dir auch nicht sagen, da ich einfach stupide dem Tutorial gefolgt bin :)
Mein Ziel ist es jedoch, einmalig einen Schlüssel zu erstellen und diesen dann auf verschiedene Linux-OS zu kopieren um dann Überprüfungen/Befehle ohne Passwortabfrage realisieren zu können. Vielleicht hast du da ein besseres Tutorial für mich?
Bitte erwähne dabei auch logische Dinge, die einem Linux-Laien vielleicht nicht sofort einfallen würden :)

Eine andere Frage, ändert sich dieser "Fingerprint" meines Systems, wenn ich das Passwort für den Benutzer (der die SSH-Keys erstellt hat) ändere? Also kann ich danach immernoch ohne Passwortabfrage auf das Ziel-System, oder muss ich dann wieder neue Keys erstellen? Nicht dass ich dieses SSH Thema zum Laufen bekomme und später wieder Probleme hab, nur weil ich sowas nicht beachtet habe...
 
Jetzt weiß man, was du vorhast, aber denken sollten man noch selber.

3 verschieden keys sind unnötig, nimm einen rsa/das key, das reicht.
Beide haben Vor- und Nachteile, Infos gibt es darüber genug.

Ein passphrase macht die Sache ein wenig schwieriger, aber dafür sicherer.

Wenn man den ssh-agent/keychain richtig einrichtet, muss man ihn nur einmal starten und alle ssh Verbindgungen laufen ohne passphrase ab.

Der fingerprint wird dazu benutzt um den Rechner zu identifizieren, bei einer "man in the middle attack" wird man gewarnt, falls sich der fingerprint geändert hat, aber nur wenn das auch eingestellt ist.

Der key wird dadruch nicht unbrauchbar, nur muss er im home Verzeichnis der jeweiligen Benutzers liegen.
 
So habs nun hinbekommen, lag wohl irgendwie an der authorized_keys, jedenfalls hab ich nun nur nen DSA Schlüssel erstellt, diesen per ssh-copy-id auf den Ziel-Host übertragen und es funzt...

zum Thema Passphrase hab ich auch was gefunden
Damit der Login-Prozess ohne Passwortabfrage funktionieren kann, darf der private Key nicht mit einer Passphrase verschlüsselt werden, andernfalls würde statt des Passworts für den Zielhost nun nach dem Passwort zum Entschlüsseln des privaten Keys gefragt, was auch wieder eine Interaktion des Benutzers erfordert und den automatisierten Einsatz verhindert (Ausnahme: Einsatz des ssh-agents)
Zum Vergrößern anklicken....
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

ShadowDragon
  • Gelöst
TrueNAS: rsync über SSH in die Cloud (Backups)
Antworten
3
Aufrufe
4.627
ShadowDragon
ShadowDragon
A
SSH-Key wird trotz Hinterlegung bei Provider nicht genommen.
Antworten
14
Aufrufe
2.665
up.whatever
up.whatever
Woodz
Bash Dateitransfer mit scp und sshpass funktioniert nicht
Antworten
5
Aufrufe
2.264
sandreas
S
K
SSH-Sitzung fragt nach Passwort obwohl passwortlose Anmeldung funktioniert
Antworten
6
Aufrufe
3.247
Sykehouse
Sykehouse
S
iPhone als Hotspot funktioniert nicht
Antworten
10
Aufrufe
1.762
Goldsmith
Goldsmith

Passend zum Thema

Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 165 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz