İlk Gerçek Reboot ve RDP Çıkmazı

İlk gerçek reboot için box’ın fişini çektim — tam bir shutdown, ardından cold boot — sonra bir daha tek tuşa dokunmadım: PIN girilmedi, konsoldan giriş yapılmadı, klavyenin başında kimse yoktu. Asıl önemli test buydu: kurulum, kimse yardıma koşmadan ayakta kalabiliyor mu.

BIOS ayarlandı, diskler temizlendi, SSH sertleştirildi, Tailscale mesh’e alındı, GPU power-limit görevi boot’a bağlandı: bunların hepsi, klavyenin başında kimse yokken hiç cold-boot edilmemiş bir makinede yapılmış ayarlardı. Bu box, odanın öbür ucundaki bir MacBook’tan ya da başka bir ülkeden yönettiğim headless bir sunucu olacaksa, bütün bu kurulumun tutup tutmadığını bana gösterecek an işte bu andı.

Sonra Mac’te bir terminal açıp kurcalamaya başladım.

Ayakta Kalanlar

GPU 240W ile geri geldi. nvidia-smi -pl 240 komutu RTX 3060’ı 170W’lık varsayılanından kendi tavanına çıkarıyor, ama Windows’ta bu ayar reboot’ta buharlaşıyor. Kalıcı olmadığı için, onu yeniden uygulayan ve SYSTEM olarak çalışan bir ONSTART scheduled task bağlamıştım. Reboot’un ardından, ben daha hiçbir şey yapmadan:

$ nvidia-smi --query-gpu=power.limit --format=csv,noheader
240.00 W

Task tetiklendi, limit yeniden uygulandı. Kalıcılık doğrulandı — ama kalıcı olan, reboot’u tek başına atlatan bir şey değildi; onu yeniden uygulayan scheduled task’tı. Hardware-Accelerated GPU Scheduling de sağlamdı: HwSchMode=2, hâlâ açık.

Temiz PATH de yüklendi. Önceki temizliğin bir kısmı, şişmiş bir sistem PATH’ini kırpmaktı: dokuz ölü girdi (eski JDK’lar, IntelliJ, 2021’den kalma bir Flutter kurulumu, birkaç başıboş ;;) ve beş case-duplicate System girdisi çıkınca, geriye gerçek yirmi girdi kaldı. Yeni bir login, PATH’i registry’den baştan kuruyor; yani özensiz environment düzenlemeleri kendini tam da bir reboot’ta gösterir.

En çok önemsediğim kanıt, kilit ekranından kontrol edebilmekti: makine reboot oldu, kilit ekranında durdu, kimse giriş yapmadı; yine de düz bir ssh box whoami cevap veriyordu. query session bunu doğruladı:

$ ssh box "query session"
 SESSIONNAME  STATE
 console      Connected
 ...

Connected, Active değil: makine hiçbir kullanıcı oturumu çalışmadan PIN ekranında bekliyor, ama elimde hâlâ tam bir shell var — key-only, bu build’in başındaki SSH kurulumunun aynısı. OpenSSH’ın kullanıcı başına bir şey olarak değil de Windows servisi olarak çalışmasının sebebi bu: servis, daha kimse giriş yapmadan başlıyor; böylece kilit ekranında bile PIN’siz, klavyesiz, monitörsüz SSH’a cevap veriyor.

Üçte üç.

Bozulan Şey

Mac’ten tailscale status: box Not Connected görünüyordu. Geri kalan her şey login gerektirmeden geri gelmişti ama Windows’ta Tailscale varsayılan olarak sistem değil, giriş yapmış kullanıcı olarak çalışıyor — ancak biri giriş yaptıktan sonra bağlanıyor. Login yoksa tünel de yok.

Evdeyken önemi yoktu; LAN SSH alias’ım box’a ev ağından zaten doğrudan ulaşıyordu. Ama Tailscale’in bütün amacı ona her yerden ulaşabilmekti. “Her yer” dediğin an ise tam olarak evde giriş yapıp box’ı uyandıracak kimsenin olmadığı andı.

Çözüm, sshd’deki dersin aynısı:

tailscale up --unattended

--unattended, ForceDaemon=true ayarlıyor; böylece Tailscale, boot’ta ayağa kalkan ve hem logout’ta hem de login’siz reboot’larda ayakta kalan bir daemon olarak çalışıyor — bir sonraki reboot’ta bunu doğruladım.

“Always-on” tek bir anahtar değil, servis başına takip edilen bir özellikti: sshd bir servis olarak zaten boot seviyesindeydi, Tailscale ise bir uygulama olarak login seviyesinde. İkisi de, biri önem kazanana dek birbirinin tıpatıp aynısı görünüyordu.

Sonra RDP ve Kimlik Bilgisi Çıkmazı

SSH bana CLI’ı ve script’leri veriyor. Ama bazı işler tam bir desktop istiyor; o yüzden sırada RDP vardı.

RDP’yi açmak bir checkbox meselesi. Güvenli açmaksa asıl iş. Windows, varsayılan olarak tüm LAN’ı içeri alan “Remote Desktop” adında bir firewall grubunu etkinleştiriyor. Onu kapattım: RDP artık yalnızca tailnet üzerinden yanıt veriyor, NLA zorunlu.

Sonra giriş yapmayı denedim ve doğruca bir çıkmaza düştüm.

Birinci deneme: email@… ile, yani Microsoft hesabıyla bağlanmak. “The credentials did not work.” Tamam, belki format yanlıştır.

İkinci deneme: net user, hesabın şifresiz olduğunu gösteriyor — yalnızca PIN, Windows Hello. Çalışan teorim şuydu: Windows varsayılan olarak boş şifreyle network logon’u engelliyor; PIN de şifre sayılmadığından, network logon’un doğrulayacak hiçbir şeyi yoktu.

Üçüncü deneme: net user <account> * ile düpedüz bir şifre koymak:

System error 8646 has occurred.
The system is not authoritative for the specified account...

Hata 8646, çünkü bu bir Microsoft hesabı — varsaydığım boş-şifre engeli değil. Şifre yerel SAM veritabanında değil, Microsoft’un sunucularında tutuluyor; net user‘ın da ona dokunmaya yetkisi yok.

Çözüm, o kimlikle boğuşmayı bırakıp yenisini oluşturmaktı: gerçek bir şifresi olan, Remote Desktop Users grubuna eklenmiş, günlük kimlik olarak asla kullanmadığım, kendine ait bir yerel hesap. RDP kendi özel kimlik bilgisiyle gidiyor; birincil Microsoft kimliğinden ayrı tutuluyor.

Guardrail, İkinci Kez

Hesabı basıp düz metin bir şifre yazma sırası geldiğinde, asistanın kendi güvenlik katmanı reddetti. Ne hesabı açtı, ne şifreyi yazdı. İkisini de elle çalıştırdım — SSH tarafında, bir hook credential path’lerini koruduğu için ~/.ssh/config‘i yazmayı reddettiğinde çarptığım aynı duvar.

İkinci kez, aynı ilke: tooling benim adıma kimlik bilgisi basmıyor ya da saklamıyor — her seferinde de haklı çıkıyor. Makinelerime bu kadar erişimi olan bir agent, sessizce bir login yaratmaması ya da bir dosyaya şifre bırakmaması gereken agent’ın ta kendisi. O adımı bilerek elimle atıyorum.

Karşılığı şu: Mac’ten ve Microsoft’un Windows App’iyle iPhone’dan, tailnet üzerinden, her yerden ulaşılan tam bir Windows desktop.

Sırada: box’ın bütün filesystem’ini Finder’a getirmek ve teknik olarak her şeyi yapan aracı değil, daha hafif olanı neden seçtiğim.