[SSH] Wachtwoord-methode onveilig?

[DPLuS]

Laatst heb ik Debian v3 testing geïnstalleerd en tevens een ssh-daemon.
Tot mijn verbazing kon ik niet inloggen vanaf een ssh-client op een andere pc.

Toen ik de sshd_config erop na sloeg zag ik het volgende:

code:

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no

Nu weet ik niet zo heel erg veel van ssh af, maar is het zo dat het wachtwoord dat je intypt bij authenticatie van ssh-sessie gewoon in cleartext verstuurd wordt maar dan ingekapseld in de versleutelde ssh-tunnel (zoals in bovenstaand commentaar vermeld is)?

Want als dat zo is, dan is deze wachtwoord-methode inderdaad (te) onveilig voor publieke servers.
Omdat ssh gebruik maakt van realtime encryptie, is het aantal bits waarmee versleuteld wordt immers toch niet zo hoog, toch? En dus redelijk makkelijk te kraken...

Indien bovenstaand correct is, waar kan ik dan het beste (veiligste) gebruik van maken?
Ik zie in mijn SecureCRT nog zaken staan zoals: PublicKey, GSSAPI en Keyboard Interactive.

Volgens mij wordt bij PublicKey-methode het sterk versleutelde wachtwoord nog eens binnen een zwakker versleuteld SSH-tunneltje verstuurd (http://chxo.com/be2/20030905_77fe.html).

Hopende dat iemand dit kan toelichten...

[TWBMS]

Na even gegoogled te hebben vind ik de volgende interresante snippet:

PasswordAuthentication yes

The option PasswordAuthentication specifies whether we should use password-based authentication. For strong security, this option must always be set to yes

en http://www.miek.nl/linux/ssh.html geeft ook nog wat informatie hier over.

Blijkbaar heeft die functie te maken hoe ssh met logins om gaat.
Naast het invoeren van een wachtwoord kan ssh namelijk ook werken met een private en public key ( ala gpg/pgp ).

Deze url: http://open.bsdcow.net/tutorials/ssh_pubkey_auth , geeft de volgende snippet.

You also might want to disable the PasswordAuthentication option, so people can only login through key authentication:

Hopelijk geeft dit genoeg informatie.

[BoAC]

OpenSSH Faq
Je password wordt dus encrypted overgestuurd

[CyBeR]

BoAC schreef op woensdag 27 april 2005 @ 14:11:
OpenSSH Faq
Je password wordt dus encrypted overgestuurd

Dat ontkent TS ook niet.

Want als dat zo is, dan is deze wachtwoord-methode inderdaad (te) onveilig voor publieke servers.
Omdat ssh gebruik maakt van realtime encryptie, is het aantal bits waarmee versleuteld wordt immers toch niet zo hoog, toch? En dus redelijk makkelijk te kraken...

Waarom denk je dat? SSH gebruikt over het algemeen 768bit keys en groter. Kraakbaar is alles, maar tegen de tijd dat je het gekraakt hebt ben je zodanig veel tijd verder dat 't wachtwoord inmiddels al niet meer bestaat... Bruteforcen van het wachtwoord is sneller iig.

[DPLuS]

Nou, als de PasswordAuthentication Method zo veilig is, waarom zetten ze het nu dan standaard uit?
En wie kan mij bijvoorbeeld vertellen hoeveel bits versleuteling een SSH-sessie doet?

[ Voor 10% gewijzigd door DPLuS op 27-04-2005 15:24 ]

[BlaTieBla]

768bits is voor de publickey (asymmetrische encryptie). SSH bestaat uit een deel symmetrische en een deel asymmetrische cryptostuff.
Middels het asym-deel wordt het shared secret uitgewisseld (is sym-deel). Op basis van het sym-deel wordt alle data in de sessie versleuteld.
Asymmetrische encrpytie is relatief CPU-intensief. Daarom wordt het vaak alleen gebruikt om een symmetrische sleutel te beveiligen tijdens transport. De symmetrische sleutel (aka shared secret) wordt dan gebruikt om de data te beveiligen. Hier zijn 128bit en 256bit redelijk standaard.

Asym keys van 1024 zijn zo standaard als het maar kan. 2048 of 4096 is beter.

Let wel, dat je encryptie nivo wel afgestemd moet zijn op de te beveiligen data. 4096 om een boodschappenlijstje te beveiligen is overkill (tenzij het lijstje leopard tanks, F-16's etc. bevat). 768 voor staatsgeheimen is het andere uiterste.

128bit symmetrische encryptie komt qua sterkte ongeveer overeen met 1024bit assymetrische encryptie. Dat wil zeggen qua tijd om dat te bruteforcen.
Let wel; sym vergelijken met asym encryptie is appels met peren vergelijken

[ Voor 16% gewijzigd door BlaTieBla op 27-04-2005 15:35 ]

[DPLuS]

Mooi verhaaltje, maar wat betekent dit nu concreet:

Moet ik me nu zorgen gaan maken met die Password-methode, ja of nee?
Kan ik misschien beter overstappen op de publickey-methode?

[BoAC]

Zoals Cyber al zei is het mogelijk om dmv brute-force attack binnen te komen met password authenticatie. Bij ssh-key authenticatie niet uiteraard.
Hier een stukje log uit mijn server:

code:

Apr 20 00:57:08 server sshd[24295]: Illegal user raducu from 66.36.242.33
Apr 20 00:57:08 server sshd[24295]: error: Could not get shadow information for NOUSER
Apr 20 00:57:08 server sshd[24295]: Failed password for illegal user raducu from 66.36.242.33 port 41942 ssh2
Apr 20 00:57:09 server sshd[24297]: Illegal user raul from 66.36.242.33
Apr 20 00:57:09 server sshd[24297]: error: Could not get shadow information for NOUSER
Apr 20 00:57:09 server sshd[24297]: Failed password for illegal user raul from 66.36.242.33 port 42006 ssh2
Apr 20 00:57:10 server sshd[24299]: Illegal user robert from 66.36.242.33
Apr 20 00:57:10 server sshd[24299]: error: Could not get shadow information for NOUSER
Apr 20 00:57:10 server sshd[24299]: Failed password for illegal user robert from 66.36.242.33 port 42065 ssh2
Apr 20 00:57:11 server sshd[24301]: Illegal user roxi from 66.36.242.33
Apr 20 00:57:11 server sshd[24301]: error: Could not get shadow information for NOUSER
Apr 20 00:57:11 server sshd[24301]: Failed password for illegal user roxi from 66.36.242.33 port 42128 ssh2
Apr 20 00:57:12 server sshd[24303]: Illegal user sasha from 66.36.242.33
Apr 20 00:57:12 server sshd[24303]: error: Could not get shadow information for NOUSER
Apr 20 00:57:12 server sshd[24303]: Failed password for illegal user sasha from 66.36.242.33 port 42193 ssh2
Apr 20 00:57:13 server sshd[24305]: Illegal user seba from 66.36.242.33
Apr 20 00:57:13 server sshd[24305]: error: Could not get shadow information for NOUSER

Meer dan 600 attempts op 20 April

De keuze is dan aan jou..

[Verwijderd]

DPLuS schreef op woensdag 27 april 2005 @ 15:48:
Mooi verhaaltje, maar wat betekent dit nu concreet:
Moet ik me nu zorgen gaan maken met die Password-methode, ja of nee?
Kan ik misschien beter overstappen op de publickey-methode?

Lees je de comments wel?

Als je die optie op ja zet, moet je altijd een wachtwoord intypen als je inlogt.
Als je die optie op nee zet, kun je ook via keypairs inloggen.

De eerste optie is handig voor critical shell-servers. De twee optie gebruikt men bijvoorbeeld voor SSH-gebaseerde CVS/SVN/... servers. Zet hem alleen op "ja" als gebruikersvriendelijkheid geen optie is om aan veiligheid in te boeten. In elk ander geval wil je via keypairs ook kunnen inloggen, omdat de gebruiker dan slechts eenmalig (bij de key-authenticatie) hoeft in te loggen, en daarna via zijn key kan authenticaten.

[BoAC]

Verwijderd schreef op woensdag 27 april 2005 @ 17:22:
[...]


Lees je de comments wel?

Als je die optie op ja zet, moet je altijd een wachtwoord intypen als je inlogt.
Als je die optie op nee zet, kun je ook via keypairs inloggen.

`man sshd_config`:

code:

PasswordAuthentication
             Specifies whether password authentication is allowed. The default is ``yes''.

Het geeft dus alleen maar aan of het is toegestaan
Wanneer er dus met keys wordt ingelogd wordt er niet om een wachtwoord gevraagd.

..
In elk ander geval wil je via keypairs ook kunnen inloggen, omdat de gebruiker dan slechts eenmalig (bij de key-authenticatie) hoeft in te loggen, en daarna via zijn key kan authenticaten.

Wat bedoel je hiermee? Je logt toch altijd met je private-key in wanneer je keypairs gebruikt?

[Verwijderd]

BoAC schreef op woensdag 27 april 2005 @ 19:31:
Wat bedoel je hiermee? Je logt toch altijd met je private-key in wanneer je keypairs gebruikt?

Om de eerste keer de key bij de server aan te melden, log je over het algemeen zonder key in. Je kan natuurlijk ook je public key opsturen naar de serverbeheerder.

[edit]
Overigens, je bedoelt het waarschijnlijk niet zo, maar je logt natuurlijk niet in met je private key, maar met een response op een "aanbod" van de server die je behandelt met je private key. .

[ Voor 22% gewijzigd door Verwijderd op 27-04-2005 21:17 ]

[DPLuS]

OK, ik wil dus vanaf nu gebruik gaan maken van private/public keys om een ssh-sessie te authenticeren.

Ik heb eerst deze howto gevolgd: http://www.bgl.mcs.anl.go...tation/General/sshkey.php
en een ssh-sessie van linux naar linux gaat nu MET passphrase helemaal goed.

Maar nu leek het me handig om de private key maar één keer MET PASSPHRASE aan te maken, en die zowel te gebruiken in linux als in windows.

Maar nu loop ik tegen het volgende probleem aan:

Ik heb zowel windows als linux-clients die op een ssh-server moeten inloggen.
Het probleem is nu dat de keys die ik genereer met: $ ssh-keygen -t rsa -b 4096 niet werken in mijn SecureCRT-client op windows (v4 wel te verstaan).

Andersom gaat het ook fout: de private key die gegenereerd wordt in SecureCRT MET EEN PASSPHRASE kan wel in linux gebruikt worden, maar dan wordt er in linux NIET MEER om de passphrase gevraagd, da's raar!
SSH logt dus wel verder in met die windows-key, maar waar is de passphrase naar toe?

Ik las in de howto dat het bestands-formaat van de public key ook niet helemaal overeen komt met het bestandsformaat van ~/.ssh/authorized_keys.
Je moet eerst een truukje uithalen om de public key uit SecureCRT werkend te maken met je ssh-server, te weten: ssh-keygen -i -f ~/.ssh/securecrt_generated_pub_key >> ~/.ssh/authorized_keys

Misschien heb ik dus nog een commando nodig om de private key uit windows te converteren naar een voor linux begrijpelijke key?

Wie kan mij helpen?

[Wilke]

Verwijderd schreef op woensdag 27 april 2005 @ 17:22:
In elk ander geval wil je via keypairs ook kunnen inloggen, omdat de gebruiker dan slechts eenmalig (bij de key-authenticatie) hoeft in te loggen, en daarna via zijn key kan authenticaten.

Echter, dan zit er (als het goed is) een wachtwoord op de private key, en moet je dus elke keer het wachtwoord van de private key (op het lokale systeem) intypen om ergens anders te kunnen inloggen.

Dus dat is nog het meest veilig (veiliger dan een passwd, dus _juist_ iets wat je bij kritische servers zou gebruiken in plaats van een password-login), omdat:

a. je nog steeds een wachtwoord moet intypen om je private key te kunnen gebruiken (zonder die private key kun je nog steeds nergens inloggen, precies de bedoeling dus). Zelfs als iemand die private key weet te jatten is er dus niks aan de hand: zonder het wachtwoord dat er op zit kan hij er toch niets mee.
b. er uberhaupt geen wachtwoord over de lijn gestuurd wordt in welke vorm dan ook.

Als je voor gebruiksgemak gaat en toch (relatief) veilig - d.w.z. zolang het systeem vanaf waar je inlogt niet gehacked wordt - maak dan een public/private key-paar aan, de private key _moet_ een wachtwoord hebben, maar gebruik vervolgens een tooltje als ssh-agent of keychain om te zorgen dat je deze niet elke keer hoeft in te tikken.

Zie ook deze artikelen voor een uitgebreide uitleg van hoe dit werkt, en waarom het handig is:

OpenSSH key management, Part 1
OpenSSH key management, Part 2
OpenSSH key management, Part 3

[xzenor]

Nou, nu maar even een antwoord op je echte vraag..
PasswordAuthentication wil zeggen de interne authentication van sshd.
Op de meeste systemen gaat dit geheel namelijk via PAM, maar als je geen pam gebruikt en toch passwords authentication wilt moet het dus aan.
Vandaar dat het standaard dus uit staat, omdat op jouw systeem waarschijnlijk ook gewoon PAM draait, en autentication dus via PAM gebeurd.
man sshd_config op FreeBSD geeft dit, misschien heb je er iets aan.

PasswordAuthentication
Specifies whether password authentication is allowed. The
default is ``no'', unless sshd was built without PAM support, in
which case the default is ``yes''. Note that if
ChallengeResponseAuthentication is ``yes'', and the PAM authenti-
cation policy for sshd includes pam_unix(, password authentica-
tion will be allowed through the challenge-response mechanism
regardless of the value of PasswordAuthentication.

[ Voor 3% gewijzigd door xzenor op 28-04-2005 11:35 ]