Tailscale SSH, Sıkılaştırılmış Sunucularda authorized_keys Kısıtlamalarını Ses­sizce Bypass Ediyor

Ne yaşandı

dev.to'da yazan bir geliştirici, aslen forge.workstyle.tech'te Japonca olarak yayımlanan bir yazıda, SSH sıkılaştırmasındaki sessiz bir hata modunu belgeledi: Bir makinede Tailscale SSH'nin etkinleştirilmesi, authorized_keys kısıtlamalarının herhangi bir hata veya uyarı olmadan uygulanmayı bırakmasına yol açabiliyor. Yazar, bir Mac'in Linux makinesinden yalnızca bitmiş videoları çekebilmesi için özel bir anahtarı kısıtlamıştı; ama aynı kurulum, ana dizinden .bashrc dosyasını da sorunsuzca indirdi.

Çalışması gereken kurulum

Yazıya göre, video üreten Linux makinesinde, özel bir ed25519 anahtarı için authorized_keys'te command="rrsync -ro /path/to/deliver",restrict biçiminde bir kayıt vardı. rrsync sarmalayıcısı rsync aktarımlarını tek bir dizine hapseder, -ro bu aktarımları salt okunur yapar, restrict ise anahtarın yapabileceği diğer her şeyi devre dışı bırakır. Mac tarafında ise ~/.ssh/config, makineyi IdentitiesOnly yes ve özel kimlik dosyasıyla sabitliyordu; böylece sunucuya başka bir anahtar önerilmeyecekti.

Teslimat klasöründen bir video çekmek tasarlandığı gibi çalıştı. Olumsuz test — o klasörün dışından bir dosya çekme — de çalıştı ve sorun tam olarak buydu.

Kısıtlama neden yok sayıldı

Yazarın açıkladığına göre, belirleyici ayrıntı, Linux makinesinde Tailscale SSH'nin, Tailscale yapılandırmasında RunSSH: true ile etkin olmasıydı. Tailscale SSH üzerinden gelen bağlantılar, OpenSSH'nin sshd süreci yerine Tailscale daemon'u olan tailscaled tarafından sonlandırılır. authorized_keys yalnızca sshd'nin danıştığı bir dosya olduğundan, anahtara bağlı command= ve restrict seçeneklerine hiç bakılmadı. Kısıtlamalar zayıflatılmadı ya da yanlış yorumlanmadı — hiç çalıştırılmayan bir kod yolunda duruyorlardı.

Çözüm ve doğrulama yöntemi

Çare, sunucu tarafında tek bir komuttu:

tailscale set --ssh=false

Bu değişiklikten sonra Tailscale üzerinden gelen SSH trafiği yeniden sshd'ye ulaşır ve anahtar başına kısıtlamalar devreye girer. Yazarın doğrulama rutini taklit etmeye değer. Önce izin verilen işlemin hâlâ çalıştığını kontrol edin — teslimat klasörü çekilebiliyor. Sonra engellemek istediğiniz şeylerin gerçekten başarısız olduğunu kontrol edin: hedef klasörün dışındaki bir dosya, örneğin .bashrc, ve bağlantı üzerinden rastgele bir komut çalıştırma denemesi. Yazarın temel savı şu: İzin verilen işlemin başarılı olması, engelleme tarafının gerçekten uygulanıp uygulanmadığı konusunda hiçbir şey kanıtlamaz.

İki ek tuzak daha

Yazımı tamamlayan iki ikincil bulgu daha var. Birincisi, macOS, openrsync tabanlı bir rsync ile geliyor ve rrsync bunu reddetti; Homebrew ile rsync kurmak istemciyi düzeltti. Dolayısıyla istemci tarafındaki bir sürüm uyuşmazlığı, sunucu yapılandırma hatası gibi görünebilir. İkincisi, --ssh bayrağıyla Tailscale'e yeniden giriş yapmak Tailscale SSH'yi yeniden etkinleştirir, tailscaled yolunu geri getirir ve sshd'nin anahtar işlemeyi yine bypass eder. Yani çözüm bir kerelik değil — her yeniden girişten sonra ayarın yeniden kontrol edilmesi gerekiyor.

Neden önemli

authorized_keys, SSH sıkılaştırmasının taşıyıcı bir parçasıdır. Zorunlu komutlar, restrict, no-pty ve benzeri seçenekler, ekiplerin otomasyon, yedekleme ve deployment anahtarlarını ihtiyaç duydukları en düşük yetkiyle sınırlandırma yoludur. Tailscale SSH, kullanıcı başına anahtar yönetimini tailnet tabanlı erişim kontrolüyle değiştirdiği için caziptir; ama bu yazı iki mekanizmanın uyumlu çalışmadığını gösteriyor: Tailscale SSH'nin etkin olduğu bir makinede, authorized_keys'teki anahtar başına ilke fiilen ölü bir yapılandırmadır. Kısıtlı anahtarlarla birlikte Tailscale çalıştıran herkes, bağlantılarını hangi daemon'un sonlandırdığını teyit etmeli, anahtar başına kısıtlamaların önemli olduğu yerlerde Tailscale SSH'yi devre dışı bırakmalı ve yalnızca izin verilen yolu değil, engellemeleri de test etmelidir. Hiç başarısız olduğu gözlemlenmemiş bir erişim kontrolü, hiç çalışmayan bir erişim kontrolden ayırt edilemez.