Düzeltme: OpenVPN, Auth kullanıcı adını standart girdiden okuyamadı

could not read Auth username from stdin bir kimlik doğrulama sorunu gibi görünüyor ve değil. OpenVPN kullanıcı adını standart girdiden sormayı denedi, okunabilir hiçbir şey bulamadı ve sunucuyla hiç temas kurmadan durdu. Hesap tamamen geçerli olabilir; sürecin sormak için kimsesi yok.

Bu yüzden ilk yararlı adım, istemcinin ne okuduğunu doğrulamaktır; bağlantıyı yeniden denemek ya da sunucu tarafındaki ayarları değiştirmek değil. Aşağıdaki kontrolleri sırayla yapın ve ilk başarısız olanda durun.

Hatayı yerel bir girdi arızası olarak okuyun

Bir dosya bağımsız değişkeni olmadan auth-user-pass göründüğünde, istemci sormayı bekler. Etkileşimli bir kabukta bu istem çalışır çünkü süreç bir terminale sahiptir. systemd, cron görevi veya konteyner altında standart girdi genellikle boştur ve okuma, gördüğünüz hatayla hemen döner.

İleti, başarısız olan alanı da adlandırır, kullanıcı adı veya parola, bu da okumanın nereye kadar gittiğini gösterir. Kullanıcı adının eksik olması sürecin hiçbir şey okuyamadığı anlamına gelir. Başarılı bir kullanıcı adından sonra parolanın eksik olması, girdi akışının iki okuma arasında bittiği anlamına gelir; bu, yarı yazılmış bir dosya veya kapatılmış bir boru için tipiktir.

Başka bir şeyi değiştirmeden önce istemcinin kendi görüşünü doğrulayın. Aynı yapılandırma ve aynı kullanıcıyla ön planda çalıştırın ve istemin görünüp görünmediğine bakın. Kabuğunuzda görünüyor ama hizmet yöneticisi altında görünmüyorsa fark girdi kaynağındadır, kimlik bilgilerinde değil. Unit dosyası ile kabuk ortamınızın hızlı bir karşılaştırması genellikle hangisinin terminal sağladığını gösterir.

Hizmete desteklenen bir kimlik bilgisi kaynağı verin

Gözetimsiz çalışma için desteklenen kaynak, bağımsız değişken olarak verilen bir kimlik bilgisi dosyasıdır: auth-user-pass. Dosya düz metin olarak okunur: ilk satır kullanıcı adı, ikinci satır paroladır. Ona şu gibi mutlak bir yolla işaret edin: /etc/openvpn/client/creds , böylece hizmet hesabının çalışma dizini yönergenin anlamını değiştiremez.

İzinler yol kadar önemlidir. Dosya, istemciyi çalıştıran hesap tarafından okunabilmeli, diğer herkes tarafından okunmamalıdır ve hizmet hesabına veya hizmeti içeren bir gruba sahip root'a ait olmalıdır. İçeriği yazdırmadan o hesap olarak okunabilirliği denetleyin.

Göreli yol sessiz arıza biçimidir. Profil bir dizinde olabilirken systemd süreci başka bir yerde başlatır, bu yüzden kabuğunuzda çözülen bir dosya hizmet için çözülmez. Kimlik bilgilerini sabit bir konuma taşıyın ve onlara mutlak olarak başvurun. Sonra hizmeti bir kez başlatın ve profil düzenleyicisinin görünümüne güvenmek yerine aynı yolun kullanıldığını doğrulayın.

Dağıtım tek kullanımlık bir kod veya başka bir etkileşimli meydan okuma gerektiriyorsa, istemcinin iş akışının bunu gerçekten gözetimsiz destekleyip desteklemediğine karar verin. Statik parolalı bir dosya dönen bir koda yanıt veremez ve yanıtlanamayan bir istemi yeniden denemek bilgi eklemez.

script-security neden yardımcı olmaz

script-security istemcinin komut dosyalarını çalıştırıp çalıştıramayacağını ve onlara ne kadar aktarabileceğini denetler; bir parolanın ortam değişkeni aracılığıyla bir komut dosyasına verilip verilemeyeceği de buna dahildir. Kullanıcı adı ile parolanın başlangıçta nereden geldiği hakkında hiçbir şey söylemez.

İleti Auth'tan söz ettiği için onu daha yüksek bir düzeye çıkarmak yaygın bir refleks, ama bu girdi kaynağını değil komut dosyası izinlerini değiştirir ve istemcinin neleri yürütebileceğini genişletir. Yardımcı bir komut dosyası tasarımın parçasıysa önce girdi kaynağını düzeltin ve güvenlik düzeyini dağıtımın gerektirdiği en düşük değerde tutun.

Yönetim arayüzü meşru bir alternatiftir. Bir ön uç ona bağlanabilir, kimlik bilgisi isteğini alabilir ve kullanıcı adı ile parolayla yanıt verebilir; bazı GUI'ler böyle çalışır. Kullanırsanız yerel bir adrese bağlayın, bir yönetim parola dosyasıyla koruyun ve kimin bağlanabileceğini kısıtlayın, çünkü bu istemci için bir denetim kanalıdır.

İstemci dosyayı okuduktan sonra sonraki aşamayı doğrulayın

İstemci kimlik bilgilerini okuyabildiğinde, sonraki arıza sunucuyla gerçek bir alışveriştir ve iletisinin anlamı farklıdır. O aşamadaki bir kimlik doğrulama hatası sunucunun hesabı reddettiği anlamına gelir; bir meydan okuma yanıtı sunucunun başka bir faktör istediği anlamına gelir. Bunları aynı sorunun tekrarı değil, yeni sorunlar olarak ele alın.

Tüm yolu hizmetin çalıştıracağı gibi test edin: aynı hesap, aynı çalışma dizini, aynı unit ortamı. Yalnızca kabuğunuzdan başlatıldığında çalışan bir bağlantı, bir ortam değişkeninin veya bir terminalin hâlâ akışın parçası olduğunun işaretidir.

Sonra sırları ait oldukları yerde tutun. Komut satırı bağımsız değişkenlerindeki parolalar süreç tablosunda görünür ve hata ayıklama çıktısındaki parolalar bilete düşer. Korumalı bir dosya veya yönetim arayüzünü kullanın, günlükleri kimlik bilgilerini tekrarlamayan bir düzeyde tutun ve erişimi olan biri ayrıldığında dosyayı değiştirin.

Kontrol listesi: mutlak kimlik bilgisi yolu, hizmet hesabı olarak okunabilir, terminal gerekmez, script-security minimumunda bırakılmış, yönetim arayüzü yalnızca bağlı ve kimliği doğrulanmışsa, ve ortaya çıkan sunucu yanıtı ayrı bir olay olarak ele alınır.