Yanlış sunucuya bağlanmaya çalıştığınızda SSH şifreniz ortaya çıkıyor mu?

192

Yanlışlıkla yanlış sunucuya şifre kimlik bilgileriyle bağlanmaya çalıştığınızda, yöneticinin kullandığınız şifreyi okuması ve kaydetmesi mümkün müdür?

ssh password

— vfclists
kaynak

11

SSH şifre doğrulama, sunucuya şifre sağlıyor mu?

— jamesdlin

41

Bir ssh istemcisinde, önce sunucunun kimliğini doğrularsın ve "Bu sunucuya şifremi söyleyebileceğime inanıyorum" diyorsun. Bir dahaki sefere ilk gördüğünüz mesaja daha fazla dikkat edin: "X'in gerçekliği tespit edilemez. RSA anahtar parmak izi Y olduğundan emin misiniz Z? (Evet / hayır)" Bu can sıkıcı soru sorulmayacaktı her defasında evet'i otomatik olarak cevaplamak için .

— kubanczyk 15:16

6

PasswordAuthentication noOpenSSH'de varsayılan olarak ayarlamak mümkündür ve yalnızca güvenilir sunucular için (gerekirse / gerektiğinde) etkinleştirebilirsiniz. Sıkı ana bilgisayar anahtar kontrolü ile birleştirildiğinde, bu işlem sizi genellikle şifreniz karşılığında parolanızı ifşa etmekten korumalıdır.

— Ocaklar

6

@kubanczyk, eğer "internal-www.my-company.com" yazıp SSH'ye yazdıysanız, ancak yanlışlıkla "ssh www.my-company.com" yazıyorsanız, bu bilgi istemi sizi korumaz - muhtemelen iki sunucunun da güvenilir listenizde, bunlardan sadece biri sizin tarafınızdan, diğeri ise üçüncü taraflarca yönetilir.

— Mark

@hobbs ChallengeResponseAuthentication node sanırım

— ilkkachu 16:16

215

Basit bir şekilde: evet

Daha fazla detay...

Makineme bağlanırsanız, normal bir sshsunucu mu kullandığımı veya geçirilen şifreyi yazmak için değiştirilmiş bir sunucu mu kullandığımı bilmiyorsunuz .

Dahası, mutlaka değiştirmem gerekmeyecek sshdancak pam_scriptşifrenizin iletileceği bir PAM modülü yazabilirim (örn. Kullanarak ).

Yani evet. Şifrenizi ASLA güvenilmeyen bir sunucuya göndermeyin. Makinenin sahibi, denenen tüm şifreleri günlüğe kaydetmek için kolayca yapılandırabilirdi.

(Aslında bu infosec dünyasında nadir değildir; girilen şifreleri kaydetmek için bir honeypot sunucusu kurmak)

— Stephen Harris
kaynak

13

Doğru. Varsayılan olarak, standart sshdyok değil şifreleri açın. (Şifrenizi bir giriş adı olarak girerseniz, giriş yapılır ancak bu başka bir problemdir). Standart sshdbir güvenlik aracıdır ve bu nedenle bu gibi kimlik bilgilerini

— Stephen Harris

116

Herkese açık / özel anahtar çiftleri kullanmak için başka bir neden ...

— gerrit

3

Bir süredir şifrelerimi kullandığımı merak ediyordum ve son zamanlarda yanlış sunuculara giriş yapmayı denemek, şifremi kötü niyetli bir sunucu yöneticisine bildirmenin iyi bir yol olacağını açıkladı.

— vfclists

10

@vfclists yanlış sunucuya giriş yapmak, aynı zamanda sshd istemcinizin her sunucu için parmak izi kaydetmesinin nedenidir. İlk bağlandığınızda, bu parmak izini kabul edersiniz, daha sonra uymazsa, dikkat etmeniz gereken dev bir uyarı alırsınız.

— hometoast

44

Daha iyi tavsiye: ssh için asla şifre kimlik doğrulaması kullanmayın . Protokolün çok iyi nedenlerden dolayı pubkey auth var; kullan!

— R.,

52

Evet.

Şifre şifreli bağlantı kurulduktan sonra gönderilir, ancak uzak sunucu şifreyi düz metin olarak alır.

Bunu umursuyorsanız, en iyi ve en kolay çözüm SSH anahtarlarını kullanmaktır.

Anahtar kabul edemeyen makineleriniz varsa, çözümlerden biri, şifrelerinizi güvenli bir şekilde saklayan bir araç oluşturmak ve ardından sshpassbağlandığınız sunucuya bağlı olarak her zaman doğru şifreyi göndermek için kullanılır.

Şimdi, parolanın düz metin olarak gönderilmesinin nedeni, onu kullanma ve saklama konusundaki tüm kararları uzak uca bırakmasıdır ve müşteri tamamen aptal olabilir. Son on yıl boyunca Linux ve BSD sistemlerinde kullanılan birkaç şifre şifreleme (depolama) formatı vardır ( hiçbiri istemciden destek gerektirmeyen şifreli (3) ).

Kısmen tarih yüzünden de olsa (yani her zaman böyle olmuştur). Parolalarla bile kullanılabilecek daha iyi bir meydan okuma yanıtı doğrulama protokolü vardır. Örnek için SRP , bu kimlik doğrulaması sırasında paylaşılan sır ile partiler sağlar. Bazı SSH sunucuları için uygulandı, ancak OpenSSH yaması (çok) eski bir sürüm için.

— ilkkachu
kaynak

1

Parola doğrulaması için meydan okuma protokolleriyle ilgili sorun, bazılarının sunucunun parolayı düz metin olarak saklamasını gerektirmesidir. Mücadele yanıtı protokolü, sunucunun karma şifreyi saklamasına izin veriyorsa, büyük olasılıkla çok özel bir karma algoritması gerektirir.

— kasperd

8

Parolalar genellikle "düz metin" olarak gönderilir (yani aslında açık değil, yalnızca temel SSH | TLS | bağlantısının sağladığı koruma ile). Şifreler için denilen bir sistem istemci tarafı karma edilecek ve karma gönderilmek üzere, sunucular gerçek şifreyi türetmek için yolu yoktur ve bunun yerine şifre karma sağlayabilir herkese erişim izni olacağını karma söyledi yapmada, şifre eşdeğer .

— Blacklight,

1

@BlacklightShining Sıfır bilgi parola provaları mevcuttur, ancak SSH'de kullanılmazlar, çünkü bunlar için standart parola veritabanını kullanmanın bir yolu yoktur ve anahtar tabanlı kimlik doğrulama yerine bunları kullanmak için gerçek bir nokta yoktur.

— Random832

Kimlik doğrulamada kullanılan şifreleri nerede görebilirim? /Var/log/auth.log'da değiller, o zaman nerede?

— ア 'ックス

OpenSSH şifreleri günlüğe kaydetmeyecek, başarısız veya başka şekilde girmeyecek. (Diğer SSH sunucularına pek aşina değilim.) Neredeyse tüm meşru kurulumlarda, bunun sağlayabileceği herhangi bir değer, bir kısmı yazım hatası yapan meşru kullanıcılar tarafından sağlanmış olabilir. ya da cleartext ile yanlış ama başka bir şeyin şifresini denedim. Bunu yapmak için iyi bir nedeniniz varsa, OpenSSH'ye yama yapmak kolay olacaktır.

— musicinmybrain 18:16

10

Stephen Harris'in cevabını oluşturmak için, burada, değiştirilmiş bir PAM auth betiğinin ssh üzerinden bir kutuya bağlanırken nelerin yakalanabileceğini gösteren gerçek zamanlı bir görünüm var. PAM kütüphanesi lib-storepw'in değiştirilmiş bir versiyonunu kullanıyorum.

https://livesshattack.net

https://livesshattack.net/about

— Willie S.
kaynak

4

Öncelikle bağlantılar olan cevaplar, bağlantının kullanılamaması durumunda üzerine kaşlarını çattı (bu siteyi kişisel olarak kullanıyor olmanıza rağmen hala geçerli). Bunu, okuyucular için auth betiğinizle nasıl yönettiğinizi açıklamalısınız.

— Centimane

artık çalışmıyor, parola olarak çok büyük bir dize gönderdim, sanırım kırmış olabilir, üzgünüm: - /

— scottydelta 18:16

@scottydelta Buna bakmamış olmama rağmen, PAM modülünün ya da SSH arka planının kendisinin bir kimlik doğrulama girişiminde kabul edebileceği parola boyutunda bir arabellek sınırı olabilir. Site hala istediğim gibi çalışıyor, gerçekte durum böyle ise, sshd veya PAM modülü tarafından kabul edilen tampon sınırına uyuyor olsa da.

— Willie S.

Değiştirilmiş lib-storepw'inizin başkalarının kullanması için kaynağı ilgi çekici mi?

— Tim Fletcher

2

SSH, karşılıklı güven gerektiren bir protokoldür. OpenSSH istemcisinin, ilk kullanım şemasına olan güvenini uygulamak için bilinen bir evrak dosyasını tutmasının nedeni budur.

Bir SSH sunucusunda oturum açmaya çalıştığınızda, yazılımı kimin sağladığına veya hangi verileri günlüğe kaydedeceğinize bakılmaksızın, bazı kimlik doğrulama prosedürlerine katılıyorsunuzdur. Parola doğrulamayı kullanırken, şifrenizi bu sunucuya iletiyorsunuz. Asimetrik şifrelemenin (genel anahtar, sertifikalar) önerilmesinin bir nedeni budur - genel anahtar şifrelemesi, kimlik bilgilerinizi açıklama riskini büyük ölçüde azaltır. (Her ne kadar ssh-agent forwarding veya benzer bir program kullanıyorsanız, bu sizi bir MitM saldırısından korumaz.

— jvoorhis
kaynak

SSH, karşılıklı güven veya en azından simetrik güven gerektirmez. Kesin olmak önemlidir: known_hosts güvenilirlikle ilgilidir, güven değil. Sizin de belirttiğiniz gibi, daha az güvenilen bir ana bilgisayara ortak bir anahtar koymak güvenlidir. Gerçekten de, giriş yapmak için bir şifre kullanmak, şifrenizi tekrar kullanmadığınızı varsayarsak, "güvenli" dedir. (Elbette sunucuya güvenme dereceniz kadar güvenlidir.) Ana bilgisayar tabanlı ssh girişleri bile asimetrik güvene bağlıdır.

— markhahn