OpenSSH (SSH server)

[Johan van Dijk]

http://wiki.ubuntu-nl.org/community/Openssh-server

Opmerking: Het aanmaken van een sleutel zonder wachtwoordzin is niet aan te raden. Zodra iemand de sleutel heeft kan hij inloggen zonder wachtwoord. Stel je verliest je USB stick, met daarop je sleutel en andere informatie....

Het is veel veiliger om toch een wachtwoordzin te maken. Op die manier staat je computer niet meteen wagenwijd open mocht je sleutel in verkeerde handen komen.

Als je Ubuntu gebruikt, dan kan je de wachtwoordzin laten onthouden, zodat je die maar 1 keer per sessie hoeft in te voeren. Je kan hem ook opslaan in je keyring, zodat die automatisch beschikbaar wordt als je inlogt.
Op die manier ben je een stuk veiliger bezig, zonder dat het invoeren van je wachtwoordzin irritant wordt.

(Ik weet dat je in sommige gevallen wel een key zonder wachtwoordzin wil maken, maar doe dat dan alleen als je weet waar je mee bezig bent. Zo'n geval kan een automatisch backup script zijn bijvoorbeeld.)

[testcees]

@Johan: bedankt voor je opmerking!

Je hebt gelijk: maak alleen een sleutel zonder wachtwoord als je weet dat deze sleutel veilig is.

In de wiki staat nu:

De bezitter van de privé sleutel kan zonder wachtwoord een verbinding maken. Bijvoorbeeld bij verlies van draagbare apparaten kan dit een veiligheidsprobleem zijn. Sla deze sleutel eventueel versleuteld op.

Is dit niet duidelijk genoeg? Deze tekst had ik toegevoegd en is niet vertaalt uit de Engelstalige documentatie omdat daar helemaal geen opmerking staat over dit risico (mogelijk omdat deze documentatie alleen voor servers in bedoelt).

Je zal ongetwijfeld gelijk hebben dat de wachtwoordzin opgeslagen kan worden in de Ubuntu keyring. Ik heb daar echter geen ervaring mee. Een alternatief is encryptie. Bijvoorbeeld met de nieuwe Ubuntu versleutelde Private map:
http://wiki.ubuntu-nl.org/community/VersleuteldePrivateMap

[Johan van Dijk]

Het werkt heel eenvoudig:
Werk je in een gewone grafische omgeving en wil je een SSH verbinding maken met een sleutel, dan krijg je een venster om je wachtwoordzin voor je key in te voeren.
In dit venster kan je ook aangeven of je wachtwoordzin voor de duur van de sessie onthouden moet worden (totdat je uitlogt of opnieuw opstart), of dat die permanent onthouden moet worden.
Je keyring is versleuteld en vanuit de key zelf is het onmogelijk om je wachtwoord terug te rekenen.
Dat is dus redelijk veilig, zonder dat je ingewikkeldere dingen als encryptie moet gaan toepassen.

Werk je zonder grafische omgeving, dan kan je wachtwoord ook onthouden worden.


Een ander voordeel van keys is dat je inloggen met alleen een wachtwoord uit kan schakelen. Hiermee maak je het de scriptkiddies en hun SSH scans meteen onmogelijk om in te breken. Zonder key kan je immers helemaal niet inloggen, dus het bruteforcen van je inlogwachtwoord kan dan niet meer.

Je moet dan wel goed opletten dat je bij je key kan. Verlies je de usb-stick met je key, dan kan je niet meer inloggen via SSH. Wel veilig, maar niet handig

Die link naar de documentatie die je geeft is wel erg kort en mist gewoon wat dingen. Het advies (lege wachtwoordzin) is gewoon onveilig. Waarom ze dat gedaan hebben, is mij een raadsel.

Deze pagina lijkt me een beter startpunt: https://help.ubuntu.com/community/SSH
En deze gaat specifiek over keys: https://help.ubuntu.com/community/SSH/OpenSSH/Keys

[testcees]

Een ander voordeel van keys is dat je inloggen met alleen een wachtwoord uit kan schakelen. Hiermee maak je het de scriptkiddies en hun SSH scans meteen onmogelijk om in te breken. Zonder key kan je immers helemaal niet inloggen, dus het bruteforcen van je inlogwachtwoord kan dan niet meer.

Juist! In de wiki staat nu:
(!) Voor extra veiligheid, bijvoorbeeld als OpenSSH op internet gebruikt wordt, kan het inloggen met een wachtwoord worden uitgeschakeld door het aanpassen van de volgende regel in bestand /etc/ssh/sshd_config:

Code: [Selecteer]

PasswordAuthentication no
Dat bedoel je toch ook?

Het advies (lege wachtwoordzin) is gewoon onveilig. Waarom ze dat gedaan hebben, is mij een raadsel.

Voor toepassing op een server kan dat wel. Met name voor laptops (of voor putty op mijn mobiele telefoon ) is het  (wel praktisch maar) eigenlijk NIET veilig. Een server daarentegen verlies je niet zomaar ergens.

[Johan van Dijk]

Dat bedoel je toch ook?

Zoiets ja

Het advies (lege wachtwoordzin) is gewoon onveilig. Waarom ze dat gedaan hebben, is mij een raadsel.

Voor toepassing op een server kan dat wel. Met name voor laptops (of voor putty op mijn mobiele telefoon ) is het  (wel praktisch maar) eigenlijk NIET veilig. Een server daarentegen verlies je niet zomaar ergens.

Voor een server zou het wel kunnen, maar dan nog zou ik het alleen toepassen als het echt nodig is. Als je een script bouwt die via SSH inlogt, kan die moeilijk om een wachtwoord vragen, bijvoorbeeld.

Als je die key op je telefoon/laptop/usb-key zet dan is een wachtwoordzin wel noodzakelijk om je key een beetje veilig te houden. Een usb-key kan je makkelijk verliezen en je laptop kan gestolen worden...

Ik kan me wel voorstellen dat het invoeren van een wachtwoord op je telefoon niet handig gaat
Hoe belangrijk je dat vindt moet je zelf bepalen. Gebruiksvriendelijkheid gaat dan wel ten koste van de veiligheid.

[testcees]

Stel je verliest je USB stick, met daarop je sleutel en andere informatie....

Niet om van topic te veranderen hoor: maar een onbeveiligde USB stick met informatie

zonder dat je ingewikkeldere dingen als encryptie moet gaan toepassen.

encryptie wordt steeds eenvoudiger in Ubuntu!

Werk je zonder grafische omgeving, dan kan je wachtwoord ook onthouden worden.

Ja, ssh-agent. Staat niet in het wiki artikel.

Hoe belangrijk je dat vindt moet je zelf bepalen. Gebruiksvriendelijkheid gaat dan wel ten koste van de veiligheid.

Normaal gesproken zal voor ieder apparaat een eigen sleutel worden gemaakt. Als je na verlies of diefstal de regel met de verloren sleutel uit ~/ssh.autorized_keys wist is het gevaar geweken. Maar je hebt 100% gelijk dat er tot die tijd een risico is!

[Johan van Dijk]

Stel je verliest je USB stick, met daarop je sleutel en andere informatie....

Niet om van topic te veranderen hoor: maar een onbeveiligde USB stick met informatie

Zo gek is dat toch niet? Als ik een stickje wil gebruiken in Ubuntu en Windows, thuis, op het werk, op school, bij de buren enz. dan formatteer ik die als fat32 of ntfs (hangt af van de grootte en wat ik er mee wil doen).
Cross-platform encryptie die betrouwbaar, gebruiksvriendelijk en te gebruiken is zonder admin rechten is er nog niet volgens mij

Wat er nog meer op die stick staat verschilt natuurlijk per persoon, maar je key icm met bijv. Putty kan al genoeg zijn.

zonder dat je ingewikkeldere dingen als encryptie moet gaan toepassen.

encryptie wordt steeds eenvoudiger in Ubuntu!

Dan zou ik graag een artikeltje zien op de wiki, waarin staat hoe je makkelijk losse mappen of usb-sticks kan versleutelen. Het versleutelen van je home is vrij eenvoudig in Jaunty, maar usb-keys...

Het kan wel... maar dan loop je weer tegen de problemen aan die ik eerder noemde: cross-platform, betrouwbaarheid, gebruiksvriendelijkheid en admin rechten.

Een usb stick die ik alleen op mijn eigen systemen kan gebruiken heb ik niet zoveel aan.

[testcees]

Cross-platform encryptie die betrouwbaar, gebruiksvriendelijk en te gebruiken is zonder admin rechten is er nog niet volgens mij

off-topic: maar ik denk aan TrueCrypt. Open source en werkt super in linux EN windows.

Mijn eigen sleutels (zonder wachtwoordzin) staan in ~/Private. Dit kan, zoals je waarschijnlijk wel weet, eenvoudig met

Code: [Selecteer]

mv ~/.ssh ~/Private
ln -s ~/Private/.ssh .sshHiermee zijn de sleutels beveiligd tegen diefstal of verlies van mij laptop of pc.
(ik gebruik wel een inlog wachtwoord voor Ubuntu)

Wat er nog meer op die stick staat verschilt natuurlijk per persoon, maar je key icm met bijv. Putty kan al genoeg zijn.

Ja, als je een key op een onbeveiligde stick plaatst is er een zeker risico bij verlies. Daar doelt de opmerking ook op. Maar ik zal de waarschuwing uitbreiden dat voor meer veiligheid beter wel een wachtwoordzin gebruikt kan worden.

Dan zou ik graag een artikeltje zien op de wiki, waarin staat hoe je makkelijk losse mappen of usb-sticks kan versleutelen. Het versleutelen van je home is vrij eenvoudig in Jaunty, maar usb-keys...

Een verzoek voor een artikel over TrueCrypt stond al onderaan de ArtikelenInAanbouw pagina. Hoort dit wel thuis op de wiki? Eigenlijk zou je deze documentatie van de TrueCrypt site willen hebben. Maar die site is helaas alleen Engelstalig. Een korte inleiding (beginners tutorial) kan maar in de Ubuntu-NL wiki moet GEEN in-depth documentatie over TrueCrypt komen, de vraag is of dat dan onderhouden zal (kan) worden.

[siegi]

Het geeft ook nadelen om de .ssh map te encrypten. De authorized_keys zitten hier ook in.
Het probleem is dat deze niet kunnen gelezen worden als de gebruiker niet ingelogd is.
Je kan dus niet meer van buitenaf op de pc geraken, met behulp van de keys.

[testcees]

@siegie: Klopt als een bus.

Zoals bij veel beveiligingsvraagstukken is de oplossing afhankelijk van het gebruik en gewenst gebruiksgemak.
Op de server(s) staat de map ~/.ssh NIET in ~/Private. De server laat ik normaal gesproken thuis en het dus niet waarschijnlijk dat ik die onderweg verlies.
Om op de gewone pc's en laptops (die zijn niet te benaderen via (poort 22) internet) via ssh in te loggen gebruik ik gewoon het gebruikers wachtwoord. Om vanaf deze pc's en laptops de server te benaderen (intern of via internet) gebruik ik de sleutels (uit ~/Private/.ssh).

[Johan van Dijk]

Cross-platform encryptie die betrouwbaar, gebruiksvriendelijk en te gebruiken is zonder admin rechten is er nog niet volgens mij

off-topic: maar ik denk aan TrueCrypt. Open source en werkt super in linux EN windows.

Je hebt dan nog steeds admin rechten nodig, of een admin moet toestemming geven. Ik denk niet dat veel werkgevers of scholen dit toe zullen staan.
http://www.truecrypt.org/docs/?s=truecrypt-portable
http://www.truecrypt.org/docs/?s=administrator-privileges

Mijn eigen sleutels (zonder wachtwoordzin) staan in ~/Private. Dit kan, zoals je waarschijnlijk wel weet, eenvoudig met

Code: [Selecteer]

mv ~/.ssh ~/Private
ln -s ~/Private/.ssh .sshHiermee zijn de sleutels beveiligd tegen diefstal of verlies van mij laptop of pc.
(ik gebruik wel een inlog wachtwoord voor Ubuntu)

Dit is een goede oplossing voor Ubuntu

Wat er nog meer op die stick staat verschilt natuurlijk per persoon, maar je key icm met bijv. Putty kan al genoeg zijn.

Ja, als je een key op een onbeveiligde stick plaatst is er een zeker risico bij verlies. Daar doelt de opmerking ook op. Maar ik zal de waarschuwing uitbreiden dat voor meer veiligheid beter wel een wachtwoordzin gebruikt kan worden.

Bedankt

Een verzoek voor een artikel over TrueCrypt stond al onderaan de ArtikelenInAanbouw pagina. Hoort dit wel thuis op de wiki? Eigenlijk zou je deze documentatie van de TrueCrypt site willen hebben. Maar die site is helaas alleen Engelstalig. Een korte inleiding (beginners tutorial) kan maar in de Ubuntu-NL wiki moet GEEN in-depth documentatie over TrueCrypt komen, de vraag is of dat dan onderhouden zal (kan) worden.

Zoals ik al eerder zei is Truecrypt maar een gedeeltelijke oplossing. In een aantal gevallen gaat dit niet werken.
Een korte handleiding is misschien toch wel een goed idee voor onze wiki

Het geeft ook nadelen om de .ssh map te encrypten. De authorized_keys zitten hier ook in.
Het probleem is dat deze niet kunnen gelezen worden als de gebruiker niet ingelogd is.
Je kan dus niet meer van buitenaf op de pc geraken, met behulp van de keys.

Je zou de authorized_keys onversleuteld in de .ssh map kunnen laten staan. Ben je niet ingelogd, dan is dat bestand gewoon te lezen. Op het moment dat je ~/Private map gemount wordt, is de complete inhoud weer gewoon te lezen via de .ssh map.
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427
Deze reactie geeft precies aan hoe dat moet: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12

[testcees]

Je zou de authorized_keys onversleuteld in de .ssh map kunnen laten staan.

Daar is over nagedacht. Dat ga ik dat ook doen.  8)

[testcees]

Toegevoegd: http://wiki.ubuntu-nl.org/community/Openssh-server#Wachtwoordzin

[Johan van Dijk]

Lees en huiver: http://gathering.tweakers.net/forum/list_messages/1355990

[testcees]

Regelmatig (dagelijks, nee: dagelijks vaak meerdere keren) lees ik in /var/log/auth:

Code: [Selecteer]

Invalid user test from xxx.xxx.xxx.xxx
en behalve 'test' een lange lijst met tientallen andere mogelijke inlognamen van systeemgebruikers als 'admin', 'web', 'ftpuser', 'guest', 'oracle', enz. En ook van tientallen (of meer?) gewone namen als 'tom', 'paul', 'susan', 'pamela', enz., enz.

En ook:

Code: [Selecteer]

User root from xxx.xxx.xxx.xxx not allowed because none of user's groups are listed in AllowGroupsen ook hier naast 'root' ook een aantal andere bestaande gebruikersnamen zoals 'mysql', 'www-data', 'backup', enz.

--> Als je een ssh server openzet voor internet is de AllowGroups parameter van belang! Bij de topicstarter op tweakers was dit blijkbaar niet gedaan, of was 'test' lid van deze groep.

En ook kom ik tegen:
Did not receive identification string from xxx.xxx.xxx.xxx

--> Het is van belang (bijna noodzakelijk?) als je een ssh server via internet wilt gebruiken je de parameter PasswordAuthentication op no zet in /etc/ssh/sshd_config :

Code: [Selecteer]

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
Wachtwoorden 'raden' is dan niet meer mogelijk omdat er ALTIJD een ssh-sleutel nodig is.

Voor de volledigheid xxx.xxx.xxx.xxx staat voor meerdere ip-adressen! Hoewel er soms wel hetzelfde patroon in namen is te herkennen. Dus het is of:
- dezelfde 'hacker' die over meerdere ip-adressen kan beschikken,
- verschillende 'hackers' die hetzelfde script gebruiken?

Het is dan ook niet verrassend dat de /var/log/auth.log en /var/log/auth.log.0 de grootste logbestanden zijn in /var/log. 

[Johan van Dijk]

Handig stukje code om te bepalen welke ip adressen het vaakst proberen in te loggen:

Code: [Selecteer]

grep sshd /var/log/auth.log |grep Invalid |awk '{print $10}' |uniq -c |sort -r
Dat levert hier dit op:

Code: [Selecteer]

      3 93.152.143.67
      3 216.146.46.93
      3 208.64.71.106
      3 202.103.69.164
      3 200.74.216.164
      3 200.25.193.89
      2 62.212.132.194
      2 200.24.219.194
      2 187.21.252.122Het eerste getal is hoe vaak het ip adres voorkomt.
Je kan zo vast wel zien hoe ik denyhosts heb ingesteld mbt het maximale aantal inlogpogingen

Verder heb ik via IPtables het aantal nieuwe verbindingen per ip adres naar poort 22 gelimiteerd op 4 per minuut.
Zo rem je de bots al behoorlijk af voordat ze door denyhosts permanent buitengesloten worden.
Tegelijkertijd geeft het geen belemmering voor normaal gebruik.

Code: [Selecteer]

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

[testcees]

Mede naar aanleiding van deze discussie heb ik de tekst wat aangescherpt over de internet toegang:
http://wiki.ubuntu-nl.org/community/Openssh-server#Internettoegang

Het script levert hier weer andere ip-adressen op. Hier de top-4:

Code: [Selecteer]

    462 93.186.192.46
    462 213.159.6.144
    201 217.73.131.32
    135 80.69.88.114
En de lijst is langer! 
Denyhost is een goede tip. Dat pakket ga ik er direct bijzetten, en de iptables regels zeker ook. Bedankt voor deze tips.

[Johan van Dijk]

Die ergste overtreders zou ik handmatig blokken via IPtables (alles van en naar die IP's droppen).

Je kan ook het IP opnemen in /etc/hosts.deny:

Code: [Selecteer]

ALL: 93.186.192.46
ALL: 213.159.6.144
enzovoortVoordeel: het is makkelijk. Het nadeel is dat niet alles beschermd wordt. Alleen de services die met tcpwrappers werken worden daarmee beschermd. (Voorbeelden zijn SSH, Telnet, FTP)

[Double12]

Ik vind de indeling van het artikel eigenlijk een beetje onoverzichtelijk. Ik zou eerst schrijven hoe je een simpele interne SSH-server opzet, en hoe je daarop inlogt met een wachtwoord van een gebruiker. Dan vertel je daarna hoe je een server beter beveiligt met een key en een passphrase.

Het hoofdstukje "Wachtwoordzin" is heel onlogisch geplaatst: je leest over een wachtwoordzin als je nog geeneens weet hoe je die moet maken.

Ook is het misschien handig om overal bij te zetten of je het op de client of op de server moet uitvoeren, dat is nu niet helemaal duidelijk. Je verwacht dat je pas in het hoofdstuk "SSH Clients" dingen op de client-machine moet uitvoeren, en dat je daarvoor alles op de server moet uitvoeren. Maar ook het aanmaken van keys moet al op de client-machine gebeuren.

[Soul-Sing]

Truecrypt kwam een aantal malen voorbij. Er zijn licentie toestanden:
TrueCrypt is *GEEN* GPL: http://www.truecrypt.org/legal/license

• Analyse @ Fedora Wiki: http://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
  
  The TrueCrypt software is under an extremely poor license, which is not only non-free, but actively dangerous to end users who agree to it, opening them to possible legal action even if they abide by all of the licensing terms. Fedora made extensive efforts to try to work with the TrueCrypt upstream to fix these mistakes in their license, but was unsuccessful.
  
  Fedora Suggests: Avoid this software entirely.

[testcees]

Double12 heeft helemaal gelijk met de opmerking dat de indeling onoverzichtelijk is geworden. Oorzaak: Het was eerst een artikel over de ssh-server en het client deel is later gekopieerd vanuit het server-installatie artikel. En de paragraaf over een wachtwoordzin is na overleg op het forum toegevoegd.

Wordt vervolgd.

[testcees]

Truecrypt ...
Fedora Suggests: Avoid this software entirely.

Ok. Dat had ik nog niet zo duidelijk begrepen, bedankt voor de info. Toch maar voor de Private map gaan?

Zoals ik al had aangegeven is de 1e aangewezen plek voor Truecrypt documentatie de Truecrypt site zelf. In ieder geval off-topic voor ssh.

[Soul-Sing]

Truecrypt ...
Fedora Suggests: Avoid this software entirely.

Ok. Dat had ik nog niet zo duidelijk begrepen, bedankt voor de info. Toch maar voor de Private map gaan?

Zoals ik al had aangegeven is de 1e aangewezen plek voor Truecrypt documentatie de Truecrypt site zelf. In ieder geval off-topic voor ssh.

offtopic: vreemd he, ik hoorde ervan via ubuntuforums. Truecrypt was altijd 1 van mijn favo progs.

[testcees]

Offtopic: De (eigen) Truecrypt licentie past niet bij Ubuntu. Uit http://en.wikipedia.org/wiki/TrueCrypt:
Licensing
The TrueCrypt Collective License does not meet the Open Source Definition, and thus has not been approved by the Open Source Initiative. It is considered "non-free" by all the major GNU/Linux distributions (Debian[12], Ubuntu[13], Fedora[14], openSUSE[15], Gentoo[16]).

Hier een toelichting van Fedora: http://lists.freedesktop.org/archives/distributions/2008-October/000276.html

[testcees]

Wordt vervolgd.

De opbouw is met wat 'knip en plakwerk' veranderd. Een extra inleiding met uitleg over de server en client rollen. Het onderdeel over ssh-sleutels is onderdeel van het client deel. Hopelijk iets duidelijker dat de ssh-sleutel-opdrachten op de client computer uitgevoerd moeten worden.
Bedankt voor de tips Double12!
http://wiki.ubuntu-nl.org/community/Openssh-server