Remote inloggen wil niet meer na upgrade van openssh

[GertW]

Gistermorgen mijn server (die draait op freebsd en in amsterdam hangt, ongeveer 200km van mijn huis) via ssh geupgrade. Dit doe ik zo al ongeveer anderhalf jaar. Diverse packages werden vernieuwd, waaronder openssh. Nu wilde ik gisteravond weer inloggen maar dit wilde niet. Putty gaf het volgende aan:

Disconnected. No supported authentication methods available!

Nadat ik gisteravond de hele avond en vandaag de hele dag heb gezocht/geprobeert ben ik er achter dat de authentication van openssh nu via ssh2 met een private en public key moet gebeuren, maar die heb ik dus niet. Hebben jullie een oplossing hoe ik toch kan inloggen?

Wat ik gevonden/geprobeert:
-op diverse fora werd aangeraden te spelen met de authentication methodes, dus Keyboard Interactive aanzetten, forcen tot ssh1 of 2 alles volgens mij geprobeert, maar ik krijg geen connectie, steeds weer diezelfde foutmelding
-andere ssh clients geprobeert, waaronder secureCRT en WinSCP, hier kwam ik er achter dat openssh met een public/private key werkt.
-ftpen naar de server wil wel, maar alleen in de webserver mappen.
-mail werkt, net als de rest, behalve dus inloggen via ssh
-PHPSh en PHP Shell Commander geprobeert om toch in te loggen, maar dan kan ik eigenlijk niks doen, inloggen wil echter wel.
-een CGI shell geval geprobeert, maar die kreeg ik niet werkend.


Hieronder even een stukje logfile van SecureCRT:

SecureCRT - Version 5.5.1 (build 407)
[LOCAL] : SSH2Core version 4.3.0.407 
[LOCAL] : Connecting to ***.***.***.***:22 ... 
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT 
[LOCAL] : Using protocol SSH2 
[LOCAL] : RECV : Remote Identifier = "SSH-2.0-OpenSSH_4.6p1 FreeBSD-openssh-portable-4.6.p1,1" 
[LOCAL] : CAP  : Remote can re-key 
[LOCAL] : CAP  : Remote sends language in password change requests 
[LOCAL] : CAP  : Remote sends algorithm name in PK_OK packets 
[LOCAL] : CAP  : Remote sends algorithm name in public key packets 
[LOCAL] : CAP  : Remote sends algorithm name in signatures 
[LOCAL] : CAP  : Remote sends error text in open failure packets 
[LOCAL] : CAP  : Remote sends name in service accept packets 
[LOCAL] : CAP  : Remote includes port number in x11 open packets 
[LOCAL] : CAP  : Remote uses 160 bit keys for SHA1 MAC 
[LOCAL] : CAP  : Remote supports new diffie-hellman group exchange messages 
[LOCAL] : CAP  : Remote correctly handles unknown SFTP extensions 
[LOCAL] : CAP  : Remote correctly encodes OID for gssapi 
[LOCAL] : CAP  : Remote correctly uses connected addresses in forwarded-tcpip requests 
[LOCAL] : CAP  : Remote can do SFTP version 4 
[LOCAL] : CAP  : Remote x.509v3 uses ASN.1 encoding for DSA signatures 
[LOCAL] : SEND : KEXINIT 
[LOCAL] : RECV : Read kexinit 
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 
[LOCAL] : Selected Kex Method = diffie-hellman-group-exchange-sha1 
[LOCAL] : Available Remote Host Key Algos = ssh-rsa,ssh-dss 
[LOCAL] : Selected Host Key Algo = ssh-dss 
[LOCAL] : Available Remote Send Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr 
[LOCAL] : Selected Send Cipher = aes256-cbc 
[LOCAL] : Available Remote Recv Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr 
[LOCAL] : Selected Recv Cipher = aes256-cbc 
[LOCAL] : Available Remote Send Macs = hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96 
[LOCAL] : Selected Send Mac = hmac-sha1 
[LOCAL] : Available Remote Recv Macs = hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96 
[LOCAL] : Selected Recv Mac = hmac-sha1 
[LOCAL] : Available Remote Compressors = none,[e-mail] 
[LOCAL] : Selected Compressor = none 
[LOCAL] : Available Remote Decompressors = none,[e-mail] 
[LOCAL] : Selected Decompressor = none 
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE 
[LOCAL] : SEND : KEXDH_GEX_REQUEST 
[LOCAL] : RECV : KEXDH_GEX_GROUP 
[LOCAL] : SEND : KEXDH_INIT 
[LOCAL] : RECV : KEXDH_REPLY 
[LOCAL] : SEND : NEWKEYS 
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_EXPECT_NEWKEYS 
[LOCAL] : RECV : NEWKEYS 
[LOCAL] : Changing state from STATE_EXPECT_NEWKEYS to STATE_CONNECTION 
[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth] 
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK 
[LOCAL] : SENT : USERAUTH_REQUEST [none] 
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey] 
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - unsigned,fingerprint: *******] 
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey] 
[LOCAL] : SEND: Disconnect packet: The user canceled authentication.  
[LOCAL] : Changing state from STATE_CONNECTION to STATE_SEND_DISCONNECT 
[LOCAL] : Changing state from STATE_SEND_DISCONNECT to STATE_CLOSED 
[LOCAL] : Connected for 22 seconds, 1199 bytes sent, 1892 bytes received 

[axis]

Ik heb geen goed antwoord op je vraag, maar mag ik vragen hoe je dit voor elkaar hebt gekregen? (Ik zou het zelf niet fijn vinden als ik volgende week met hetzelfde probleem zit) De sshd zit toch bij de base, en is geen losse package? Heb je een rebuildworld gedaan, en is dit opeens het resultaat? Of heb je een vervanger geinstalleerd met de verkeerde optie?

Sja, ik denk dat het lastig wordt.. Als je niemand kent in A'dam, en je servers hebben geen remote access card, kvm over ip of seriele connectie, dan zit er denk ik niet veel andere op dan heen en weer rijden..

[ Voor 7% gewijzigd door axis op 28-06-2007 02:11 ]

[benoni]

axis schreef op donderdag 28 juni 2007 @ 02:06:
(Ik zou het zelf niet fijn vinden als ik volgende week met hetzelfde probleem zit)

Je kunt direct na de upgrade de authenticatieprocedure testen door een extra sessie te openen. Als het dan niet werkt kun je een openstaande sessie gebruiken om het probleem te verhelpen.

@GertW:
Ik vrees dat het een serverside configuratieprobleem is, maar voor alle zekerheid: kijk ook even naar de bewaarde public keys aan de client kant (~/.ssh/known_hosts voor Linux of Mac, bij Windows zal 't wel ergens in Mijn Documenten zitten of zo). Misschien dat de server een nieuwe public key heeft aangemaakt en dat de oude key uit je known_hosts file moet worden gehaald. Ik verwacht eigenlijk niet dat dit nu 't geval is, want de meeste SSH clients hadden bij zo'n probleem een melding gegeven in de trant van 'WARNING - public key has changed'. Maar goed, 't kan verkeren...

[GertW]

nou, de transip distro heeft een handige portupgrade optie waarmee alles (behalve apache) wordt geupgrade naar de nieuwste versie uit de cvs repositories (ff uit mijn hoofd hoor). Die draai ik anders ook en ik heb geen melding gehad dat er iets verandert was in openssh e.d., daar let ik namelijk altijd wel op!

Mijn authentication was eerst via password en nu dus in één keer via rsa keys... erg wazig! Keys kan ik helaas niet vinden lokaal (ik was ingelogd met putty onder winXP).

Zit niks anders op dan volgende week of die week erop ofzo een ritje naar amsterdam te maken dus... Of jullie moeten me een spoedcursus freebsd hacken geven ofzo! Maargoed, als ik er toch heen ga dan maar gelijk nieuwe HDD's erin en DirectAdmin erop. Van de nood een deugd maken noemen ze dat geloofik!

[GertW]

Goed, het probleem is eindelijk opgelost! En je raad het nooit, het was iets stoms en makkelijks! Maar ik dacht, laat ik het toch maar even posten, misschien loopt iemand anders ooit nog eens tegen dit probleem aan!

Mijn oplossing is als volgt:
-SSH key gegenereerd (met secureCRT)
-inhoud van het public key bestand in het bestandje authorized_keys gezet
-via ftp ingelogd in home dir van gebruiker
-de map .shh aangemaakt
-.ssh gechmod naar 700
-het bestandje authorized_keys geupload naar .shh
-authorized_keys gechmod naar 600
-bling -> het werkt!

Vooral het chmodden bleek erg belangrijk en natuurlijk de inhoud van authorized_keys.

In ieder geval bedankt voor de reacties

[deadeyes]

GertW schreef op maandag 09 juli 2007 @ 19:41:
Goed, het probleem is eindelijk opgelost! En je raad het nooit, het was iets stoms en makkelijks! Maar ik dacht, laat ik het toch maar even posten, misschien loopt iemand anders ooit nog eens tegen dit probleem aan!

Mijn oplossing is als volgt:
-SSH key gegenereerd (met secureCRT)
-inhoud van het public key bestand in het bestandje authorized_keys gezet
-via ftp ingelogd in home dir van gebruiker
-de map .shh aangemaakt
-.ssh gechmod naar 700
-het bestandje authorized_keys geupload naar .shh
-authorized_keys gechmod naar 600
-bling -> het werkt!

Vooral het chmodden bleek erg belangrijk en natuurlijk de inhoud van authorized_keys.

In ieder geval bedankt voor de reacties

Het is gewoon een server instelling die zegt dat er alleen kan ingelogd worden met public key authenticatie.
Dus via password is niet meer mogelijk.
Dit is een veel veiligere manier van werken.waarschijnlijk is dit nu een standaardinstelling geworden.

[dragunova]

Het probleem was al opgelost, maar ik ben benieuwd wat je bedoelt met wat je nu zegt.
Ging bij ssh de data onversleuteld over de lijn dan?
Dat zou hetzelfde betekenen als telnet, ik dacht dat de kracht van ssh juist zat in de beveiliging, vandaar de secure shell?

Wat is er nu precies veranderd met ssh2 ten opzichte van ssh?

EDIT: t ziet er naar uit dat het versleutelingsalgoritme anders is. RSA was toch gekraakt? Nah, toch niet helemaal

The OpenSSH SSH client supports SSH protocols 1 and 2. Protocol 2 is the
default, with ssh falling back to protocol 1 if it detects protocol 2 is
unsupported. These settings may be altered using the Protocol option in
ssh_config(5), or enforced using the -1 and -2 options (see above). Both
protocols support similar authentication methods, but protocol 2 is pre-
ferred since it provides additional mechanisms for confidentiality (the
traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and
integrity (hmac-md5, hmac-sha1, hmac-ripemd160). Protocol 1 lacks a
strong mechanism for ensuring the integrity of the connection.
Protocol 1 is restricted to using only RSA keys, but
protocol 2 may use either

[ Voor 57% gewijzigd door dragunova op 15-07-2007 22:38 ]

[sam.vimes]

GertW schreef op maandag 09 juli 2007 @ 19:41:
[...]
-via ftp ingelogd in home dir van gebruiker
-de map .shh aangemaakt
-.ssh gechmod naar 700
-het bestandje authorized_keys geupload naar .shh
-authorized_keys gechmod naar 600
-bling -> het werkt!
[...]

Deze combi van ftp en ssh is natuurlijk een beveiliging van lik-me-vestje! Bij ftp gaat je wachtwoord onversleuteld over de lijn. Een hcracker hoeft alleen maar jouw ftp-verkeer af te luisteren om achter je password te komen en kan vervolgens hetzelfde trucje uithalen als wat jij deed om ssh-toegang tot jouw account te krijgen.

Ik zou ftp-toegang (laten?) blokkeren en vervangen door ssh/scp/sftp.

[GertW]

Het enige wat je kunt is in de home-dir van een gewone gebruiker (met beperkte rechten) komen, root is uiteraard uitgeschakelt. dus dan zou de eventueële hcracker nog vast zitten in de chroot omgeving.

Nu ben ik eigenlijk wel benieuwd hoe dat zit bij de grote hosting providers enzo... Die bieden toch ook gewoon ftp toegang aan? luistert er gewoon niemand die wachtwoorden af? of hebben ze dit op andere manieren beveiligd? Dit zou dus betekenen dat je in principe op elke ftp server kunt komen als je ook maar een klein beetje handig bent! Er zijn volgens mij maar weinig providers die geen normale ftp toegang toelaten... Of heb ik het mis en werkt elke provider met sftp?

ik geef nu dus via ftp toegang tot de home dir, daar staat een map www in, en wat andere mappen enzo, zou het beter zijn als ik via ftp alleen toegang tot de www dir geef? Ik kan me herinneren dat ik ooit bij deheeg een soortgelijke homedir had... dus net als ik nu al heb.

Ik ga eens even flink googlen hierover!


(sorry voor het (beetje) offtopic gaan, maar ik vind dit erg interessant!)

[ Voor 45% gewijzigd door GertW op 18-07-2007 11:30 ]