ssh werkt niet echt soepel op jaunty server met xubuntu

[Wiley]

Hallo,

Sinds ik Xubuntu-desktop heb geïnstalleerd op een oud testservertje met Ubuntu 9.04 server werkt ssh nog maar sporadisch. Ik kom er maar niet achter wat het is, logfiles geven weinig prijs.

Symptomen:
* putty timed per definitie out na het ingeven van het wachtwoord (op een windows laptop)
* ssh vanaf een andere Jaunty machine reageert 4 van de 5 keer met "connection closed by <mijn server ip>" na het invoeren van het wachtwoord
* daarnaast hangt de login nogal eens na het invoeren van het wachtwoord.

In /var/log/auth.log is niets vreemds te zien, behalve de kennelijk gebruikelijke ecryptfs meldingen rondom de login. Bij afgebroken logins is de laatste melding meestal

Code: [Selecteer]

May 21 22:07:18 <mijn servernaam> sshd[3370]: There is already a key in the user session keyring for the given passphrase.
maar die melding staat ook bij succesvolle logins, gevolgd door

Code: [Selecteer]

May 21 22:56:41 <mijn servernaam> sshd[3745]: Accepted password for <mijn usernaam> from 192.168.2.2 port 42828 ssh2

ssh op mijn gewone 9.04 desktop werkt gewoon goed (incl. putty vanaf mijn windows laptop). Ik verdenk dan toch ecryptfs, aangezien in bij de desktopinstall van Xubuntu de hele home map heb laten encrypten.

Iemand ook die ervaring of een idee waar ik het moet zoeken?

[Johan van Dijk]

Je hebt waarschijnlijk de verborgen .ssh map ook versleuteld.
Als je niet bent ingelogd op die server, dan kan de SSH daemon de configuratie van die gebruiker dus niet lezen.

Op de Engelse wiki zijn daar wel oplossingen voor te vinden als het goed is.
http://www.google.nl/search?q=ecryptfs+ssh&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12

[Wiley]

vast en zeker, maar ik gebruik geen public key in dit geval. Gewoon het user wachtwoord. Dan is de ~/.ssh niet nodig voor de login zelf.

Bovendien, het lukt geregeld ook wel. De machine is headless, dus er verandert in de tussentijd niets (zoals: op een andere manier inloggen met dezelfde gebruikernaam, zodat de home directory al 'open' is)

Ik heb inderdaad ook al druk rond gekeken bij ecryptfs en ssh (je google link), maar ik kan specifiek mijn probleem niet vinden (al een paar weken), vandaar dat ik dan hier maar eens post.

Ik denk eraan om de encryptie maar eens eraf te halen, zien of dat werkt. Maar ik zou liever de echte oorzaak kennen.

[Johan van Dijk]

Kan je proberen om verder uit te zoeken wanneer het wel werkt en wanneer niet?
Bijvoorbeeld: als die gebruiker al is ingelogd (direct of via ssh bijv.), dan is zijn home decrypted, dus is de .ssh map te lezen. Lukt het dan altijd wel om een nieuwe verbinding te maken?
Als die gebruiker niet is ingelogd, dan is de .ssh map niet te lezen. Lukt het dan nooit?

Verder kan je natuurlijk ook wat dieper graven in de logbestanden. Noteer wanneer een login niet lukte en kijk wat er in de logbestanden staat. Doe hetzelfde als het wel lukt en vergelijk de regels.
Eventueel kan je ssh configureren zodat die meer gaat loggen (de loglevel aanpassen in sshd_config).

[Wiley]

tussenstand: ik heb een nieuwe gebruiker aangemaakt op de server, zonder encrypted home. ssh met die gebruiker werkt altijd, dus ik blijf ecryptfs verdenken. Ik zal de workaround voor de encrypted ~/.ssh eens gaan uitproberen.

@Johan: het maakt niet zoveel uit of ik al ben ingelogd of niet, maar meestal uiteraard niet. Maar ook als het wel een keer werkt en ik probeer dan in een andere terminal nog een verbinding, dan zelfde resultaat: 8 van de 10 keer 'connection closed'.
En 'nooit' lukt het nooit, zoals ik al schreef: hij is headless. Dus zonder ssh login geen beheer...