Alexander Jäger wrote: [...]
~/.ssh ist also für *alle* schreibbar. Das dürfte die
Ursache für das
Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.
sowohl 700 als auch 755 funktionierte nicht
755 geht; 700 geht (ist IMO egal, aber eben _nicht_ hinreichend. Dagegen _darf_ auf deine authorized_keys Datei niemand ausser dem User selber Schreibrecht haben (chmod 644 ...)
was mich hier wundert, ist dass das ll in /var/backup/.ssh gemacht wurde und eben nicht in ~/.ssh - oder ist /var/backup das Home-Verzeichnis des Backup-Users?
ja ist es
Noch 'ne Idee (hatte ich auch mal): Ich muss hier (OK, ist 'ne grössere Sun; aber ssh ist ebenfalls installiert) für Zugriff mit leerer Passphrase _zusätzlich_ mein Homeverzeichnis für alle zum schreiben dichtmachen. Sonst fragt er IMMER nach passwort. Also in Deinem Fall: chmod 700 /var/backup (oder max. 755) Ist zumindest ein Versuch wert. Andreas
Am Mi, den 31.08.2005 schrieb Kyek, Andreas, VF-DE um 11:46:
Alexander Jäger wrote: [...]
~/.ssh ist also für *alle* schreibbar. Das dürfte die
Ursache für das
Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.
sowohl 700 als auch 755 funktionierte nicht
755 geht; 700 geht (ist IMO egal, aber eben _nicht_ hinreichend.
Dagegen _darf_ auf deine authorized_keys Datei niemand ausser dem User selber Schreibrecht haben (chmod 644 ...)
Das ist aber chmod 600. Nachzulesen auf: http://www.puddingonline.com/~dave/publications/SSH-with-Keys-HOWTO/document... Bye Michael -- The only thing worse than suffering an injustice is committing an injustice. -- Plato ________________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://dattuxi.de/
So nach langer Testphase melde ich mich mal wieder.
Betreff: Re: SSH key ablegen
Alexander Jäger wrote: [...]
~/.ssh ist also für *alle* schreibbar. Das dürfte die
Ursache für das
Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.
sowohl 700 als auch 755 funktionierte nicht
755 geht; 700 geht (ist IMO egal, aber eben _nicht_ hinreichend.
Dagegen _darf_ auf deine authorized_keys Datei niemand ausser dem User selber Schreibrecht haben (chmod 644 ...)
was mich hier wundert, ist dass das ll in /var/backup/.ssh gemacht wurde und eben nicht in ~/.ssh - oder ist /var/backup das Home-Verzeichnis des Backup-Users?
ja ist es
Noch 'ne Idee (hatte ich auch mal): Ich muss hier (OK, ist 'ne grössere Sun; aber ssh ist ebenfalls installiert) für Zugriff mit leerer Passphrase _zusätzlich_ mein Homeverzeichnis für alle zum schreiben dichtmachen. Sonst fragt er IMMER nach passwort.
Also in Deinem Fall: chmod 700 /var/backup (oder max. 755)
Ist zumindest ein Versuch wert.
Andreas
Habe es nun mit chmod 700 /var/backup versucht, funzt nach wie vor nicht.
Michael Raab wrote:
Am Mi, den 31.08.2005 schrieb Kyek, Andreas, VF-DE um 11:46:
Alexander Jäger wrote: [...]
~/.ssh ist also für *alle* schreibbar. Das dürfte die
Ursache für das
Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.
sowohl 700 als auch 755 funktionierte nicht
755 geht; 700 geht (ist IMO egal, aber eben _nicht_ hinreichend.
Dagegen _darf_ auf deine authorized_keys Datei niemand ausser dem User selber Schreibrecht haben (chmod 644 ...)
Das ist aber chmod 600. Nachzulesen auf:
??? _Schreibrecht_ entziehen reicht. (Eben noch mal probiert).
600 tut es natürlich auch; aber 644 reicht eben aus.
chmod 600 hat auch nichts gebracht
oder ist /var/backup das Home-Verzeichnis des Backup-Users?
ja ist es
ssh backup@server2 -v-v gibt folgendes aus: [...] debug1: identity file /root/.ssh/identity type -1
Diese beiden Aussagen machen mit stutzig. Kann es sein, dass Deine ganzen Versuche mit dem .ssh Verzeichnis an der falschen Stelle gemacht wurden? Du scheibst immer von /var/backup/.ssh aber beim login verwendet ssh offensichtlich die Dateien aus /root/.ssh
Du solltest Dir also entweder /root/.ssh genauer ansehen und die Tipps anwenden, die Du schon bekommen hast oder dafür sorgen, dass ssh nicht dort hin sondern nach /var/backup/ssh schaut. Warum es das nicht tut, kann ich Dir leider nicht sagen.
Gruß,
Achim
Habe mal geschaut, also auf server 2 in /root/.ssh/authorized_keys steht der korrekte key, aber er soll ja in /var/backup schauen, wie sage ich ihm das er das machen soll? evtl indem ich auf server1 auch einen User backup anlege? /var/log/messages sagt derzeit nichts aus, außer das ich korrekt eingelogged werde, wenn ich das passwort zu fuß eingebe, aber von key oder so steht nichts drinne, außer der ständigen Meldung: Sep 5 10:44:00 h612132 /USR/SBIN/CRON[32425]: (root) CMD (killall -HUP authdaemond.plain > /dev/null) Sep 5 10:44:00 h612132 authdaemond.plain: authdaemon: modules="authcustom authcram authuserdb authvchkpw authshadow authpwd", daemons=5 Vllt hat ja sonst noch jemand eine Idee Vielen dank schonmal für die zahreiche Hilfe die ich bissher erhalten habe Gruß Alex
Alexander Jäger schrieb:
So nach langer Testphase melde ich mich mal wieder. Habe mal geschaut, also auf server 2 in /root/.ssh/authorized_keys steht der korrekte key, aber er soll ja in /var/backup schauen, wie sage ich ihm das er das machen soll? evtl indem ich auf server1 auch einen User backup anlege?
/var/log/messages sagt derzeit nichts aus, außer das ich korrekt eingelogged werde, wenn ich das passwort zu fuß eingebe, aber von key oder so steht nichts drinne, außer der ständigen Meldung: Sep 5 10:44:00 h612132 /USR/SBIN/CRON[32425]: (root) CMD (killall -HUP authdaemond.plain > /dev/null) Sep 5 10:44:00 h612132 authdaemond.plain: authdaemon: modules="authcustom authcram authuserdb authvchkpw authshadow authpwd", daemons=5
Vllt hat ja sonst noch jemand eine Idee
Vielen dank schonmal für die zahreiche Hilfe die ich bissher erhalten habe Gruß Alex
Wo der ssh-Dämon den Key, bzw. die erlaubten Key sucht steht in /etc/ssh/sshd_config der Eintrag sollte so aussehen: AuthorizedKeysFile .ssh/authorized_keys (Wobei hier relativ zum Homeverzeichnis des Users geschaut wird.) Gruß Axel
Wo der ssh-Dämon den Key, bzw. die erlaubten Key sucht steht in /etc/ssh/sshd_config
der Eintrag sollte so aussehen:
AuthorizedKeysFile .ssh/authorized_keys (Wobei hier relativ zum Homeverzeichnis des Users geschaut wird.)
Gruß Axel
also authorized_keys sieht so aus: server2:/var/backup/.ssh # cat authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA7zDdaFUpIv4hOsd3cUzRbJWg7MQcLudaDCHqBDodVSr5bYRB c+to6SZYqdQR0kHK13al8dOfznDXXf4iAVXGA7lJ9ZcnnFDXtqHvwN7su6r8D+0aUokBWFAOeigK HYg1EoFjD/j7Zk5hFOwg0+9UMqsiDSzkwD11b/ST5G9xtNE= backup@h561178 die sshd_config sieht so aus: # $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $ # This is the ssh client system-wide configuration file. See # ssh_config(5) for more information. This file provides defaults for # $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 Protocol 2 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 Protocol 2 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /etc/ssh/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 # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCreds yes # Set this to 'yes' to enable PAM authentication (via challenge-response) # and session processing. Depending on your PAM configuration, this may # bypass the setting of 'PasswordAuthentication' UsePAM yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #KeepAlive yes #UseLogin no UsePrivilegeSeparation no #PermitUserEnvironment no #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /usr/lib/ssh/sftp-server
participants (4)
-
Alexander Jäger
-
Axel Birndt
-
Kyek, Andreas, VF-DE
-
Michael Raab