Vraag Hoe SSH-hostsleutels op Linux toe te staan ​​(Fedora 10 & CentOS 5.2)


Ik probeer SSH-hostsleutels op te zetten vanaf onze Mac OS X 10.5 Leopard Server-gebaseerde centrale back-upserver naar onze twee Linux-servers met Fedora 10 en CentOS 5.2. Het proces dat we meestal nemen werkt en plaatst de sleutel in ~ / .ssh / authorized_keys, maar vraagt ​​toch om het wachtwoord.

Ik ben niet de reguliere beheerder van deze boxen en ik begrijp dat de standaard waarschijnlijk is dat SSH-hostsleutels zijn uitgeschakeld. Hoe kunnen SSH-hostsleutels worden ingeschakeld?

Bijwerken: Ik had al een ongecommentarieerde 'PubkeyAuthentication yes' in / etc / ssh / ssd_config en liep service restart sshd, maar dat werkte niet. Niet-gecommenteerde alle drie de regels ('RSAAuthentication', 'PubkeyAuthentication' en 'AuthorizedKeysFile'), gecorrigeerde machtigingen op ~ / .ssh en opnieuw geprobeerd. Nog steeds geen liefde.

Wanneer ik ren ssh -v user@host Ik krijg het volgende voordat het vraagt ​​om een ​​wachtwoord en na een aantal GSS-fouten:

debug1: Next authentication method: publickey
debug1: Trying private key: /Users/shortname/.ssh/identity
debug1: Trying private key: /Users/shortname/.ssh/id_rsa
debug1: Trying private key: /Users/shortname/.ssh/id_dsa
debug1: Next authentication method: password

Verdere suggesties?

Nog een update: Machtigingen op ~/ en ~/.ssh/ zijn 700.

De opdracht die ik heb uitgevoerd om de hostsleutel te maken, is als volgt:

cat /blah/ssh_keys_for_shortname/id_dsa.pub | ssh -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld 'cat - >> ~/.ssh/authorized_keys'

En bij het proberen te verbinden gebruik ik:

ssh --verbose -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld

We gebruiken dus duidelijk DSA-sleutels. Ik heb het hernoemen geprobeerd ~/.ssh/authorized_keys2, maar dat helpt niet.

Ik wil de sleutels graag op hun standaardlocaties opslaan in plaats van /blah/ssh_keys_for_shortname/, maar het is buiten mijn controle.

Wanneer ik kijk /var/log/audit/audit.log en probeer verbinding te maken, ik krijg het volgende:

type=CRED_DISP msg=audit(1249426114.642:128): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:setcred acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_END msg=audit(1249426114.647:129): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:session_close acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_LOGIN msg=audit(1249426129.524:130): user pid=10633 uid=0 auid=4294967295 ses=4294967295 msg='acct="shortname": exe="/usr/sbin/sshd" (hostname=?, addr=192.168.1.149, terminal=sshd res=failed)'

Iets te melden?


4
2017-08-03 19:50


oorsprong




antwoorden:


Lijkt erop dat je de basis correct hebt.

De meest voorkomende reden die ik heb gezien om dit te laten mislukken, is de rechten op de afstandsbediening authorized_keys bestand en de mappen erboven. Voordat je op sleutels gebaseerde authenticatie toestaat, sshd voert een machtigingscontrole uit; als het de resultaten niet bevalt, staat het authenticatie niet toe. Ik ging meestal op weg ~/.ssh tot 0700 en ~/.ssh/authorized_keys tot 0600. Ik geloof dat de werkelijke $ HOME ook geen groeps- of wereldschrijven kan hebben, hoewel het lezen prima is.

Als dat nog steeds niet lukt, is de volgende stap om wat foutopsporing aan de serverzijde uit te voeren:

server$ /usr/sbin/sshd -d -p 2222

Maak vervolgens verbinding met de "debug" -server vanaf uw client:

client$ ssh -v user@host  -p 2222

U krijgt uitgebreide informatie over debuggen stderr op de server. Ik moet nog een auth-probleem tegenkomen dat ik niet van daaruit kon opsporen.


10
2017-08-03 22:25



Hmmm ... Ik zie dat je zegt dat je de perms op authorized_keys al hebt opgelost. Kun je de uitvoer van "ls -ld ~ user" en "ls -lr ~ user / .ssh" plakken? - Insyte
Mijn collega kwam ditzelfde probleem vorig weekend opnieuw tegen op een ander project en was in staat om het op te lossen met mode 0700 op ~ / .ssh, mode 0600 op ~ / .ssh / authorized_keys en een chmod go-w ~/. IIRC, de thuismap was al modus 0755 dus ik weet niet zeker waarom het verwijderen van groeps- / andere schrijftoegang iets heeft gewijzigd, maar het loste het probleem wel op. Tenslotte! Ik ga je antwoord markeren als de oplossing. - morgant
Dezelfde problemen op mijn fedora-systeem. Het verwijderen van de schrijfrechten voor groepen in de hoofddirectory loste uiteindelijk het probleem op. - Spacemoose


Dit is het proces dat ik zou volgen.

  1. Maak een publiek / privaat sleutelpaar op de OS X-server. Ik geef geen wachtwoordzin op wanneer daarom wordt gevraagd.

    $ ssh-keygen -b 4096 -C "myusername @ myhostname" -t rsa

  2. Kopieer de inhoud van ~ / .ssh / id_rsa.pub op de OS X-server naar ~ / ssh / authorized_keys in de hoofddirectory van de juiste gebruiker op de CentOS / Fedora-hosts.

  3. Controleer of de rechten op alle hosts correct zijn. De directory ~ / .ssh moet mode 0700 zijn, de bestanden binnen moeten 0600 zijn (je kunt 0644 gebruiken voor de publieke sleutels, maar het doet geen pijn meer restrictief te zijn).

Als de op sleutels gebaseerde verificatie nog niet werkt, controleer dan of de volgende waarden zijn ingesteld in uw sshd_config-bestand (/ etc / ssh / sshd_config) op elk van de CentOS / Fedora-hosts. (Deze waarden moeten standaard zijn.)

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys

Als het nog steeds niet werkt, probeer het dan ssh -v user@host om te zien wat er gebeurt als je verbinding maakt. Voeg meer v's toe voor meer informatie over wat er gebeurt.

BEWERK: Probeer de machtigingen voor de volledige mapstructuur van / naar de map .ssh in kwestie te verifiëren. Als een van de mappen in dat pad groeps- of wereldbeschrijfbaar is, zal SSH bombarderen. Voer dit uit om de rechten van alle mappen in het pad af te drukken:

j="" ; for i in `echo ~baumgart/.ssh | sed 's%/% %g'` ; do ls -ld $j/$i ; j=$j/$i ; done

Controleer ook het logbestand op berichten van sshd op de CentOS / Fedora-systemen. Dat zou een nuttige boodschap moeten zijn over wat er mis is. Het zou in / var / log / messages moeten zijn of /var/log/auth.log. Als je het niet kunt vinden, doe het dan grep sshd /var/log/*.


4
2017-08-03 20:00



In plaats van direct ~ / ssh / authorized_keys op de externe host te bewerken, kan men het script ssh-copy-id gebruiken dat bij de meeste Linux-distro's wordt geleverd. Ik heb het script niet van OSX gebruikt, maar het is vrij eenvoudig en zou moeten werken. Het controleert niet op dubbele invoer. - Not Now


Als u de gebruikers- / groepsrechten juist hebt ingesteld, zijn er mogelijk SELinux-problemen. De gemakkelijkste manier om dit op te lossen, is met restorecon -R /home/user/.ssh/. De fouten worden ingelogd /var/log/audit/audit.log en je kunt de gebruiken audit2why hulpmiddel om het systeem alle SELinux-ontkenningen te laten verklaren die mogelijk zijn opgetreden.


2
2017-08-04 01:54



Bedankt. Ik herinner me dat we in het verleden een aantal SELinux-problemen tegenkwamen en de vaste beheerder van die doos zei dat hij het had uitgeschakeld. Ik heb de restorecon commando hoe dan ook en keken /var/log/audit/audit.log en zag geen fouten tijdens een poging om in te loggen (alles zei "succes"). Ik zal blijven graven. - morgant
De opdracht sestatus geeft aan of SELinux is afgedwongen / toegestaan ​​/ uitgeschakeld. Het is meestal het beste om het in Toegeeflijk te laten wanneer je iets fout probeert te draaien, omdat je de weigeringen gedocumenteerd zult zien, maar je acties zullen slagen zoals wanneer het werd uitgeschakeld. - Ophidian
sestatus geeft "SELinux-status: uitgeschakeld" terug. - morgant


Het eerste ding om erop te wijzen is dat de /var/log/audit.log is loggen SELinux activiteit.

Ik vermoed dat als je wat verder terug in dat logboek kijkt, je een ander bericht ziet dat er ongeveer zo uitziet:

type=AVC msg=audit(xxxxxxxxx.xxx:xxxx): avc: denied { search } for pid=xxxxx comm="sshd" name="xxxxxx" dev=xxxx ino=xxxxxx scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir

Wat dit betekent is dat je sshd-proces wordt beperkt door het geladen selinux-beleid en niet in staat is om toegang te krijgen tot het bestandssysteempad waarin je geautoriseerde sleutelsbestand zit.

Om te controleren of het selinux-beleid actief is, voert u de sestatus commando en je ziet de volgende output:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted

Om snel te testen of dit het probleem is of niet, kun je SELinux tijdelijk instellen in de permissieve modus door problemen met de setenforce permissive commando. Nadat u dit hebt gedaan, start u sestatus nogmaals en je zou de volgende output moeten zien:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted

Probeer uw ssh-verbinding opnieuw, en aangezien al uw andere configuratie correct is, zou het moeten werken.

In de toekomst zou je waarschijnlijk aangepaste regels moeten maken die toegang geven tot het pad dat je zoekt, maar dat valt buiten het bereik van deze hulp.

Om deze wijziging persistent te maken (overleef reboots), moet u de /etc/selinux/config bestand en verandering:

SELINUX=enforcing

naar

SELINUX=permissive

2
2017-12-13 14:01





'PubkeyAuthentication yes' in / etc / ssh / sshd_config?


1
2017-08-03 19:59