SSH Schlüssel / passwortlose Anmeldung für rsync

S

sevY

Hi zusammen,

ich möchte gerne 'iMac' und 'Sawtooth' via SSH mit rsync synchronisieren.
Hier geht es mir um die passwortlose Anmeldung.

'iMac' ist der Bürorechner, 'Sawtooth' mein Arbeitsrechner mit einer 2. HDD für Backups.

Auf jedem Rechner existiert der Benutzer 'Yves'.

Ich habe nun wie folgt sowohl auf 'iMac' als auch auf 'Sawtooth' ein SSH Schlüsselpaar erzeugt:

Code:
ssh-keygen -t dsa -b 1024

Dann habe ich mich von 'Sawtooth' mittels SSH (und Passwort) auf 'iMac' eingeloggt, dort den Sawtooth-Yves-Pubkey (id_dsa.pub) wie folgt in das Verzeichnis ~Yves/.ssh/ auf 'iMac' kopiert:

Code:
scp id_dsa.pub Yves@iMac:/Users/Yves/.ssh/id_rsa.pub.sawtooth

Anschließend habe ich den Inhalt von id_rsa.pub.sawtooth in die Datei authorized_keys auf 'iMac' kopiert:

Code:
cat id_rsa.pub.sawtooth >> authorized_keys



Um das alles nochmal zu prüfen habe ich das lokal überprüft:

1.) Für beide Benutzer 'Yves' existiert auf jedem Rechner ein private und ein public key.
2.) Um mich passwortlos via SSH von 'Sawtooth' auf 'iMac' anmelden zu können, habe ich den public key von Yves@Sawtooth in die authorized_keys im Userverzeichnis von Yves@iMac kopiert (manuell mittels pico geprüft… ist also drin…)


Wenn ich dann nun versuche, mich mittels ssh Yves@iMac von 'Sawtooth' aus anzumelden, wird trotzdem nach meinem Passwort gefragt… wo liegt das Problem? Was mache ich falsch?


Ganz am Rande habe ich noch eine Frage zu Rsync und einem Bash-Befehl, der eine Pfadangabe mit Leerzeichen enthält:

Code:
#! /bin/bash 

#Adressbuch
rsync -rulHvpogDt Yves@iMac:/Users/Yves/Library/Application\ Support/AddressBook/ /Volumes/Archiv/iMac/Rsync/Library/Application\ Support/AddressBook/


/*
receiving file list ... link_stat "/Users/Yves/Library/Application" failed: No such file or directory
link_stat "/Users/Yves/Support/AddressBook/." failed: No such file or directory
done
client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
rsync error: some files could not be transferred (code 23) at main.c(660)
*/

Eigentlich ist das Leerzeichen doch korrekt escaped (\ ), oder?


Liebe Grüße

Yves
 
Du kannst den Pfad doch komplett in Anführungszeichen schreiben, dann musst Du doch nicht jedes Zeichen excapen...
 
Yves schrieb:
Wenn ich dann nun versuche, mich mittels ssh Yves@iMac von 'Sawtooth' aus anzumelden, wird trotzdem nach meinem Passwort gefragt… wo liegt das Problem? Was mache ich falsch?

das ist normal, du musst ja erst einmal den private key entschlüsseln mit dem passwort. um das zu umgehen, müsstest du einen key ohne passwort machen. das ist aber SEHR gefährlich ;)

oder du hast in der sshd_config das anmelden per key nicht erlaubt...
 
Die Datei "authorized_Keys "dient zur Aufbewahrung von Schlüsseln, die zusammen mit der SSH Protokollversion 1 verwendet werden. Mittlerweise wird SSH2 benutzt (aber heißen tut das ganze immer noch "ssh"). Hänge dazu den public key an die Datei "authorized_keys2" anstatt "authorized_keys" an (wenn diese nicht existiert, mußt Du sie im Verzeichnis ~/.ssh anlegen). Andererseits kannst Du ssh mit der Option "-1" zwingen, Protokoll 1 zu benutzen, aber davon ist abzuraten...
Achte darauf, daß der Client den richtigen private key findet und das die Dateirechte daraufrichtig gesetzt sind, sonst weigert sich shh, den key zu benutzen!

Viel Erfolg,

Kay
 
Zuletzt bearbeitet:
oneOeight schrieb:
das ist normal, du musst ja erst einmal den private key entschlüsseln mit dem passwort. um das zu umgehen, müsstest du einen key ohne passwort machen. das ist aber SEHR gefährlich ;)

oder du hast in der sshd_config das anmelden per key nicht erlaubt...

Der Key ist ohne Passwort…

Die sshd_config auf 'iMac' sieht so aus:

Code:
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#HostKey /etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 120
#PermitRootLogin yes
#StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /Users/Yves/.ssh/authorized_keys

# rhosts authentication should not be used
#RhostsAuthentication no
# 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
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication 
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt no

#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes

#MaxStartups 10
# no default banner path
#Banner /some/path
VerifyReverseMapping yes

# override default of no subsystems
Subsystem	sftp	/usr/libexec/sftp-server
 
der_Kay schrieb:
Hänge dazu den public key an die Datei "authorized_keys2" anstatt "authorized_keys" an (wenn diese nicht existiert, mußt Du sie im Verzeichnis ~/.ssh anlegen).
Hilft auch nicht.

der_Kay schrieb:
Achte darauf, daß der Client den richtigen private key findet und das die Dateirechte daraufrichtig gesetzt sind, sonst weigert sich shh, den key zu benutzen!

Hmm… nachdem ich in der config (siehe oben) die Werte geändert habe, bekomme ich „… connection refused …“.

[cd]
ssh Yves@iMac -i /Users/Yves/.ssh/id_dsa
[/cd]

Den Key hab ich auch chmod 0600

Yves
 
Hmm… ich hab das nun nochmal von vorne gemacht…

1.) Auf Server und Client ein Schlüsselpaar erzeugt.
2.) chmod 600 für den private key, 644 für den public key
3.) Vom Client den public key auf den Server kopiert und in authorized_keys und authorized_keys2 umbenannt.
4.) Auf dem Server die sshd_config wie folgt angepasst:

Code:
HostKey /Users/Yves/.ssh/id_dsa
PubkeyAuthentication yes
AuthorizedKeysFile /Users/Yves/.ssh/authorized_keys
VerifyReverseMapping yes
Subsystem	sftp	/usr/libexec/sftp-server

SSH Daemon neugestartet.


5.) Versucht, vom Client mit dem Server zu connecten:

Code:
ssh Yves@iMac -i /Users/Yves/.ssh/id_dsa

Passwortabfrage erscheint… Schlüssel wird ignoriert.

Yves
 
Ich habe nun einen Troubleshooting-Guide durchgearbeitet… und in der config „PermitEmptyPassword“ eingetragen.

Nun bekomme ich das:

Code:
ssh -i /Users/Yves/.ssh/id_dsa.pub -l Yves iMac
ssh_exchange_identification: Connection closed by remote host
 
die Option "-i" ist für den privaten Schlüssel und wird nur benötigt, wenn Du mehrere private Schlüssel unterhältst.
 
Zuletzt bearbeitet:
Machs lieber mal von vorne und nur in _EINE_ Richtung:

z.B. von iMac nach Sawtooth:
1.) auf saw einloggen, root werden, aus der known_hosts iMac-Eintrag, und alle authorized_keys? löschen (oder die Schlüssel manuell aus dem File deleten).
2.) _NUR_ auf iMac Schlüsselpaar erzeugen
3.) von iMac ~/.ssh/id_dsa.pub.saw nach sawtooth kopieren und nur dort "cat "id_dsa.pub.saw >> .ssh/authorized_keys2"
4.) neues ssh von iMac nach saw ...und das muß nun laufen!
So habe ich meinen passwortlosen ssh innerhalb unseres VPN eingerichtet.
 
Oh weh… ich hab' das mal nach deiner Anleitung gemacht… Problem besteht.
Gibt es einen SSH Helper (außer den gleichnamigen…), der einem behilflich ist?

Yves
 
hmmm was der Kay da schreibt kenne ich so nicht!

Also bei mir mache ich das immer so.

Auf dem Quellrechner mit ssh_keygen ein schlüsselpaar anlegen

Auf dem Zielrechner in ~/.ssh/authorized_keys deinen public_key eintragen.


Damit du dich jetzt ohne PASSWORTABFRAGE am Zielrechner anmelden kannst musst du auf dem Quellrechner noch einen SSH-Agent einrichten.


Diesem musst du deinen Private Key mitteilen und dich einmal authentifizieren. danach kannst du solange der Agent läuft dich ohhne Passwort an allen Systemen anmelden bei denen dein Public Key hinterlegt ist.

Als ssh-agent nutze ich den

hier den noch in die Startobjekte aufnehmen in den Einstellungen festlegen welche Identität stamdardmäßig geladen werden soll und das Passwort deines Private Keys dem MAC Schlüsselbubd hinzufügen. Danach solltest du nie wieder dein
Passwort für die Zielsysteme eingeben müssen.

LG Worf
 
Zuletzt bearbeitet von einem Moderator:
Hey Yves!

Um dich noch mehr zu verwirren, noch eine Anleitung! :D

1. SSH2 Public Key erstellen:

Code:
ssh-keygen -t rsa
3x mit Enter bestätigen

Falls man aus irgendwelchen Gründen einen ssh1 Key braucht: (SSH1 Public Key erstellen:

Code:
ssh-keygen -t rsa1

3x mit Enter bestätigen)


2.

Code:
cat ~/.ssh/id_rsa.pub

3. Den Key vom ersten bis zum letzten Zeichen in die Zwischenablage kopieren (inkl. ssh-rsa bis zum usernamen, aber ohne @rechnername.localhost)

4. mit SSH auf dem Rechner einloggen
(dort muss wie unter 1. bereits ein public key angelegt worden sein)

5.

Code:
cd ~/.ssh

6.
Code:
pico -w authorized_keys2
(eine neue Datei erstellen)

7. Den Public Key in das Document authorized_keys2 kopieren, Zeilenumbrüche entfernen und abspeichern

8. Erneut einloggen


============

Hast du noch einen weiteren Rechner? Prima! :D

Dann:

Wenn du jetzt eine weitere ssh Verbindung zu einem anderen Rechner aufbauen willst, muss der eigene RSA nicht noch einmal erzeugt werden. Der eigene Public Key wurde einmalig erzeugt und ist in der Datei /Users/anwendername/.ssh/id_rsa.pub gespeichert.

Für den nächsten Rechner, zu dem man mit dem aktuellen User eine ssh Verbindung aufbauen will, lässt man sich daher mit cat ~/.ssh/id_rsa.pub den eigenen public Keynoch einmal ausgeben.


Weiter geht es dann mit Punkt 3.


:)

Dylan
 
Zuletzt bearbeitet:
Laut Console.app's Logdateien scheint etwas mit den Rechten des Ordners ~/.ssh nicht zu stimmen…

Gebe ich allen Ordnern 0644 kann der Schlüssel nicht mehr gefunden werden.
Bei 0774 kann man dann auch die Ordner wieder öffnen, allerdings heisst es dan wiederum, das der falsche Mode gesetzt ist.

Hehe… das restriktivste was geht ist: 0474, dann komm ich noch in den Ordner.
Alles andere sperrt aus.

Yves
 
IMHO sollte die Rechte der ssh betreffenden Dateien wie folgt aussehen

PowerMAC:~ rl$ ls -ld .ssh
drwx------ 5 rl rl 170 30 Mar 20:19 .ssh
PowerMAC:~ rl$ ls -l .ssh
total 24
-rw------- 1 rl rl 1264 19 Dec 21:35 id_dsa
-rw-r--r-- 1 rl rl 1119 19 Dec 21:35 id_dsa.pub
-rw-r--r-- 1 rl rl 1516 28 Mar 17:44 known_hosts
PowerMAC:~ rl$



Die ssh Software ist da mit recht sehr restriktiv.


LG Worf
 
Yves schrieb:
Laut Console.app's Logdateien scheint etwas mit den Rechten des Ordners ~/.ssh nicht zu stimmen…

Gebe ich allen Ordnern 0644 kann der Schlüssel nicht mehr gefunden werden.
Bei 0774 kann man dann auch die Ordner wieder öffnen, allerdings heisst es dan wiederum, das der falsche Mode gesetzt ist.

Hehe… das restriktivste was geht ist: 0474, dann komm ich noch in den Ordner.
Alles andere sperrt aus.

Yves

kann es vielleicht sein das du das mit den Unix rechten noch nicht so ganz verstanden hast ?

was bitte willst du denn damit erreichen ? 0474 und wieso ist das restriktiver als 0700 ?
 
Oh jemineh,

Es tut mir echt leid, das das bei Dir nicht auf Anhieb klappen will. Grad heute hab ich noch einen passwortlosen Zugang eingerichtet, indem ich nur den public key an die authorized_keys2 des Zielrechners gecattet hab. Dabei stimmten auf den Rechnern weder die Benutzernamen noch die Passwörter noch BS`e überrein, sondern die Authentifizierung läuft einzig und allein über den private key auf meiner Seite ohne irgendwelche Optionen...
Die Rechtemaske stimmt mit der von worf überein, nur eben "authorized_keys2"
Die ssh_config nur aus "Host *" der Rest ist auskommentiert. sshd_config hat einzig und allein das X11Forwarding aktiviert und eine Option für sftp...

Gruß,

Kay
 
Yves, nach welchen Passwort wird denn gefragt? Nach dem des Keys oder nach dem User-Passwort?

Es könnte sein, dass das mit den Keys nicht funktioniert und der ssh somit auf Password-Authentication zurückfällt...
 
Zurück
Oben Unten