Bekijk Volledige Versie : SSH public / private key
Ik wil dus een public / private key mechanisme opzetten voor een rsync.
Ik heb deze tutorial gevolgd: http://www.howtomonster.com/2007/08/08/how-to-sync-data-between-2-servers-automatically/
alleen wat hier niet duidelijk uit blijkt is of dat de user ook daadwerkelijk moet bestaan op beide systemen. Hij blijft mij namelijk vragen om een wachtwoord terwijl ik geen wachtwoord heb opgegeven tijdens het aanmaken van de SSH keys.
marsipulami
15/09/10, 10:48
zonder naar de tutorial te kijken, heb je misschien een passphrase opgegeven waar hij nu om vraagt?
Nee, ik heb wel de user toegevoegd via useradd, echter heb ik deze zojuist weer verwijderd maar dat lijkt geen verschil te maken?
Je hebt hem wel correct genoemd in de .ssh folder? En als correcte user geupload?
Naar mijn weten moet de user enkel op de doel server bestaan, dus waar je op inlogt.
Je hebt hem wel correct genoemd in de .ssh folder? En als correcte user geupload?
Naar mijn weten moet de user enkel op de doel server bestaan, dus waar je op inlogt.
Het volgende heb ik:
source server:
/home/backupuser/.ssh (id_rsa, id_rsa.pub, known_hosts) allemaal toegekend aan backupuser
backup server:
/home/backupuser/.ssh (authorized_keys, known_hosts) allemaal toegekend aan backupuser
En wat staat er in de /var/log/auth.log? Hier komt ook te staan of users niet bestaan en/of de file rechten van de files in de .ssh directory niet juist zijn, bij een inlog poging.
Daarnaast moet in /etc/ssh/sshd_config ook iets van RSAAuthentication yes PubkeyAuthentication yes staan en actief zijn in de draaiende sshd, maar dat staat ook in de howto (AuthorizedKeysFile staat default al goed).
en in je authorized_keys staat wel de inhoud van je id_rsa.pub ?
/var/log/auth.log heb ik niet, in /var/log/secure komt alleen 'closed connection' bij het beëindigen van de ssh connectie.
sshd_config op backupserver is inderdaad aangepast volgens tutorial.
en in je authorized_keys staat wel de inhoud van je id_rsa.pub ?
Yes, deze heb ik gekopieerd vanaf de source server en toen in authorized_keys geplaatst. Het enige waar ik over twijfel is of de hostname wel klopt, daar staat namelijk de short hosname.
hostname is niet van belang in die file
geen auth.log, dan gebruik je vast centos
probeer eens in te loggen en kijk met ls -altr welke log file nog meer wijzigt, zal toch ergens een melding moeten komen wat er mis gaat
Is een CentOS machine inderdaad.
Alleen de /var/log/secure wijzigt, daar komt alleen in Connection closed by <ipadres> zodra ik mijn ssh poging afbreek vanaf de source server gezien die om een wachtwoord blijft vragen.
dan probeert je source server het niet met de public key
Hij lijkt het met password te willen aanmelden
Permission denied (publickey,gssapi-with-mic,password)
zet de verbinding eens op met ssh user@server -v, dan krijg je te zien wat er allemaal kan
source:~ user$ ssh user@xxxx.xxxx.nl -v
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to xxxx.xxxx.nl [xxx] port 22.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/identity type -1
debug1: identity file /Users/user/.ssh/id_rsa type 1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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 'xxxx.xxxx.nl' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:5
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,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user/.ssh/identity
debug1: Offering public key: /Users/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Linux xxxx.xxxx.nl 2.6.26-2-amd64 #1 SMP Sun Jun 20 20:16:30 UTC 2010 x86_64
"Authentications that can continue: publickey,password" is dus goed in dit geval.
Ik krijg dit:
[test@sourceserver ~]$ ssh -v -i .ssh/id_rsa.pub -p [port] test@backupserver
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to backupserver [ip] port [port].
debug1: Connection established.
debug1: identity file .ssh/id_rsa.pub type 1
debug1: loaded 1 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
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 '[host]' is known and matches the RSA host key.
debug1: Found key in /home/test/.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
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa.pub
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password
Zonder -i
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
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195
debug1: Next authentication method: publickey
debug1: Trying private key: /home/test/.ssh/identity
debug1: Offering public key: /home/test/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/test/.ssh/id_dsa
debug1: Next authentication method: password
Hij geeft dus wat fouten en gaat door met password authentication dat lijkt me niet goed, maar hoe pas ik dit aan?
sshd_config bleek toch niet goed, de . (punt) voor ssh vergeten :S
Nu komt er het volgende in de log:
Sep 15 13:19:04 backupserver sshd[4766]: Authentication refused: bad ownership or modes for file /home/test/.ssh/authorized_keys
Sep 15 13:19:04 backupserver sshd[4766]: Authentication refused: bad ownership or modes for file /home/test/.ssh/authorized_keys
Dat is het probleem dus
mooi, dat is met een chown/chmod op te lossen
zo is het al goed:
-rw-r--r-- 1 root root 1603 2010-09-12 10:35 authorized_keys
De map stond op 755, dan moest 700 zijn en de authorized_keys stond bij mij op 644 maar dat moest toch 600 zijn blijkbaar.
Bedankt voor de hulp!
Ik krijg wat Permission denied (13) errors (volledig terecht), hoe lossen jullie dit op, syncen met root? Lijkt me niet de mooiste oplossing, van de andere kant de user zal toch toegang moeten hebben om te kunnen syncen.
dit gaat moeilijk worden denk ik (de uitleg) :
als je een nieuwe key aanmaakt voor de gebruiker die rsync mag doen en die (public key) in zijn homedir plaats /home/nieuwegebruiker/.ssh/authorized_keys op beide systemen, dan kan hij met zijn gebruikersnaam en private key inloggen.
Daarna kan hij een rsync doen van 1 systeem naar het andere.
Ik denk wel dat hij niet alle mappen kan syncen want dat is alleen voor de root user.
Hij heeft niet alle rechten.
Er bestaan oplossingen om ssh te beperken in alleen zijn home map, dus dat hij niet uit die map geraakt.
Ik krijg wat Permission denied (13) errors (volledig terecht), hoe lossen jullie dit op, syncen met root? Lijkt me niet de mooiste oplossing, van de andere kant de user zal toch toegang moeten hebben om te kunnen syncen.
Ik heb het even getest met root, echter blijkt dit niet te werken gezien root een wachtwoord heeft...
Hoe hebben jullie het rechten probleem opgelost?
op sourceserver werken als root en de public key van sourceserver root op de destserver user backup toevoegen en dus ook met ssh gebruiken backup@destserver
Maar dan is het geen pull mechanisme meer, ik draai rsync nu namelijk vanaf mijn backup server.
oh, dan doe je het andersom
backup server:
werken als backup user
ssh/rsync root@sourceserver
source server:
/root/.ssh/authorized_keys: pubkey van backup@dest
Je connect dan als backup user van je backupserver naar de sourceserver. Op de sourceserver heb je root privileges.
Je kunt in de sshd config nog "PermitRootLogin without-password" (password authenticatie is niet mogelijk, alleen nog public key) of "PermitRootLogin forced-commands-only" (alleen commando uit authorized_keys file toegestaan) opnemen en root verder niet allowen.
Voorbeeld van forced-commands-only:
command="/root/.ssh/validate_rsync.sh" ssh-rsa xxxx backuser@backupserver
Voorbeeld van validate_rsync.sh:
#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac
debug1: Next authentication method: publickey
debug1: Trying private key: /home/backupuser/.ssh/identity
debug1: Offering public key: /home/backupuser/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/backupuser/.ssh/id_dsa
debug1: Next authentication method: password
Hij blijft dus overschakelen op password authentication omdat op de root user een wachtwoord staat, dat kan ik helaas niet veranderen ben ik bang.
Anyone?
Kan er op Google ook weinig over vinden, behalve dat je beter niet onder root kunt syncen, maar ja dan zul je vroeg of laat toch tegen rechten problemen aanlopen.