Son 16 aydır bu sorun için bir çözüm arayışı içindeyim. Ancak her baktığımda, bunu ilgili RFC'lerde belirtilen ve büyük uygulamalar tarafından uygulanan SSH protokolüyle yapmak imkansız görünüyor.
Ancak, hafifçe değiştirilmiş bir SSH istemcisi kullanmaya istekliyseniz ve tam olarak tasarlandıklarında amaçlanmayan protokolleri kullanmak istiyorsanız, o zaman bunu başarmak mümkündür. Bu konuda daha fazlası.
Neden mümkün değil
İstemci ana bilgisayar adını SSH protokolünün bir parçası olarak göndermez.
Ana bilgisayar adını bir DNS aramasının bir parçası olarak gönderebilir, ancak bu önbelleğe alınabilir ve istemciden çözümleyicilerden yetkili sunuculara giden yol proxy'yi geçemez ve hatta belirli DNS aramalarını ilişkilendirmenin sağlam bir yolu olmasa bile belirli SSH istemcileri.
SSH protokolü ile de yapabileceğiniz hiçbir şey yok. İstemciden SSH sürümü başlığını bile görmeden bir sunucu seçmeniz gerekir. Proxy'ye bir şey göndermeden önce müşteriye bir afiş göndermelisiniz. Sunuculardan gelen afişler farklı olabilir ve hangisinin kullanılacağını tahmin etme şansınız yoktur.
Bu afiş şifrelenmemiş olarak gönderilse bile, değiştiremezsiniz. Bu afişin her bir kısmı, bağlantı kurulumu sırasında doğrulanacaktır, bu nedenle hattın biraz altında bir bağlantı hatasına neden olmuş olursunuz.
Bana göre, bu bağlantının işe yaraması için müşteri tarafında bir şeylerin değiştirilmesi gerekiyor.
Geçici çözümlerin çoğu SSH trafiğini farklı bir protokolün içine yerleştiriyor. Biri ayrıca, SSH protokolüne kendisinin de eklendiğini hayal edebilir, bunun içinde müşteri tarafından gönderilen sürüm başlığı ana bilgisayar adını içerir. Afişin bir kısmı şu anda serbest biçimli bir kimlik alanı olarak belirtildiğinden ve istemciler genellikle sürüm afişini kendi göndermeden önce sunucudan beklemelerine rağmen, protokol istemcinin kendi afişini göndermesine izin verir ilk. Ssh istemcisinin bazı son sürümleri (örneğin, Ubuntu 14.04'teki sürüm) sunucu başlığını beklemeden başlığını gönderir.
Sunucunun ana bilgisayar adını bu başlığa dahil etmek için adımlar atmış olan herhangi bir müşteri bilmiyorum. Böyle bir özellik eklemek için OpenSSH posta listesine bir düzeltme eki gönderdim . Ancak, ana bilgisayar adını SSH trafiğini izleyen hiç kimseye açıklamama arzusuna dayanarak reddedildi. Gizli bir ana bilgisayar adı, ad tabanlı bir proxy'nin çalışmasıyla temel olarak uyuşmadığından, yakında SSH protokolü için resmi bir SNI uzantısı görmeyi beklemeyin.
Gerçek bir çözüm
Benim için en iyi olan çözüm aslında IPv6'yı kullanmaktı.
IPv6 ile her sunucuya atanmış ayrı bir IP adresine sahip olabilirim, böylece ağ geçidi paketi hangi sunucuya göndereceğini bulmak için hedef IP adresini kullanabilir. SSH istemcileri, bazen IPv6 adresini almanın tek yolunun Teredo'yu kullanacağı ağlarda çalışıyor olabilir. Teredo'nun güvenilmez olduğu bilinmektedir, ancak yalnızca bağlantının yerel IPv6 ucu bir genel Teredo rölesi kullanıyorsa. Biri proxy'yi yöneteceğiniz ağ geçidine bir Teredo rölesi yerleştirebilir. Miredo, beş dakikadan daha kısa bir sürede röle olarak kurulabilir ve yapılandırılabilir.
Bir geçici çözüm
Bir atlama ana bilgisayarı / bastion ana bilgisayarı kullanabilirsiniz. Bu yaklaşım, tek tek sunucuların SSH bağlantı noktalarını doğrudan halka açık internete maruz bırakmak istemediğiniz durumlar için tasarlanmıştır. SSH için ihtiyaç duyduğunuz harici IP adreslerinin sayısını azaltma konusunda ek bir faydası var, bu yüzden bu senaryoda kullanılabilir. Güvenlik nedeniyle başka bir koruma katmanı eklemeye yönelik bir çözüm olması, ek güvenlik gerekmediğinde kullanmanıza engel olmaz.
ssh -o ProxyCommand='ssh -W %h:%p user1@bastion' user2@target
Gerçek çözüm (IPv6) erişiminizin dışındaysa, çalışmasını sağlamak için kesmek için kirli
Tarif etmek üzere olduğum hack, yalnızca kesinlikle en son çare olarak kullanılmalı. Bu hack'i kullanmayı düşünmeden önce, SSH üzerinden harici olarak erişilebilir olmasını istediğiniz her sunucu için bir IPv6 adresi almanızı şiddetle tavsiye ederim. IPv6'yı SSH sunucularınıza erişmek için birincil yönteminiz olarak kullanın ve yalnızca IPv6'yı dağıtma üzerinde herhangi bir etkisinin olmadığı IPv4 içeren bir ağdan bir SSH istemcisi çalıştırmanız gerektiğinde kullanın.
Buradaki fikir, müşteri ve sunucu arasındaki trafiğin, kusursuz bir şekilde geçerli SSH trafiği olması gerektiğidir. Ancak proxy'nin yalnızca ana bilgisayar adını tanımlamak için paket akışını yeterince anlaması gerekir. SSH, bir ana bilgisayar adı göndermenin bir yolunu tanımlamadığından, bunun yerine, böyle bir olasılık sağlayan diğer protokolleri göz önüne alabilirsiniz.
Hem HTTP hem de HTTPS, sunucunun herhangi bir veri göndermeden önce istemciye bir ana bilgisayar adı göndermesine izin verir. Şimdi soru, SSH trafiği olarak ve HTTP ve HTTPS olarak aynı anda geçerli olan bir bayt akışı oluşturmanın mümkün olup olmadığıdır. HTTP'ler hemen hemen başlangıçsızdır, ancak HTTP mümkündür (HTTP'nin yeterince liberal tanımları için).
SSH-2.0-OpenSSH_6.6.1 / HTTP/1.1
$:
Host: example.com
Bu size SSH veya HTTP gibi görünüyor mu? SSH'dir ve tamamen RFC uyumludur (bazı ikili karakterlerin SF görüntülemesi tarafından biraz karıştırılması dışında).
SSH sürüm dizgisi, yukarıdaki değere sahip olan bir yorum alanı içerir / HTTP/1.1. Newline SSH'den sonra bazı ikili paket verileri vardır. İlk paket, MSG_SSH_IGNOREmüşteri tarafından gönderilen ve sunucu tarafından yok sayılan bir mesajdır. İhmal edilecek yük:
:
Host: example.com
Bir HTTP proxy'si kabul ettiği şekilde yeterince liberalse, aynı bayt dizisi denilen bir HTTP yöntemi SSH-2.0-OpenSSH_6.6.1olarak yorumlanır ve yoksayma iletisinin başındaki ikili veriler bir HTTP başlık adı olarak yorumlanır.
Proxy, ne HTTP yöntemini ne de ilk başlığını anlardı. Ancak Host, arka ucu bulmak için gereken tek şey olan başlığı anlayabilir .
Bunun çalışması için proxy'nin, yalnızca arka ucu bulmak için yeterli HTTP'yi anlaması gerektiği prensibiyle tasarlanması gerekirdi ve arka uç bulunduktan sonra, proxy basitçe ham bayt akışını geçecek ve gerçek sonlandırmayı terk edecek arka uç tarafından yapılacak HTTP bağlantısının
HTTP proxy'si hakkında çok fazla varsayımda bulunmak için biraz uzatma gibi gelebilir. Ancak, SSH'yi desteklemek amacıyla geliştirilen yeni bir yazılım yüklemeye istekliyseniz, HTTP proxy gereksinimleri çok kötü gelmiyor.
Kendi durumumda, bu yöntemi kodda, konfigürasyonda veya başka türlü bir değişiklik yapmadan önceden kurulmuş bir proxy üzerinde çalışmak için buldum. Ve bu sadece HTTP ile yazılmış ve SSH'sız akılda tutulan bir proxy içindi.
Müşteri ve vekil kavramının ispatı . (Proxy'nin benim tarafımdan işletilen bir hizmet olduğunu reddetme. Bu kullanımı destekleyen başka bir proxy onaylandıktan sonra bağlantıyı değiştirmekten çekinmeyin.)
Bu kesimin uyarıları
- Kullanmayın. IPv6 olan gerçek çözümü kullanmak daha iyidir.
- Proxy HTTP trafiğini anlamaya çalışırsa, kesinlikle kesilecektir.
- Değiştirilmiş bir SSH istemcisine güvenmek hoş değildir.