Via VPN-ŝlosilo estas legebla de ĉiuj: kion ripari

La unua signo kutime estas averto, ne paneo. Kliento rifuzas ŝargi ŝlosilon ĉar la dosiero estas legebla de la grupo aŭ de ĉiuj, aŭ sekureca revizio trovas client.key kun reĝimo 644 en profila dosierujo, kiu ankaŭ enhavas eksportitajn pakaĵojn. Nenio ankoraŭ fiaskis, kaj ĝuste tial la averto estas ignorata. La ŝlosilo funkcias, la tunelo leviĝas, kaj la dosiero estas legebla de ĉiu konto en la maŝino.

La simptomo estas permesa averto, ne paneo

En Unix-simila sistemo privata ŝlosilo devus esti legebla nur de la konto, kiu rulas la servon. Reĝimo 600 kun la ĝusta posedanto estas la ordinara aranĝo. Reĝimo 644 signifas, ke ĉiu loka uzanto povas kopii la ŝlosilon, kaj en komuna konstrua gastiganto tio estas reala publiko.

Klientoj, kiuj kontrolas tion, faras al vi komplezon. Tiuj, kiuj ne kontrolas, ne estas pruvo, ke la dosiero estas sekura, kaj sukcesa konekto diras nenion pri tio, kiu alia povas legi la materialon, kiu ebligis ĝin. Traktu la averton kiel la tutan konstaton. Ĝi estas preciza, kaj ĝi venis antaŭ ol iu kopiis la dosieron.

Agordigu la reĝimon al la servo-identeco

Aliro nur por la posedanto taŭgas por ŝlosilo uzata de tiu posedanto. Servo kun intence dividita grupo eble bezonas alian kontrolitan aranĝon, ekzemple grupan legadon de ŝlosilo posedata de serva konto. Blinde meti ĉiun dosieron al unu numera reĝimo rompas subtenatajn klientojn, kaj chmod -R 777 ne solvas ion ajn.

Kontrolu la posedanton kaj la servan konton antaŭ ol ŝanĝi ion. Publikaj CA-atestiloj kaj privataj identecaj ŝlosiloj havas malsamajn postulojn pri sekreteco eĉ kiam ili estas en la sama dosierujo, do rekursiva reĝimo sur la tuta dosierujo traktas ambaŭ kiel la saman objekton.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

Sur aliaj platformoj uzu la dokumentitan ŝlosilujon aŭ alirkontrolan modelon anstataŭ traduki Unix-reĝimojn en konjekton. Dosiernomo finiĝanta per private estas etikedo, ne trudmekanismo.

Trovu la kopiojn, kiujn la reĝimo ne kovras

Redaktiloj, sekurkopiaj arkoj, eksportitaj profiloj kaj provizoraj pakaĵoj povas ĉiu reteni la saman identecon. Protektu tiujn kopiojn laŭ ilia enhavo, ĉar streĉi la originalan dosieron faras nenion por tiu en la tar-arĥivo de la pasinta monato.

Pasfrazo sur ŝlosila dosiero utilas por konservita materialo kaj ne pravigas publikigi la ĉifritan dosieron apud ĝia pasvorto. Permesoj protektas la nunan dosiersisteman objekton; ili diras nenion pri akreditaĵo jam kopiita aliloken.

Serĉu la kopiojn antaŭ ol deklari la taskon finita: grep -rl la kaplinio de la ŝlosilo en verŝajnaj dosierujoj, kaj rigardu sekurkopiajn ekskludojn. La rezulto kutime pli interesas ol la dosiero, kun kiu vi komencis.

Post la riparo: kontrolu kaj anstataŭigu

Testu, ke la celita servo ankoraŭ aŭtentikigas, poste konfirmu, ke neniu nenecesa konto ricevis aliron. Limigu diagnozan eligon al metadatenoj, ĉar presi la ŝlosilon ne necesas por pruvi, ke la dosiero estas legebla kaj ĝi metas la materialon en protokolon.

Se la ŝlosilo estis elmetita, streĉu la reĝimon, poste anstataŭigu la akreditaĵon kaj revoku la malnovan. La specifo POSIX chmod klarigas, kion signifas ĉiu reĝima bito, kio indas scii antaŭ ol la sekva revizio petos vin pravigi la nombron, kiun vi elektis.