SSH için Son Derece Ayrıntılı Bir Rehber (ama yalnızca benim işime yarayanlar)

• SSH, uzaktan erişimin ötesinde port yönlendirme, jump host, yapılandırma dosyaları ve anahtar yönetimini birlikte ele alan bir araçtır; web sunucusu örneği RDP·SQL gibi diğer servislere de aynen uygulanabilir
• Yerel·uzak·dinamik port yönlendirme sırasıyla -L, -R, -D ile yapılandırılır; temel fark, portun hangi tarafta açıldığı ve trafiğin nereye aktığıdır
• Doğrudan erişimin engellendiği ağlarda -J jump host ve ProxyJump ile birden fazla SSH geçiş noktası birbirine bağlanarak hedefe ulaşılabilir
• ssh-agent ve -A agent forwarding, uzak host üzerinde de yerel anahtarların kullanılmasını sağlayarak kolaylık sunar; ancak önce agent’ın kötüye kullanılmasından doğan güvenlik riskleri kontrol edilmelidir
• ~/.ssh/config, ssh-copy-id, ssh-keygen, SSH konsolu ~?·~C birlikte kullanıldığında tekrarlayan seçenekleri yazma ihtiyacı azalır; oturum sırasında yönlendirme eklemek, açık anahtar dağıtmak ve anahtar oluşturup denetlemek kolaylaşır

---

SSH port yönlendirmesini anlamak için ön kabuller

• SSH port yönlendirmede akışı yalnızca diyagramlarla kavramak zor olduğundan, gerçek komutları ve ağ senaryolarını birlikte görmek anlamayı kolaylaştırır
• Örnekler web sunucusuna erişim üzerinden verilmiştir, ancak aynı yöntem RDP, SQL vb. neredeyse tüm servislere uygulanabilir
• Tekrar tekrar kullanılan seçeneklerin anlamı şöyledir
  • -N: Uzak sunucuda komut çalıştırmaz ve shell de açmaz
  • -f: SSH’yi arka plana gönderir
  • root@host: Tüneli oluşturacak kullanıcı ve host ile oturum açar

Yerel port yönlendirme -L

• Yerel port yönlendirme, yerel makinenin portunu uzak sunucunun portuna aktarır
• Örnek durum
  • internal-web.int, yalnızca loopback arayüzünden erişilebilen bir web sayfası barındırır
  • campfire.int üzerinden internal-web.int’e SSH erişimi mümkündür
  • campfire.int’in yerel portu üzerinden internal-web.int’in web sunucusuna erişilmek istenir
• Kullanılacak komut
  • ssh -N -f -L 1337:127.0.0.1:80 [e-mail]
• Seçeneklerin açıklaması
  • -L: Yerel yönlendirmeyi belirtir
  • 1337:127.0.0.1:80: Yerel port 1337’yi uzaktaki 127.0.0.1:80 adresine bağlar
• Tünel oluşturulduktan sonra campfire.int üzerinde yerel port 1337’ye istek göndererek internal-web.int’in port 80’iyle etkileşime geçilebilir
• Hatırlanması gereken nokta, -L için yerel portun adresin sol tarafında yer aldığıdır

Uzak port yönlendirme -R

• Uzak port yönlendirme, yerelden erişilebilen bir portu uzak sunucunun portu olarak dışa açar
• Örnek durum
  • internal-web.int, yalnızca loopback üzerinden erişilebilen bir web sayfası barındırır
  • campfire.int, güvenlik duvarı nedeniyle internal-web.int’e doğrudan erişemez
  • vuln-server.int, hem campfire.int hem de internal-web.int tarafından erişilebilir durumdadır
• Kullanılacak komut
  • ssh -N -f -R 3000:127.0.0.1:80 [e-mail]
• Seçeneklerin açıklaması
  • -R: Uzak yönlendirmeyi belirtir
  • 3000:127.0.0.1:80: vuln-server.int üzerindeki port 3000’i yereldeki 127.0.0.1:80 adresine bağlar
• Daha sonra vuln-server.int:3000 adresine curl isteği gönderildiğinde, internal-web.int üzerinde port 80’de çalışan dahili web sayfasına erişilebilir
• Hatırlanması gereken nokta, -R için yerel portun adresin sağ tarafında yer aldığıdır

Dinamik port yönlendirme -D ve SOCKS proxy

• Dinamik port yönlendirme, -D seçeneğiyle bir SOCKS proxy oluşturur ve trafiği SSH geçiş noktası üzerinden gönderir
• Örnek durum
  • internal-web.int, yalnızca dahili ağdan erişilebilen bir web uygulaması barındırır
  • vuln-server.int, aynı dahili ağdadır ve internal-web.int’e erişebilir
  • campfire.int üzerinden trafiğin vuln-server.int aracılığıyla proxy’lenmesi istenir
• /etc/proxychains.conf ayarı, SSH komutundaki portla eşleşmelidir
  • socks5: proxychains’in SOCKS5 kullanmasını sağlar
  • 127.0.0.1: localhost’u kullanır
  • 8080: SSH -D için belirtilen portla aynı olmalıdır
• Kullanılacak komut
  • ssh -N -f -D 8080 [e-mail]
• Yönlendirme oluşturulduktan sonra socks5 127.0.0.1 8080 ayarlanırsa proxychains curl 192.168.1.185 ile dahili web sayfasına erişilebilir
• SOCKS üzerinden DNS, ortama bağlı olarak düzgün çalışmayabileceği için örnekte host adı yerine IP adresi kullanılmıştır
• Firefox’ta da manuel proxy ayarıyla SOCKS proxy kullanılabilir
  • Yol: Settings → Privacy & Security → Network Settings
  • Manual proxy configuration seçilir
  • “Proxy DNS when using SOCKS V5” işaretlenir
  • SOCKS host 127.0.0.1, port 8080 olarak ayarlanır

Jump host -J

• Jump host, mevcut host’tan doğrudan erişilemeyen bir hedefe birden fazla SSH geçiş noktası üzerinden bağlanmayı sağlar
• Örnek zincir campfire.int → vuln-server.int → internal-web.int → dns.int şeklindedir
• Kullanılacak komut
  • ssh -J [e-mail],[e-mail] [e-mail]
• Birden fazla jump hedefi virgül ile ayrılır

Agent forwarding -A

• ssh-agent, yerel makinede ssh-add <private_key_file> ile özel anahtar veya ID eklenmesini sağlar
• Eklenen anahtarlar ssh-add -l ile kontrol edilebilir
• ssh-agent’a anahtar eklendiğinde, parolayı tekrar girmeden ilgili anahtarla SSH bağlantısı kurulabilir; bu hem kişiler hem de servis hesapları için kullanışlıdır
• -A agent forwarding, bağlanılan uzak makinede de yerel agent’taki anahtarların kullanılmasını sağlar
• Kullanmadan önce güvenlik risklerini kontrol etmek için Zero Effort Private Key Compromise: Abusing SSH-Agent for Lateral Movement incelenmelidir
• Örnek komut
  • ssh -A -J [e-mail] [e-mail]
• Bu komut, vuln-server.int üzerinden internal-web.int’e bağlanırken yerel campfire.int üzerindeki SSH agent’ta bulunan anahtarların kullanılmasını sağlar
• Ardından internal-web.int üzerinde ssh [e-mail] çalıştırıldığında özel anahtar belirtmeden veya kimlik bilgisi girmeden bağlantı kurulabilir

TTY komut atama -t

• -t seçeneği, uzak sunucuda etkileşim gerektiren komutları hızlıca çalıştırmak için kullanışlıdır
• Örnekler, Vim veya top gibi TTY gerektiren komutlardır
• Kullanılacak komut
  • ssh [e-mail] -t top
• Çalıştırıldığında uzak sunucuda top komutunu içeren bir TTY alınır

Harici host’ların da yerel yönlendirme portuna bağlanmasını sağlayan -g

• -g seçeneği, uzak host’ların yerel olarak yönlendirilmiş porta bağlanabilmesini sağlar
• Yerel port yönlendirme -L ile benzerdir; farkı, harici makinelerin de söz konusu “yerel” portu kullanabilmesidir
• Örnek durum
  • vuln-server.int üzerinde shell erişimi vardır
  • vuln-server.int’in port 2222’sine gelen bağlantılar internal-web.int’in port 22’sine proxy’lenmek istenir
• Kullanılacak komut
  • ssh -N -f -g -L 2222:localhost:22 [e-mail]
• Seçeneklerin açıklaması
  • -g: Uzak host’ların yerel yönlendirme portuna bağlanmasına izin verir
  • -L: Yerel yönlendirmeyi belirtir
• vuln-server.int üzerindeki port 2222’ye SSH ile bağlanılmış olsa bile gerçek shell internal-web.int üzerinde olur

SSH konsolu ~? ve oturum sırasında yönlendirme

• SSH konsolu, uzak sistemle doğrudan etkileşime girmeden SSH’nin kendisini kontrol etmeyi sağlayan gizli bir özelliktir
• Shell bozulduğunda veya SSH oturumunun kendisini kontrol etmek gerektiğinde kullanışlıdır
• Yardım konsolu ~? ile açılabilir
• Kullanışlı seçenekler
  • ~.: Mevcut SSH oturumunu sonlandırır
  • ~C: SSH konsolunu açarak yönlendirme seçenekleri eklenmesini sağlar
• Zaten normal bir ssh komutuyla vuln-server.int’e bağlıyken de ~C tuşlanıp -D 8080 girilirse, bu oturum dinamik yönlendirme oturumu gibi kullanılabilir
• campfire.int üzerinde /etc/proxychains.conf port 8080’i kullanacak şekilde ayarlıysa, baştan ssh -D ile başlatılmış gibi proxychains’ten yararlanılabilir

SSH yapılandırma dosyası ~/.ssh/config

• SSH yapılandırma dosyası ~/.ssh/config konumundadır ve tekrar tekrar girilen SSH seçeneklerini kaydederek zaman kazandırır
• SSH bağlantısı sırasında bu dosya ayrıştırılır; bağlantı hedefine uygun bir host ayarı varsa ilgili seçenekler kullanılır
• Komut satırı argümanları yapılandırma dosyasından önceliklidir
  • Örneğin yapılandırma dosyasında internal-web.int kullanıcısı root olarak belirtilmiş olsa bile ssh [e-mail] çalıştırılırsa graham olarak oturum açılmaya çalışılır
• Temel yapılandırma örneği

# You can put comments with a `#` at the beginning of the line only.
host internal-web.int
    User root
    IdentityFile /home/smores/ssh_agent/internal-web-no-pw
    Port 2222

• ssh internal-web.int çalıştırıldığında işlem akışı
  • Komut satırındaki internal-web.int ile ~/.ssh/config içindeki host internal-web.int eşleştirilir
  • Eşleşirse komut satırında belirtilmeyen seçenekler yapılandırma dosyasından alınır
  • Eşleşmezse yalnızca komut satırında tanımlanan seçenekler kullanılır

Sık kullanılan SSH config anahtar sözcükleri

• IdentityFile /path/to/private_key
  • Host için kullanılacak özel anahtarı belirtir
  • ssh -i ile aynı görevi görür
• ForwardAgent
  • ssh -A ile aynı görevi görür
  • Agent forwarding kullanmadan önce Zero Effort Private Key Compromise: Abusing SSH-Agent for Lateral Movement kontrol edilmelidir
• ProxyJump [e-mail]
  • Trafiğin proxy’leneceği sunucuyu belirtir
  • -J seçeneğiyle aynı görevi görür
  • Örnekte önce vuln-server.int kimlik doğrulaması istenerek trafiğin bu host üzerinden geçtiği gösterilir
• Match
  • Koşula göre SSH config anahtar sözcüklerini uygular
  • Örnekte export | grep PROXYME=TRUE komutunun çıkış kodu 0 ise Match bloğu altındaki ProxyJump kullanılır
  • PROXYME ortam değişkeni yoksa yalnızca normal host internal-web.int bloğu kullanılır
  • export PROXYME=TRUE ayarlandıktan sonra aynı ssh internal-web.int çalıştırılırsa önce vuln-server.int kimlik doğrulamasından geçilir, ardından internal-web.int shell’i alınır
• scp ve bazı SSH tabanlı yardımcı araçlar da genellikle SSH config kullanabilir
  • Otomatik kullanmadığı ortamlarda -F ~/.ssh/config ile açıkça belirtilebilir

Açık anahtar kopyalama ssh-copy-id

• ssh-copy-id, açık anahtarı sunucuya hızlıca yükleyen küçük bir yardımcı araçtır
• Kullanılacak komut
  • ssh-copy-id -i internal-web [e-mail]
• Seçeneklerin açıklaması
  • -i internal-web: Sunucu kimlik doğrulamasında kullanılacak özel anahtar adını belirtir
  • [e-mail]: Açık anahtarın yükleneceği sunucuyu belirtir

Anahtar oluşturma ve denetleme ssh-keygen

• ssh-keygen, özel anahtar·açık anahtar çifti oluşturan bir yardımcı araçtır
• -b seçeneğiyle daha büyük anahtar boyutu belirtmek genellikle önerilir
• Örnek ortamda varsayılan anahtar boyutu 3072 idi
• Varsayılan algoritma RSA’dır, ancak -t bayrağıyla farklı bir algoritma belirtilebilir
  • Örnek: ssh-keygen -t ecdsa -b 521
• Anahtarın parmak izi ve bayt boyutu şu komutla kontrol edilebilir
  • ssh-keygen -lf <file-name>

[GN⁺]

Hacker News yorumları

• Burada şaşırtıcı derecede basit bir yönerge eksik: sshd_config içinde AuthorizedKeysCommand /usr/bin/php /etc/ssh/auth.php %u gibi ayarlayıp, betikte GitHub’daki https://github.com/{$user}.keys adresini almak yeterli
  Elbette production kalitesinde kod değil, ama ana fikri gösteriyor
  GitHub organizasyonu/grubu üyeliğini kontrol ettikten sonra kullanıcı mevcutsa ve nss-ato gibi bir şeyle eşlenmişse sunucuya girişe izin verebilirsiniz
  İnsanları onboard/offboard ederken yalnızca GitHub grubuna ekleyip/çıkarmakla makine erişimini vermek veya geri almak mümkün olduğundan zahmeti azaltır

  • Amazon Linux da benzer bir şey yapıyor; muhtemelen production kalitesinde olduğu için çok daha karmaşık
    Amazon Linux 2 ve öncesinde, authorized_keys dosyasındaki tek tek anahtar biçimlerini kontrol etmek için openssl komut satırını çağırıyor; RSA’ya hardcode edildiği için OpenSSH sürümü ed25519 desteklese bile Amazon Linux 2 host’larında ed25519 ile kimlik doğrulaması yapılamıyordu
    Teoride hoş bir özelliği¹ mümkün kıldığı için güzel, ama pratikte o özelliği kullanmayanların bile temel işlevini bozarak Amazon Linux’a daha az güven duymama neden oluyor
    Bu sorunla ilk karşılaştığımda, cloud-first bir DevOps meslektaşımın sahip olduğu bir makineye SSH ile bağlanmaya çalışıyordum; doğrudan müdahale edemediğim için teşhis etmesi zordu
    O AWS’yi iyi biliyor ama Linux’u daha az biliyor, bu yüzden nereye bakacağını bilmiyordu; bulut platformu sahibinin yaptığı dağıtım olduğu için “daha uyumlu” olacağını düşünerek Amazon Linux’u seçmişti, ama burada “daha uyumlu” aslında “daha çok aptalca surprise” anlamına geliyordu
    ¹ https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-...
  • Böyle şeyleri görünce ağ tarafında olmak üzücü geliyor
    “Ağ düzgün çalışmıyor” iş kapsamım olduğu için böyle harika özellikleri kaçırıyorum
  • Bu tür kullanım için bunun yerine SSH sertifikaları kullanmak daha iyi olur

• OpenSSH yapılandırma ayrıştırıcısının yinelenen yönergeleri yok saydığını ve aynı yönergelerden yalnızca ilk olanın etkili olduğunu pek çok kişi bilmiyor olabilir
  Genelde yapılandırma ayrıştırıcılarında veya kural motorlarında daha sonra gelen yönerge öncekinin üzerine yazar; bu yüzden oldukça sezgiye aykırı
  Önemsiz görünebilir, ama /etc/ssh/sshd_config gibi varsayılanları değiştirirken insanlar ve yazılımlar değişiklikleri dosyanın ya da yönerge bloğunun sonuna ekleme eğilimindedir ve bunun uygulanmasını bekler
  Güvenlik şirketleri ve kuruluşlar, çeşitli SSH bastion ürünleri de bunda hata yapıyor; CIS Benchmarks önerileri ve üçüncü taraf CIS denetim araçlarının çoğu da önceliği dikkate almıyor ya da yanlış ele alıyor
  OpenSSH yapılandırma yönergelerinin beklendiği gibi tanımlanıp tanımlanmadığını kontrol etmek için yapılandırma dosyasını doğrudan taramak yerine sshd -T veya ssh -G ile türetilmiş iç yapılandırmayı dump etmelisiniz

  • sudoers dosyası da aynı şekilde çalışır
    Kullanıcı kimlik doğrulama/yetkilendirme yazılımında bu yaklaşımın tercih edilir olduğunu düşünüyorum
    Çünkü whatever.conf.d dizinine yeni bir dosya eklenerek override edilemeyen ayarlar oluşturmayı kolaylaştırır
    Ana yapılandırma dosyasında whatever.conf.d/* yüklenmeden önce ilgili ayarı tanımlayıp o dosyaya özel koruma uygulamak yeterlidir
    Birinin kontrolü aşmaya çalıştığı bir durum olmasa bile, tüm bağlamı bilmeyen yeni biri yeni bir dosya eklediğinde ya da bir paket kendi servisi için garip varsayılanlar kurduğunda temel ayarın önceliğini koruması açısından yapılandırma yönetimi için avantajlıdır
    Başka bağlamlarda ters davranışı daha sık görmemizin nedeni, istenenin “temel ayar” değil, kullanıcı/geliştirici/yönetici açıkça ayarlamadığında kullanılan katı anlamdaki varsayılan değer olmasıdır
  • Bazı yönergelerin yinelenebilir kabul edildiğini düşünüyorum. Örneğin AllowUsers böyle
    Ancak daha dün NixOS aniden birleştirme sırasını değiştirince benim dosyamdaki AllowUsers başka bir dosyadaki Match bloğunun altına inip kilitlenmişti

• Yazıdaki en önemli ve özlü cümle, -L için yerel yönlendirmede local’in adresin solunda, -R için uzak yönlendirmede yerel portun adresin sağında olduğunu hatırlatan açıklama
  En başından beri -L ile -R kafamı karıştırıyordu; hangi port örneğinin yerel olduğu L/R’ye göre değişmesi epey can sıkıcı
  -L ve -R’nin niyet yönünü, yani başlatan ve yanıtlayanın nerede olduğunu değiştirdiğini anlıyorum; ama port:address:port her zaman local:binding:remote anlamına gelse ve -L/-R hangi tarafın dinleyen, hangi tarafın gönderen olduğunu belirlese de fena olmazdı

  • -L’nin hemen ardından gelen numaradaki yerel portta dinlediğini, -R’nin ise hemen ardından gelen numaradaki uzak portta dinlediğini hatırlamak en kolayı
    Geri kalan host:port, nereye bağlanılacağını söyleyen sıradan biçimden ibaret
    SSH tüneli üzerinden port yönlendirme yaptığınız için, host’un dinleyen portun bulunduğu tarafın tünelin karşı ucundan erişildiği de doğal olarak buradan çıkar

• SSH’de daha az bilinen ama kullanışlı bir özellik olarak bağlantı çoğullama vardır
  Yeni bir TCP bağlantısı kurup kimlik doğrulama sürecinden yeniden geçmek yerine mevcut bağlantıyı yeniden kullanacak şekilde ayarlanabilir
  Protokolün kendisinde kanal kavramı vardır; her veri çerçevesine farklı akışları ayırt eden metadata eklenir ve bu özellik de bunu kullanır
  Sonraki oturumlarda tam kimlik doğrulamayı tekrar yapmamak büyük bir avantajdır
  Uzak tarafta tmux vb. yoksa ve birden fazla terminal penceresiyle birden fazla panel kullanıyorsanız özellikle iyidir; kimlik doğrulamada parola ifadesi ya da HSM’e dokunma gibi birkaç saniye süren adımlar varsa etkisi daha da hissedilir
  “Bağlantıyı sürdürme” ayarı da vardır; böylece birkaç sunucu arasında gidip gelirken her seferinde kimlik doğrulamak gerekmez
  Genel olarak bulunması iyi olan ama hayat değiştirecek düzeyde olmayan bir özellik olarak görüyorum
  Bazı sunucularda bu özellik kapalıdır; varlığı açıkken değil, yokluğu kapalıyken daha çok hissedilir
  Devamı: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

  • İstemci ile sunucu arasındaki gecikme yüksekse fark çok büyüktür
    SSH, gidiş-dönüş sayısını azaltacak şekilde optimize edilmiş TLS’in aksine oldukça geveze bir protokoldür; bu çoğullama seçeneği neredeyse tek istisnadır
  • ProxyJump bastion host üzerinden geçerken Ansible kullanımını çok daha rahat hale getirebilir

• ~/.ssh/config içinde çok sayıda host varsa wildcard destekleyen Include yönergesiyle dosyanın fazla dağınık hale gelmesini önleyebilirsiniz
  Örneğin ~/.ssh/config içine Include config.d/*.conf koyup, ~/.ssh/config.d/work.conf veya client1.conf içinde host, hostname, user ayarlarını ayrı ayrı tutabilirsiniz

  • Host yönergesi de wildcard destekler
    Örneğin host *_work ekleyip host1_work gibi tüm iş host’ları için ortak ayarları koyabilirsiniz
  • Ek bir ipucu olarak Include’u Host/Match yönergelerinin içine koyabilirsiniz
    Örneğin ~/.ssh/config içine Host proj1.*.corp ve Include ~/.ssh/proj1.conf koyarsanız, proje bazlı eşleşmeleri üst tarafa yakın tutabilir ve gözden geçirirken çok sayıda ayrı dosyada arama yapma ihtiyacını azaltabilirsiniz

• Forwarding yaparken neredeyse hiç -f kullanmam
  Hangi forwarding’in hâlâ açık ve çalışır durumda olduğunu anlamayı zorlaştırıp kendi ayağına sıkmak haline gelebilir
  -t hoş bir numara ve bilmediğim bir özellikti
  ~ escape komutları listesinde gözden kaçması kolay önemli bir nokta, iç içe oturumlarda da escape’i iç içe kullanabilmenizdir
  Herhangi bir nedenle -J kullanmadığınızda işe yarar
  Liste kullanışlı şeylerle iyi örtüşüyor; ayrıca öğrendiğim birkaç şey daha oldu

  • -t harika. Ben ssh -t my-dev-vps 'tmux new-session -A -s main' şeklinde kullanıyorum; her çalıştırdığımda tmux oturumundaki önceki konumuma doğrudan dönüyorum
  • Hedef sunucuda birden fazla shell açıkken de aynı sorun hâlâ var
    Süreç listesini elle kurcalamak dışında, SSH’in forwarding durumunu makul bir şekilde dışa vermesi iyi olurdu

• AF_UNIX desteği ekleyen mevcut bir pull request var; bu girerse her türden ilginç forwarding mümkün hale gelecek
  Çünkü SSH bağlantısını rastgele bir yerel süreç üzerinden proxy’lemek kolaylaşacak ve bu süreç veriyi uzak uca iletme işini istediği gibi yönetebilecek
  https://github.com/openssh/openssh-portable/pull/431

  • Benim ilgilendiğim şey AF_UNIX kullanan -D, ama her şeyin AF_UNIX üzerinde çalışabilir hale gelmesi güzel
    Yaklaşık 1 yıl öncesinden beri curl, ALL_PROXY sözdizimi socks5://localhost/path veya socks5h üzerinden AF_UNIX SOCKS kullanabiliyor gibi görünüyor
    Tor AF_UNIX SOCKS proxy kullandığı için eklenmiş gibi duruyor
    Ağ erişimini standart Unix izinleriyle ayarlayabilmek güzel olurdu; kişisel olarak TCP/IP’yi çekirdekten tamamen dışarı atabilmek daha da iyi olurdu

• SSH konsolunu ilk gördüğümde şok olmuştum
  Bir iş arkadaşım ~# göstermişti; SEGA Genesis oyunundan çıkacak türden gizli bir hile menüsü bulmuşum gibi hissetmiştim

• Neden tilde? Çünkü rlogin, rsh bunu kullanıyordu
  Peki rlogin, rsh neden tilde kullanıyordu? Çünkü cu kullanıyordu
  Neden cu? Bir modeminiz veya seri hattınız varsa cu ile haberleşirdiniz ve Hayes kodları göndermeniz gerekirdi; Hayes kodunun kaçış dizisini kullanırsanız modeme çıkmış olacağınız için cudan çıkmak üzere ayrı bir sinyale ihtiyaç vardı
  Neden ^[ değil? Çünkü o telnet içindir
  Bu yüzden telnet ile bir host’a bağlanıp ardından cu ile modeme bağlandıysanız, telnet’ten çıkmadan cuya dönmek için ayrı bir kaçış sözdizimine ihtiyaç vardı
  Sonuçta kaçış sözdizimlerinin sonsuza dek üst üste yığıldığı bir yapı
  Ve aslında tilde değil, tilde’dir

  • Sıralamanın CR, tilde, . olduğunu sanıyordum; bunca zamandır yanlış mı kullanıyordum?

• ssh-copy-id bölümü, komutun public key’i yüklediğini anlatırken birden private key’i yüklediğini söylemeye dönüyor; yazım hatası gibi görünüyor
  Ayrıca bu komut yalnızca anahtarı yüklemekle kalmaz, ~/.ssh/authorized_keys dosyasına ekler; bu yüzden çok daha kullanışlıdır
  Son olarak ssh-keygen bölümünde, bugünlerde okuduğum kaynaklara göre ecdsa yerine ed25519 tercih ediliyor