PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : temporärer SSH Publickey error



neonerd
30.04.10, 14:19
Hallo zusammen,

debian lenny 5.04
kernel 2.6.26-1-amd64
openssh-server 1.5.1p1-5
hoster = hetzner - root server

ich nutze passwortverschlüsselte publickeys für ssh, auf meinem Produktivserver habe ich folgendes Setup:



Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
UsePAM yes
Subsystem sftp internal-sftp /usr/lib/openssh/sftp-server
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
PasswordAuthentication yes

Der Login funktioniert wunderbar, aber gestern hatte ich für ca. 40 min nicht die möglichkeit mich einzuloggen, mit folgender Fehlermeldung:

Permission denied (publickey)

Ich konnte nichteinmal das key-passwort eingeben. Nach ca. 40 min ging es auf wundersame Weise wieder. Ich habe dieses Problem vor Monaten schon auf einem Entwicklungsserver gehabt, aber auch keine Lösung gefunden. Manchmal ging es einfach nicht für ca. 45 Min. Auf diesem Server kann ich mir das allerdings nicht erlauben ;-)

im /var/log/auth.log steht folgendes was ich nicht einordnen kann:



Apr 30 04:27:51 su[18152]: Successful su for nobody by root
Apr 30 04:27:51 su[18152]: + ??? root:nobody
Apr 30 04:27:51 su[18152]: pam_unix(su:session): session opened for user nobody by (uid=0)
Apr 30 04:27:51 su[18152]: pam_unix(su:session): session closed for user nobody
Apr 30 04:27:51 su[18154]: Successful su for nobody by root
Apr 30 04:27:51 su[18154]: + ??? root:nobody
Apr 30 04:27:51 su[18154]: pam_unix(su:session): session opened for user nobody by (uid=0)
Apr 30 04:27:51 su[18154]: pam_unix(su:session): session closed for user nobody
Apr 30 04:27:51 su[18156]: Successful su for nobody by root
Apr 30 04:27:51 su[18156]: + ??? root:nobody
Apr 30 04:27:51 su[18156]: pam_unix(su:session): session opened for user nobody by (uid=0)


Im /var/log/syslog ist nichts, in /var/log/messages steht nur folgendes:

Apr 30 03:59:02 backup-manager[13441]: info * Using the upload method ssh.

Ich konnte im Netz nichts finden das sshd und backup-manager zusammenhängen. Der Backupmanager macht nachts erst tar.gz backups und schiebt sie dann per SCP auf einen anderen Server.


Für jede Idee wäre ich dankbar, grüße, endlich wieder mit kurzer Hose.. :-)

marce
30.04.10, 14:28
sowas wie fail2ban oder denyhosts am laufen?

neonerd
30.04.10, 14:48
nope, beides nicht laufend, bzw. auch nichts anderes in die richtung das dynamisch irgendwas zu macht

403
03.05.10, 02:30
Apr 30 03:59:02 backup-manager[13441]: info * Using the upload method ssh.

Ich konnte im Netz nichts finden das sshd und backup-manager zusammenhängen. Der Backupmanager macht nachts erst tar.gz backups und schiebt sie dann per SCP auf einen anderen Server.


Zur Klärung: scp wird manchmal zu ssh -o Optionen aufgeloest, scp wird dann remote aufgrufen:




root 6306 0.0 0.6 4620 2320 pts/0 S+ 00:20 0:00 /usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -p23 -l403 somehost.com scp -t /tmp




Zum Rest: Hast Du noch Logs? Denyhosts Ähnliches auf dem Client?

Gruss
403

neonerd
03.05.10, 14:36
Hallo 403,

ich habe leider keine logs auf dem client, habs grade enabled...
wenns nochmal auftritt, poste ich die logs in diesem thread...

Vielen Dank, Philip

neonerd
27.05.10, 13:50
Auf der vorhandenen Machine wird syscp eingesetzt. wenn nun eine ssh-session einen timeout hat, wird wohl irgendwo die normale uid gesperrt und die uid verwendet die SYSCP für den (gleich benannten) nutzers angelegt hat. warum der openssh-server sich diese nimmt weiss ich noch nicht. ideen sind sehr willkommen ;-)