Hi,
nun, ich will hier kurz auf beide Antworten eingehen.
ein kurzes Nachschauen zeigte, das www-data (nat�rlich der
Apache-user) bereits eine Shell (/bin/sh) besitzt.
Nachdem ich gestern entdeckt hatte, das der Wurm bei der
ssh config zu suchen war ist mir auch su -c als einfachere
Testmethode in den Sinn gekommen.
Habe auf dem Ausgangsrechner in /var/www/.ssh/config
BatchMode yes
PasswordAuthentication no
gesetzt.
Mittels su - www-data -c 'ssh-keygen -t dsa'
und su - www-data -c 'ssh-keygen -t rsa'
entsprechende Schl�ssel erzeugt,
mittels scp die entsprechenden Dateien
/var/www/.ssh/id_dsa.pub /var/www/.ssh/id_rsa.pub
auf den Zielrechner kopiert
und dort mittels cat id_rsa.pub id_dsa.pub > authorized_keys
zusammengef�gt.
uns so sah dann die Ausgabe des Tests aus (nur der
entscheidende Teil nat�rlich).
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try pubkey: /var/www/.ssh/id_rsa
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: try pubkey: /var/www/.ssh/id_dsa
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: no more auth methods to try
Permission denied (publickey,password,keyboard-interactive).
nach der ssh manpage m�sste das klappen.
tut es aber nicht (wie leicht zu sehen).
habe auf dem Zielrechner leider bisher vergeblich
nach einem logfile gesucht, der diese Zugriffsversuche
etwas detailierter beschreibt.
Any Ideas?
TIA
Helmut
ps: zumindest klappt die Alternativmethode
rsync via NFS mounted Directory.
--
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
