curl ile Temel Kimlik Doğrulama Nasıl Kullanılır (+Örnekler)

Neden önem veriyoruz: Biz Geonode olarak proxy satışı yapıyoruz; bu nedenle, kimlik bilgilerini içeren çok sayıda komutla karşılaşıyoruz — genellikle aynı satırda hem proxy şifresi hem de hedef şifresi yer alıyor. Öncelikle belirtilmesi gereken pratik bir uyarı şudur: curl komutundaki kimlik bilgileri, kabuk geçmişinde, işlem listelerinde ve destek biletine yapıştırdığınız her şeyde yer alır. Geçerli şifrelerin yer aldığı ekran görüntülerini birden fazla kez aldık. Aşağıdaki .netrc yöntemi, bu sorunu yaklaşık bir dakika içinde ve hiçbir maliyet olmadan çözer; ayrıca, yazının sonuna doğru ele alınacak olan proxy kimlik bilgileri için de aynı şekilde geçerlidir.

Temel Sözdizimi

curl -u username:password https://api.example.com/private

curl kılavuzu, -u, --user <user:password>

seçeneğini şöyle açıklamaktadır: "Sunucu kimlik doğrulaması için kullanılacak kullanıcı adını ve şifreyi belirtin."

Basic varsayılan şemadır, bu nedenle --basic

genellikle gereksizdir. Kılavuzda da şöyle belirtilmiştir: "Uzak ana bilgisayarla HTTP Basic kimlik doğrulamasını kullanın. Bu yöntem varsayılandır ve farklı bir kimlik doğrulama yöntemi belirleyen önceden ayarlanmış bir seçeneği geçersiz kılmak için kullanmadığınız sürece bu seçenek genellikle anlamsızdır."

Aslında ağ üzerinden gönderilen şey bir başlıktır:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Bu, username:password

adresinin base64 ile kodlanmış halidir — kodlanmış, şifrelenmiş değil. İsteği görebilen herkes bunu tek adımda çözebilir. Bu nedenle, düz HTTP üzerinden temel kimlik doğrulama, şifrenizi düz metin olarak göndermekle eşdeğerdir ve bu nedenle yalnızca HTTPS üzerinden kullanılmalıdır.

Kılavuzdaki bir sözdizimi kısıtlaması: "Kullanıcı adı ve şifreler ilk iki nokta üst üste ile ayrılır; bu da bu seçenekle kullanıcı adında iki nokta üst üste kullanılmasını imkansız kılar. Şifrede ise kullanılabilir." Yani şifrede iki nokta üst üste olması sorun değildir; kullanıcı adında ise sorun oluşturur.

Komut Satırı Neden Uygun Değildir?

Kılavuz bu konuda açık sözlüdür:

Çalıştığı sistemlerde, curl verilen seçenek argümanını işlem listelerinden gizler. Ancak bu, kimlik bilgilerinin aynı sistemdeki diğer kullanıcılar tarafından görülmesini önlemek için yeterli değildir; çünkü bu bilgiler silinmeden önce bir anlığına görünür durumdadır. Bu tür hassas veriler, bunun yerine bir dosyadan veya benzeri bir yerden alınmalı ve asla komut satırında düz metin olarak kullanılmamalıdır.

Dört ayrı güvenlik açığı, hepsi gerçektir:

Kabuk geçmişi. ~/.bash_history veya zsh'deki karşılığı, düz metin olarak, süresiz olarak. İşlem listeleri. curl komutu bunları silmeden önceki kısa süre boyunca, makinedeki diğer kullanıcılar tarafından görülebilir. Günlükler. Bir komut dosyasının çalıştırdığı komutları kaydeden her şey. Yapıştırılan çıktı. Hata raporları, sorun izleme sistemleri, sohbet mesajları, ekran görüntüleri.

Sonuncusu, pratikte en yaygın olanı ve en az dikkate alınanıdır.

Üç Daha Güvenli Yöntem

1. Curl’un komut istemini kullanın. Yalnızca kullanıcı adını girin; curl, şifreyi etkileşimli olarak ister ve ekrana yansıtmadan okur:

curl -u username https://api.example.com/private

Hiçbir şey saklanmaz, hiçbir şey günlüğe kaydedilmez. Bu, elle girdiğiniz her şey için doğru yaklaşımdır.

**2. .netrc

dosyasını kullanın.** Kılavuzda -n, --netrc

şu şekilde açıklanmaktadır: "curl'un, kullanıcının ana dizinindeki .netrc dosyasını tarayarak kullanıcı adı ve şifreyi almasını sağlar... HTTP ile kullanıldığında, curl kullanıcı kimlik doğrulamasını etkinleştirir."

~/.netrc

dosyasını oluşturun:

machine api.example.com
login myusername
password mypassword

Ardından bu dosyaya kısıtlama getirin, çünkü curl bunu sizin için yapmaz — kılavuzda "curl, bu dosyanın doğru izinlere sahip olmaması durumunda hata vermez (dosya ne herkes tarafından ne de grup tarafından okunabilir olmalıdır)" şeklinde belirtilmiştir:

chmod 600 ~/.netrc
curl -n https://api.example.com/private

Kılavuzdan üç faydalı ayrıntı. "netrc dosyası, kullanılan protokol ve bağlantı noktası numarasından bağımsız olarak bir ana bilgisayar adı için kimlik bilgilerini sağlar", yani tek bir giriş bir ana bilgisayarı kapsar. --netrc-file

"dosyayı belirlemenin diğer tüm yollarını geçersiz kılar", bu da proje başına kimlik bilgisi dosyaları için kullanışlıdır. Ayrıca curl 8.16.0 sürümünden itibaren, NETRC

ortam değişkeni dosyayı belirleyebilir. Windows'ta, ana dizinde hem .netrc

hem de _netrc

dosyaları kontrol edilir; bunlardan ilki tercih edilir.

--netrc-optional

, dosya varsa onu kullanan ve yoksa hata vermeyen bir varyanttır — her iki durumda da çalışabilecek komut dosyaları için daha uygundur.

3. Bir ortam değişkeninden okuma. Bir dosya kullanmak pratik değilse, en azından geçmişte kalmasını önleyin:

read -rs API_PASS
curl -u "myuser:${API_PASS}" https://api.example.com/private

Şifrenin ekrana yansıtılmaması için read

adresindeki -s

komutuna dikkat edin. Bu, işlemin ortamında hâlâ görülebilir olduğundan, iyi bir seçenek olmaktan ziyade orta derecede bir seçenektir.

Komut dosyaları için çözüm, .netrc

komutunu chmod 600

ile birlikte kullanmaktır. Bu, kılavuzda önerilen seçenektir ve yukarıda listelenen tüm güvenlik açıklarını ortadan kaldırır.

Basic ve Diğer Şemalar

curl birçok şemayı destekler; hangisinin hangisi olduğunu bilmek, bazı karışıklıkları önler.

Digest şu şekilde belgelenmiştir: "HTTP Digest kimlik doğrulamasını etkinleştirin. Bu kimlik doğrulama şeması, şifrenin ağ üzerinden düz metin olarak gönderilmesini önler. Kullanıcı adı ve şifreyi ayarlamak için bunu normal --user seçeneğiyle birlikte kullanın."

--anyauth, kılavuzda açıkça belirtildiği üzere bir bedeli olan kolaylık sağlayan bir seçenektir: "Kimlik doğrulama yöntemini otomatik olarak belirleyin ve uzak sitenin desteklediğini iddia ettiği en güvenli yöntemi kullanın. Bu, önce bir istek gönderip yanıt başlıklarını kontrol ederek yapılır; dolayısıyla muhtemelen fazladan bir ağ gidiş-dönüşü gerektirebilir."

İstek başına fazladan bir gidiş-dönüş, yüksek hacimde ücretsiz değildir. Ayrıca kılavuzda uyarıldığı gibi belirli bir hata durumu vardır: "stdin'den yükleme yapıyorsanız --anyauth kullanılması önerilmez, çünkü bu durum verilerin iki kez gönderilmesini gerektirebilir ve bu durumda istemcinin geri sarma yapabilmesi gerekir. stdin'den yükleme yaparken bu ihtiyaç ortaya çıkarsa, yükleme işlemi başarısız olur."

Öyleyse: sunucunun ne istediğini gerçekten bilmiyorsanız --anyauth kullanın ve ne istediğini öğrendiğinizde şemayı belirtin.

Bearer tokenleri, günümüz API'lerinin çoğunda kullanılan yöntemdir ve bunlar temel kimlik doğrulama (basic auth) ile hiçbir ilgisi yoktur:

curl --oauth2-bearer "mF_9.B5f-4.1JqM" https://api.example.com/me

Bu, Authorization: Bearer ... ayarını manuel olarak yapmakla eşdeğerdir. Bearer tokeninin kendisi kimlik bilgisi olduğunu unutmayın — elinde bulunduran herkes bunu kullanabilir — bu nedenle bir şifre ile aynı özenle ele alınması gerekir.

Yanıtı Okuma

Kimlik doğrulama başarısız olduğunda izlenebilecek kısa bir tanılama yolu.

**401 Unauthorized

**, sunucunun kimlik bilgilerini istediği veya gönderdiğiniz bilgileri reddettiği anlamına gelir. Yanıtta, sunucunun beklediği şemayı belirten bir WWW-Authenticate

başlığı bulunur ve bunu okumak, tahminde bulunma zahmetinden kurtarır:

curl -sS -o /dev/null -D - https://api.example.com/private | grep -i www-authenticate

Eğer başlıkta Digest

yazıyorsa ve siz Basic göndermişseniz, işte cevabınız budur.

**403 Forbidden

** farklı bir durumdur ve sıklıkla yanlış yorumlanır. Kimlik doğrulamanız başarılı olmuştur ancak bu işlemi gerçekleştirme izniniz yoktur. Şifrenizi değiştirmek bir fayda sağlamaz; izinlerinizi değiştirmek ise işe yarayabilir.

**407 Proxy Authentication Required

**, kimlik bilgilerini isteyenin hedef değil, proxy olduğunu gösterir. Farklı bir başlık, farklı bir seçenek; bu konu bir sonraki bölümde ele alınacaktır.

**Giriş sayfası içeren bir 200

**, uç noktanın HTTP kimlik doğrulamasını hiç kullanmadığı anlamına gelir — bir form ve oturum çerezi kullanır ve -u

bu durumda hiçbir işe yaramaz. Content-Type

adresini kontrol edin: JSON bekliyordunuz ve text/html

aldıysanız, muhtemelen olan budur.

Gerçekte ne gönderdiğinizi doğrulamak için:

curl -v -u user:pass https://api.example.com/private 2>&1 | grep -i '^> authorization'

Kılavuzdaki, ayrıntılı çıktının "kullanıcı adları, kimlik bilgileri veya gizli veri içeriği dahil olmak üzere hassas veriler içerebileceği" uyarısını unutmayın — paylaşmadan önce gizli bilgileri sansürleyin.

Başlığı Kendiniz Oluşturma

Bazen -u istediğiniz sonucu vermez; bu işlevin gerçekte ne ürettiğini bilmek, sınırlamalarını aşmanıza olanak tanır.

Kullanıcı adı iki nokta üst üste içeriyorsa. -u ilk iki nokta üst üste işaretinde bölünür; bu nedenle service:reader gibi bir kullanıcı adını ifade etmek imkânsızdır. Başlığı doğrudan oluşturun:

CRED=$(printf '%s' 'service:reader:mypassword' | base64 -w0)
curl -H "Authorization: Basic ${CRED}" https://api.example.com/private

echo yerine printf kullanın; çünkü , kodlanmış kimlik bilgilerinin içine bir satır sonu ekler ve kafa karıştırıcı bir 401 hatasına neden olur. Ayrıca, satır sarılmasını önlemek için base64 -w0 kullanın — GNU base64 varsayılan olarak 76 karakterde satır sarar ve içine satır sonu eklenmiş bir başlık, biçim hatası içeren bir istek olarak değerlendirilir. macOS'ta, düz base64 satır sarmaz ve bayrağa gerek yoktur.

Gizli bilgi yöneticisinden kimlik bilgilerine ihtiyacınız olduğunda. Çoğu gizli bilgi aracı stdout'a çıktı verir ve değeri bir dosyada değil bir değişkende tutmak, ömrünü sınırlar:

TOKEN=$(vault kv get -field=token secret/api)
curl -H "Authorization: Bearer ${TOKEN}" https://api.example.com/me

Başlığı komuttan ziyade bir yapılandırma dosyasında tutmak istediğinizde. curl, seçenekleri ~/.curlrc adresinden veya -K biçiminde adlandırılmış bir dosyadan okur:

# api-auth.conf
--user "myuser:mypassword"
--header "Accept: application/json"

curl -K api-auth.conf https://api.example.com/private

chmod 600 ile dosyayı kısıtlayın. Bu, .netrc 'un uygun olmadığı durumlarda — örneğin, kullanıcı adı ve şifre yerine bir token'a ihtiyacınız olduğunda — makul bir orta yoldur.

Özellikle ~/.curlrc ile ilgili bir uyarı. Bu, o kullanıcı tarafından yapılan her curl çağrısı için geçerlidir; sizin yazmadığınız çağrılar da dahil. Kimlik bilgilerini buraya koymak, herhangi bir komut dosyasının talep ettiği herhangi bir ana bilgisayara bu bilgileri göndermek anlamına gelir. Hassas bilgiler için -K ile adlandırılmış bir dosya kullanın ve ~/.curlrc adresini --show-error ve --location gibi zararsız varsayılan ayarlar için saklayın.

Proxy Kimlik Doğrulaması Ayrıdır

Destek kuyruğumuzda en çok kafa karışıklığına neden olan ayrım budur.

İki bağımsız kimlik bilgisi kümesi söz konusu olabilir: biri proxy için, diğeri hedef için. Bunlar farklı başlıklar, farklı durum kodları ve farklı curl seçenekleri kullanır.

curl -x http://proxy.example.com:9000 \
     --proxy-user proxyuser:proxypass \
     -u apiuser:apipass \
     https://api.example.com/private

--proxy-user komutu proxy'de kimlik doğrulaması yapar; -u komutu ise hedefte kimlik doğrulaması yapar. Bunları karıştırmak, 401 hatası beklerken 407 hatası almanıza veya tam tersi bir duruma yol açar.

Proxy şemasında, hedef tarafındakilerin aynısı olan paralel seçenekler vardır — --proxy-basic , --proxy-digest , --proxy-anyauth , --proxy-negotiate .

İki pratik not.

Proxy URL’sindeki kimlik bilgileri de aynı maruz kalma sorununa sahiptir, üstelik bir sorun daha vardır. -x http://user:pass@proxy:9000 , şifreyi komut satırına ve proxy URL’sini barındıran herhangi bir ortam değişkenine yerleştirir; http_proxy genellikle bu ortam değişkeninde bulunur. Şifredeki @ , : veya / adreslerini yüzde kodlayın; aksi takdirde URL ayrıştırıcısı yanlış yerde bölünecektir.

Tahminde bulunmak yerine, sizi hangi hop'un reddettiğini ayırt edin:

curl -sS -o /dev/null -x "$PROXY" \
  -w 'connect=%{http_connect} status=%{response_code}\n' \
  https://api.example.com/private

connect=407 , proxy'nin sizi reddettiği ve hedefe hiç ulaşamadığı anlamına gelir. connect=200 status=401 ise proxy'nin çalıştığı ve hedefin kimlik bilgilerini istediği anlamına gelir. İki farklı çözüm vardır.

Ve proxy kimlik doğrulamasına özgü bir not: birçok sağlayıcı, kullanıcı adı ve şifreye alternatif olarak IP izin listesi sunar. Kaynak adresiniz sabitse, bu komutlarınızdan kimlik bilgilerini tamamen ortadan kaldırır; bu, mevcut en temiz çözümdür — dosya yok, ortam değişkeni yok, sızabilecek hiçbir şey yok.

Site HTTP Kimlik Doğrulamasını Hiç Kullanmadığında

“curl basic auth çalışmıyor” bildirimlerinin büyük bir kısmı, sitenin başından beri HTTP kimlik doğrulamasını hiç kullanmadığı durumlardır.

Nasıl anlaşılır? Kimlik bilgileri olmadan korumalı URL'yi isteyin ve yanıtı inceleyin:

curl -sS -o /dev/null -D - https://example.com/dashboard

WWW-Authenticate

başlığı içeren bir 401

, HTTP kimlik doğrulaması anlamına gelir ve -u

doğru araçtır. Bir 200

adresinin oturum açma sayfası döndürmesi veya bir 302

adresinin /login

adresine yönlendirmesi, sitenin bir form ve oturum çerezi kullandığı anlamına gelir — ve -u

adresini ne kadar kullanırsanız kullanın bir işe yaramaz, çünkü bu başlığı okuyan hiçbir şey yoktur.

Bunun yerine formla oturum açma modeli. Kimlik bilgilerini oturum açma uç noktasına gönderin, çerezleri saklayın ve yeniden kullanın:

curl -c jar.txt -d "username=ada&password=secret" \
     https://example.com/login

curl -b jar.txt https://example.com/dashboard

-c

bir çerez kavanozu yazar ve -b

bir çerez okur. Sunucu oturum çerezini değiştiriyorsa (çoğu sunucu bunu yapar), sonraki isteklerde (-b jar.txt -c jar.txt

) her ikisini de kullanın.

Karşılaşacağınız zorluk: CSRF belirteçleri. Çoğu oturum açma formu, kimlik bilgileriyle birlikte gönderilmesi gereken ve her oturum için ayrı ayrı oluşturulan gizli bir belirteç içerir. Bu, iki aşamalı bir işlem anlamına gelir — formu alın, belirteci çıkarın ve birinci adımda elde ettiğiniz çerezlerle birlikte gönderin:

TOKEN=$(curl -sS -c jar.txt https://example.com/login \
        | grep -o 'name="csrf_token" value="[^"]*"' \
        | cut -d'"' -f4)

curl -b jar.txt -c jar.txt \
     -d "csrf_token=${TOKEN}" -d "username=ada" -d "password=secret" \
     https://example.com/login

HTML üzerinde grep ve kesme işlemleri güvenilmezdir ve tek seferlik bir tanılama için uygundur. Sürekli bir işlem söz konusuysa, önce hizmetin jetonla kimlik doğrulamalı bir API sunup sunmadığını kontrol edin — neredeyse her zaman sunar ve bu, kendi giriş formunuz için bir kazıyıcı sürdürmekten çok daha az çaba gerektirir.

Giriş işlemi JavaScript gerektiriyorsa, curl bunu hiç yapamaz. Bu, aşılması gereken bir curl sınırlaması değildir; sayfanın kendisinin çağırdığı API uç noktasını aramanız gerektiğinin bir işaretidir. Bu uç noktayı tarayıcınızın ağ sekmesinde bulabilir ve doğrudan yeniden oluşturabilirsiniz.

Sık Sorulan Sorular

curl ile temel kimlik doğrulamayı nasıl kullanırım?

curl -u username:password URL. Temel kimlik doğrulama, curl’un varsayılan yöntemidir; bu nedenle, önceden ayarlanmış bir yöntemi geçersiz kılmadığınız sürece --basic kullanımı gereksizdir. Temel kimlik doğrulama, kimlik bilgilerini şifrelemek yerine base64 ile kodladığından, her zaman HTTPS kullanın.

curl'un şifre istemesini nasıl sağlarım?

Yalnızca kullanıcı adını girin: curl -u username URL. curl, şifreyi etkileşimli olarak ister ve ekrana yansıtmaz; böylece hiçbir bilgi kabuk geçmişinize veya işlem listelerinize ulaşmaz. Bu, elle yazılan her şey için doğru yaklaşımdır.

curl'un temel kimlik doğrulaması güvenli midir?

Yalnızca HTTPS üzerinden güvenlidir. Kimlik bilgileri Base64 ile kodlanır ve bu kodlama kolayca geri dönüştürülebilir; dolayısıyla düz HTTP üzerinden aktarıldığında, bu bilgiler fiilen açık metin halindedir. TLS üzerinden aktarım sırasında bu bilgiler korunur; geriye kalan risk, bunları kendi makinenizde nerede sakladığınıza bağlıdır.

curl kimlik bilgilerini bir dosyada nasıl saklayabilirim?

~/.netrc dosyasını kullanın ve içine machine, login ve password satırlarını ekleyin, ardından dosyayı chmod 600 komutuyla işleyin ve curl'u -n komutuyla çalıştırın. curl, yanlış izinler konusunda uyarı vermez; bu nedenle izinleri ayarlamak size kalmıştır. --netrc-file alternatif bir konuma işaret eder ve --netrc-optional dosyası mevcut olmadığında hatanın oluşmasını önler.

Şifrem doğru olmasına rağmen curl neden 401 hatası veriyor?

Birkaç olasılık vardır: sunucu farklı bir şema bekliyor olabilir — WWW-Authenticate başlığını kontrol edin — ya da uç nokta HTTP kimlik doğrulaması yerine çerezlerle form üzerinden oturum açma kullanıyor olabilir, ya da kullanıcı adınızda iki nokta üst üste (:) varsa, -u ilk iki nokta üst üsteyi ayırdığı için bunu ifade edemez.

401 ile 403 arasındaki fark nedir?

401, kimlik doğrulamanızın yapılmadığı anlamına gelir: kimlik bilgileri yok veya yanlış. 403 ise kimlik doğrulamanızın başarıyla yapıldığı, ancak bu işlemi gerçekleştirmenize izin verilmediği anlamına gelir. Farklı kimlik bilgileriyle yeniden denemek, ilk durumda yardımcı olur, ikinci durumda ise olmaz.

Curl ile bir proxy'ye nasıl kimlik doğrulaması yapabilirim?

Hedef için -u adresinden ayrı olan --proxy-user user:password adresini kullanın. 407 durumu, proxy'nin kimlik bilgisi istediği anlamına gelir; 401 ise hedefin istediği anlamına gelir. Kaynak adresiniz sabitse, bunun yerine sağlayıcınıza IP izin listesi eklemeyi sorun — bu, komutlarınızdan kimlik bilgilerini tamamen ortadan kaldırır.

--anyauth ne işe yarar?

Bu seçenek, curl'un bir istek gönderip yanıt başlıklarını okuyarak sunucunun tercih ettiği şemayı tespit etmesini ve ardından sunulan en güvenli yöntemle kimlik doğrulaması yapmasını sağlar. Bunun bedeli, istek başına ekstra bir gidiş-dönüş işlemidir; kılavuzda, verilerin iki kez gönderilmesi gerekebileceğinden stdin'den yükleme yaparken bu işlemin başarısız olabileceği konusunda uyarı bulunmaktadır.

Sonuç

Sözdizimini anlamak biraz zaman alır: -u username:password komutuyla, curl’ün varsayılan şeması olan “basic” kullanılarak kimlik doğrulamanız yapılır. Dikkat edilmesi gereken kısım, şifrenin nerede yer aldığıdır.

curl'un kendi kılavuzu bu konuda oldukça nettir — kimlik bilgileri "bir dosya veya benzeri bir yerden alınmalı ve asla komut satırında düz metin olarak kullanılmamalıdır" — ve uyarıldığı güvenlik açıklarının hepsi gerçektir. Shell geçmişi bunları süresiz olarak saklar, işlem listeleri bunları makinedeki herkese kısa bir süreliğine maruz bırakır ve yapıştırılan terminal çıktısı, istemediğiniz yerlere ulaşma konusunda şaşırtıcı bir yeteneğe sahiptir.

İki alışkanlık bu sorunu çözer. Etkileşimli kullanım için yalnızca kullanıcı adını girin ve curl'un sorusunu bekleyin. Komut dosyaları için, kimlik bilgilerini ~/.netrc dosyasına chmod 600 ile kaydedin ve -n komutunu kullanın. Her ikisi de şifreyi yazmaktan daha uzun sürmez.

Ayrıca, iki kimlik doğrulama katmanını birbirinden ayırın. 401 hatası hedef sunucudan gelir ve -u bilgisini ister; 407 hatası ise proxy sunucusundan gelir ve --proxy-user bilgisini ister. Adresiniz sabitse, bir izin listesi komutlarınızdaki ikinci kimlik bilgisini tamamen ortadan kaldırır — bu da bir gizli bilginin saklanabileceği tek gerçekten güvenli yerdir.