SSH Zugang ohne Passwort

W

wizzardxx

Mitglied
Hallo zusammen,

ich habe folgendes Problem:
Ich möchte mich von einem Linux Server zu einem anderen per shh ohne Passwort abfrage verbinden. Was immer ich auch mache kommt immer wieder die frage nach dem Passwort.

Fogendes habe ich gemacht:

1. Server = Samba Fileserver -Fedora Core 8
2. Server = Backupserver -Fedora Core 8

Auf dem Fileserver den Key erzeugt mit: ssh-keygen -t rsa -b 1024
Alles mit Enter bestätigt

Auf dem Backupserver zuvor im user home Verzeichnis einen Ornder .ssh angelegt.

Den id_rsa.pub vom Fileserver in das home verzeichnis des users kopiert
scp ~/.ssh/id_rsa.pub **********nt

passwort des users backup eingegen.

in der console steht: id_rsa.pub 100% 255 0,2KB/s 00:00

Auf den Backupserver einlogen: ssh backup@192.168.1.221
Passwort eingeben - Enter

Ins home verzeichnes des users wechseln wo die Datei liegt.

cd /home/backup/.ssh

Den Schlüssel bekannt machen:

cat id_rsa.client >> authorized_keys
Enter

Die id_rsa.client löschen
rm id_rsa.client
exit

Wenn ich mich jetzt vom Fileserver mit:
ssh backup@192.168.1.221
einloggen will kommt trotzdem wieder die Frage nach dem Passwort.

Was mache ich bloß falsch? Ich sitze jetzt schon den 2.Tag daran.
 
was is der sinn von nem ssh server ohne passwort?
dann nimm lieber telnet^^
 
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Sind beide auskommentiert
ssh -v sagt folgendes:

OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006
usage: ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command]

@Floetkowski
ssh ohne passwort brauche ich für ein automatisches Backup welches zu einer bestimmten Uhrzeit per rsync läuft.
 
*In Glaskugel blick*

Vermutlich will Rvg die Version von ssh wissen, deshalb

Code: 
ssh -V
Greetz,

RM

P.S. @Floetkowski

Du möchtest Dich darüber informieren, wieso SSH mit einer Authentifizierung über Pubkeys

a) nicht zwingend eine lokale Passphrase (!=Passwort) und erst recht kein Passwort benötigt

und

b) trotzdem ein höheres Maß an Sicherheit gegenüber einem Remote-Angriff als _JEDE_ Verbindung über telnet bietet.
 
Ok dann hier nochmal die kurzfassung ;-)

OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006
 
Rain_Maker schrieb:
*In Glaskugel blick*
Zum Vergrößern anklicken....

Ich will auch mal ;)
Ich glaube Rvg wollte eher dass er mal mit aktiviertem debug output (-v) versucht eine Verbindung herzustellen, das koennte dann naemlich eventuell Aufschluss darueber geben was falsch laeuft.

mfg,
bytepool
 
Was beudetet dieses debug output (-v)?
Was genau muss man da machen?
 
*hust* sorry, japp letzteres. wobei ich mir vorstellen kann, das pam da seine finger drin hat
 
Den Parameter -v _zusätzlich_ zu den anderen Angaben hinzufügen, die man sonst beim Login eingibt.

Greetz,

RM
 
Oh ha... ist ja krass.

[root@fileserver ~]# ssh backup@192.168.1.221 -v
OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.221 [192.168.1.221] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.221' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
Address 192.168.1.221 maps to localhost, but this does not map back to the addre ss - POSSIBLE BREAK-IN ATTEMPT!
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


debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
backup@192.168.1.221's password:
 
die letzte zeile des logs sagt wohl aus, dass du passwort-logins nicht verboten hast

vi /etc/ssh/sshd_config:
Code: 
  Wir deaktivieren die kennwortbasierte Authentifizierung und verwenden nur noch die auf dem Austausch des öffentlichen Schlüssels basierende Authentifizierung, die wir im letzten Abschnitt eingerichtet haben.

# disable password authentication 
PasswordAuthentication no

habe ich aus der debian-anleitung, an der man sich meiner Meinung ganz gut orientieren kann: http://www.debianhowto.de/doku.php/de:howtos:woody:ssh

was mir auch noch auffällt:
Code: 
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
Address 192.168.1.221 maps to localhost, but this does not map back to the addre ss - POSSIBLE BREAK-IN ATTEMPT!
sieht so aus als ob du nen zertifikat erstellt hast, ich denke, der client muss nen zertifikat erstellen und du das zur liste hinzufügen... meine ich zumindest beim link gelesen zu haben

mfg
 
# disable password authentication
PasswordAuthentication no

Habe ich gemacht. Ergebnis ist aber das gleiche.
Wenn ich das beim Backupserver mache dann kann ich mich garnicht mehr per ssh einloggen.

Ich habe das vor einem Jahr schon mal 2 Redhat 9 Kisten gemacht und da klappte das auf anhieb. Hatte das extra noch mal schriftlich Dokumentiert falls ich es noch mal brauche. Fedora Core 8 muckt jetzt jedoch.
 
Zuletzt bearbeitet:
hi,

wizzardxx schrieb:
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
Zum Vergrößern anklicken....

Sind die Pfade denn korrekt? Ich frage weil du im ersten Post alle Schritte nur mit ~ beschrieben hast, aber nicht gesagt hast als wer du angemeldet warst.

mfg,
bytepool
 
Das hier liegt im root/.ssh Verzeichnis auf dem Filserver wo ich den Key erstellt habe (als root):

[root@fileserver .ssh]# ls
id_rsa id_rsa.pub known_hosts

Und auf dem Backupserver liegt die authorized_keys
in /home/backup/.ssh

Den schlüssel habe ich mit dem user backup bekannt gemacht.
Alos cat /home/backups/.ssh/id_rsa.client >> authorized_keys
 
Hallo subzero17.
Ich mir deine Anleitung durchgelsen. Genau so habe ich es gemacht.
Bis auf authorized_keys2. Ist es denn ein Unterschied ob man authorized_keys oder authorized_keys2 macht? Und ich habe den Key als user ohne root rechte öffentlich gemacht.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Das gibts nicht. Ich habe das ganze jetzt als root auf dem Backupserver gemacht.
Den Key im root/.ssh Verzeichnis bekannt gemacht und jetzt funktioniert es.
Aber wieso klappt das nicht mit einem user ohne root rechte????
Mit redhat9 ging das.
 
Zuletzt bearbeitet:
hi wizzardxx...

bei mir klappt das unter ubuntu mit jedem user. falls ich es überlesen haben sollte, sorry für die folgende frage... welches linux nutzt du?
 
Ich habe meine 2 Kisten jetzt von Redhat9 auf Fedora Core8 umgestellt.
Bei Redhat9 hatte ich auch keine Probleme mit normalen usern.
 
Anmelden, um zu antworten.

Ähnliche Themen

Samba 4 Gast Zugang unter Ubuntu funktioniert nicht
Samba 4 Gast Zugang unter Ubuntu funktioniert nicht: Hallo zusammen, ich habe unter Ubuntu 14.04 meinen Samba Server konfiguriert wie hier beschrieben um einen Gast Zugang zu einer Freigabe zu erlauben...

rsnapshot und ein Rechteproblem?
rsnapshot und ein Rechteproblem?: [gelöst] rsnapshot und ein Rechteproblem? Zugegebenermaßen ich bin ziemlich neu was rsnapshot angeht (rsync kam schon früher zum Einsatz), hab deswegen...

SSH per DSA Keyfile ohne Passwort
SSH per DSA Keyfile ohne Passwort: Hallo, ich versuche nun schon seit knapp einer Woche eine SSH Verbindung zu einem Linuxrechner aufzubauen ohne eine Passwort eingeben zu müssen. Ich habe...

ssh verbindung mit sich selbst
ssh verbindung mit sich selbst: ich benötige eine ssh verbindung ohne passworteingabe von einem rechner mit sich selbst. distri: ubuntu 9.04 habe das heute morgens auf einem anderen...

Ein paar Fragen von einem Anfänger
Ein paar Fragen von einem Anfänger: Hallo zusammen, Ich bin noch etwas frisch in der Linuxwelt und hätte zu beginn ein paar kleine Fragen... vorab. ich Frage hier nur das, was ich in der...

Neueste Themen

Zurück
Oben