← man/network
●slogin — man slogin — 80×24
ugur@toprak:~/man/network$man slogin
Bölüm 1 Ağ

slogin

OpenSSH uzak oturum açma istemcisi

Kullanım

     ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec]
 	 [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
 	 [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
 	 [-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port]
 	 [-w local_tun[:remote_tun]] destination [command [argument ...]]
     ssh [-Q query_option]

Açıklama

ssh (SSH istemcisi), uzak bir makinede oturum açmak ve uzak bir makinede komutları yürütmek için kullanılan bir programdır. Güvensiz bir ağ üzerinden iki güvenilmeyen ana bilgisayar (host) arasında güvenli şifrelenmiş iletişim sağlamak üzere tasarlanmıştır. X11 bağlantıları, isteğe bağlı TCP bağlantı noktaları ve UNIX-domain soketleri de güvenli kanal üzerinden yönlendirilebilir (forward).

ssh, belirtilen hedefe bağlanır ve oturum açar; hedef, [user@]hostname şeklinde veya ssh://[user@]hostname[:port] biçiminde bir URI olarak belirtilebilir. Kullanıcı, birkaç yöntemden birini kullanarak (aşağıya bakın) uzak makineye kimliğini kanıtlamalıdır.

Bir komut belirtilirse, bir oturum açma kabuğu (login shell) yerine uzak ana bilgisayarda bu komut yürütülür. Tam bir komut satırı komut olarak belirtilebilir veya ek argümanlara sahip olabilir. Sağlanırsa argümanlar, sunucuya yürütülmek üzere gönderilmeden önce boşluklarla ayrılarak komutun sonuna eklenir.

Seçenekler aşağıdaki gibidir:

  • -4: ssh'ı yalnızca IPv4 adreslerini kullanmaya zorlar.

  • -6: ssh'ı yalnızca IPv6 adreslerini kullanmaya zorlar.

  • -A: ssh-agent(1) gibi bir kimlik doğrulama aracısından (agent) gelen bağlantıların yönlendirilmesini etkinleştirir. Bu durum, bir yapılandırma dosyasında her ana bilgisayar bazında da belirtilebilir.

Aracı yönlendirmesi (agent forwarding) dikkatli bir şekilde etkinleştirilmelidir. Uzak ana bilgisayarda dosya izinlerini (aracının UNIX-domain soketi için) aşma yeteneğine sahip kullanıcılar, yönlendirilen bağlantı aracılığıyla yerel aracıya erişebilirler. Bir saldırgan aracıdan anahtar verilerini elde edemez, ancak aracıya yüklenen kimlikleri kullanarak kimlik doğrulaması yapmalarını sağlayan işlemleri anahtarlar üzerinde gerçekleştirebilir. Daha güvenli bir alternatif, bir sıçrama ana bilgisayarı (jump host) kullanmak olabilir (bkz. -J).

  • -a: Kimlik doğrulama aracısı bağlantısının yönlendirilmesini devre dışı bırakır.

-B bind_interface Hedef ana bilgisayara bağlanmaya çalışmadan önce bind_interface adresine bağlanır (bind). Bu seçenek, yalnızca birden fazla adresi olan sistemlerde yararlıdır.

-b bind_address Bağlantının kaynak adresi olarak yerel makinedeki bind_address adresini kullanır. Yalnızca birden fazla adresi olan sistemlerde yararlıdır.

  • -C: Tüm verilerin (stdin, stdout, stderr ve yönlendirilen X11, TCP ve UNIX-domain bağlantılarına ait veriler dahil) sıkıştırılmasını ister. Sıkıştırma algoritması gzip(1) tarafından kullanılanla aynıdır. Sıkıştırma, modem hatlarında ve diğer yavaş bağlantılarda istenir, ancak hızlı ağlarda işleri yalnızca yavaşlatacaktır. Varsayılan değer yapılandırma dosyalarında ana bilgisayar bazında ayarlanabilir; ssh_config(5) içindeki Compression seçeneğine bakın.

-c cipher_spec Oturumu şifrelemek için şifreleme yöntemini (cipher) seçer. cipher_spec, tercih sırasına göre listelenmiş, virgülle ayrılmış bir şifreleme yöntemleri listesidir. Daha fazla bilgi için ssh_config(5) içindeki Ciphers anahtar sözcüğüne bakın.

-D [bind_address:]port Yerel bir "dinamik" uygulama düzeyinde port yönlendirmesi belirtir. Bu seçenek, yerel tarafta port dinlemek için isteğe bağlı olarak belirtilen bind_address adresine bağlı bir soket tahsis ederek çalışır. Bu porta her bağlantı yapıldığında bağlantı güvenli kanal üzerinden yönlendirilir ve ardından uzak makineden nereye bağlanılacağını belirlemek için uygulama protokolü kullanılır. Şu anda SOCKS4 ve SOCKS5 protokolleri desteklenmektedir ve ssh bir SOCKS sunucusu gibi davranacaktır. Yalnızca root ayrıcalıklı portları yönlendirebilir. Dinamik port yönlendirmeleri yapılandırma dosyasında da belirtilebilir.

IPv6 adresleri, adres köşeli parantez içine alınarak belirtilebilir. Yalnızca süper kullanıcı (superuser) ayrıcalıklı portları yönlendirebilir. Varsayılan olarak yerel port, GatewayPorts ayarına uygun olarak bağlanır (bind). Ancak bağlantıyı belirli bir adrese bağlamak için açık bir bind_address kullanılabilir. "localhost" şeklindeki bind_address, dinleme portunun yalnızca yerel kullanım için bağlanacağını gösterirken, boş bir adres veya ‘*’ portun tüm arayüzlerden erişilebilir olması gerektiğini gösterir.

-E log_file Hata ayıklama günlüklerini (debug logs) standart hata (stderr) yerine log_file dosyasına ekler.

-e escape_char Pty kullanan oturumlar için kaçış (escape) karakterini ayarlar (varsayılan: ‘~’). Kaçış karakteri yalnızca bir satırın başında tanınır. Kaçış karakterinin ardından gelen nokta (‘.’) bağlantıyı kapatır; control-Z bağlantıyı askıya alır; ve kendisi takip ettiğinde kaçış karakterini bir kez gönderer. Karakteri “none” olarak ayarlamak tüm kaçışları devre dışı bırakır ve oturumu tamamen saydam hale verir.

-F configfile Kullanıcıya özel alternatif bir yapılandırma dosyası belirtir. Komut satırında bir yapılandırma dosyası verilirse, sistem genelindeki yapılandırma dosyası (/etc/ssh/ssh_config) yoksayılacaktır. Kullanıcıya özel yapılandırma dosyası için varsayılan ~/.ssh/config'dir. “none” olarak ayarlanırsa hiçbir yapılandırma dosyası okunmayacaktır.

  • -f: ssh'ın komut yürütülmeden hemen önce arka plana geçmesini ister. Bu seçenek, ssh şifre veya parola soracaksa ancak kullanıcının bunun arka planda çalışmasını istemesi durumunda yararlıdır. Bu seçenek -n seçeneğini gerektirir. Uzak bir sitede X11 programlarını başlatmanın önerilen yolu, ssh -f host xterm gibi bir komut kullanmaktır.

ExitOnForwardFailure yapılandırma seçeneği “yes” olarak ayarlanırsa, -f ile başlatılan bir istemci arka plana geçmeden önce tüm uzak port yönlendirmelerinin başarıyla kurulmasını bekleyecektir. Ayrıntılar için ssh_config(5) içindeki ForkAfterAuthentication açıklamasına bakın.

  • -G: ssh'ın Host ve Match bloklarını değerlendirdikten sonra yapılandırmasını yazdırmasına ve çıkmasına neden olur.

  • -g: Uzak ana bilgisayarların yerel olarak yönlendirilmiş portlara bağlanmasına izin verir. Çoklu (multiplexed) bir bağlantıda kullanılıyorsa, bu seçenek ana (master) süreçte belirtilmelidir.

-I pkcs11 ssh'ın kullanıcı kimlik doğrulaması için anahtarlar sağlayan bir PKCS#11 belirteci (token) ile iletişim kurmak için kullanması gereken PKCS#11 paylaşılan kitaplığını belirtir. Bu seçeneğin kullanülmesi UseKeychain özelliğini devre dışı bırakacaktır.

-i identity_file Ortak anahtar (public key) kimlik doğrulaması için kimliğin (özel anahtar) okunacağı dosyayı seçer. Özel anahtar dosyası yerel olarak mevcut olmadığında, ssh-agent(1) içinde yüklü olan ilgili özel anahtarı kullanmak üzere bir ortak anahtar dosyası da belirtebilirsiniz. Varsayılan yollar ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 ve ~/.ssh/id_ed25519_sk şeklindedir. Kimlik dosyaları, yapılandırma dosyasında ana bilgisayar bazında da belirtilebilir. Birden fazla -i seçeneğine (ve yapılandırma dosyalarında belirtilen birden fazla kimliğe) sahip olmak mümkündür. CertificateFile yönergesi ile açıkça bir sertifika belirtilmemişse, ssh kimlik dosyası adlarına -cert.pub ekleyerek elde edilen dosya adından sertifika bilgilerini yüklemeyi de deneyecektir.

-J destination Önce destination ile tanımlanan sıçrama ana bilgisayarına (jump host) bir ssh bağlantısı kurup ardından oradan nihai hedefe bir TCP yönlendirmesi oluşturarak hedef ana bilgisayara bağlanır. Virgül karakterleriyle ayrılarak birden fazla sıçrama belirtilebilir. IPv6 adresleri, adres köşeli parantez içine alınarak belirtilebilir. Bu, bir ProxyJump yapılandırma yönergesini belirtmenin kısayoludur. Komut satırında sağlanan yapılandırma yönergelerinin genellikle belirtilen sıçrama ana bilgisayarlarına değil, hedef ana bilgisayara uygulandığını unutmayın. Sıçrama ana bilgisayarları için yapılandırmayı belirtmek üzere ~/.ssh/config dosyasını kullanın.

  • -K: GSSAPI tabanlı kimlik doğrulamayı ve GSSAPI kimlik bilgilerinin sunucuya yönlendirilmesini (delegasyonunu) etkinleştirir.

  • -k: GSSAPI kimlik bilgilerinin sunucuya yönlendirilmesini (delegasyonunu) devre dışı bırakır.

-L [bind_address:]port:host:hostport -L [bind_address:]port:remote_socket -L local_socket:host:hostport -L local_socket:remote_socket Yerel (istemci) ana bilgisayardaki belirtilen TCP portuna veya Unix soketine yapılan bağlantıların, uzak taraftaki belirtilen ana bilgisayar ve porta veya Unix soketine yönlendirileceğini belirtir. Bu seçenek, yerel tarafta bir TCP portunu (isteğe bağlı olarak belirtilen bind_address adresine bağlı) veya bir Unix soketini dinlemek için bir soket tahsis ederek çalışır. Yerel porta veya sokete her bağlantı yapıldığında, bağlantı güvenli kanal üzerinden yönlendirilir ve uzak makineden host port hostport'a veya Unix soketi remote_socket'e bir bağlantı kurulur.

Port yönlendirmeleri yapılandırma dosyasında da belirtilebilir. Yalnızca süper kullanıcı ayrıcalıklı portları yönlendirebilir. IPv6 adresleri, adres köşeli parantez içine alınarak belirtilebilir.

Varsayılan olarak yerel port, GatewayPorts ayarına uygun olarak bağlanır. Ancak bağlantıyı belirli bir adrese bağlamak için açık bir bind_address kullanılabilir. "localhost" şeklindeki bind_address, dinleme portunun yalnızca yerel kullanım için bağlanacağını gösterirken, boş bir adres veya ‘*’ portun tüm arayüzlerden erişilebilir olması gerektiğini gösterir.

-l login_name Uzak makinede oturum açacak kullanıcıyı belirtir. Bu durum, yapılandırma dosyasında ana bilgisayar bazında da belirtilebilir.

  • -M: Bağlantı paylaşımı için ssh istemcisini “master” (ana) moda geçirir. Birden fazla -M seçeneği ssh'ı master moda geçirir ancak çoğullama (multiplexing) durumunu değiştiren her işlemden (örneğin yeni bir oturum açılması) önce ssh-askpass(1) kullanılarak onay alınmasını gerektirir. Ayrıntılar için ssh_config(5) içindeki ControlMaster açıklamasına bakın.

-m mac_spec Tercih sırasına göre belirtilmiş, virgülle ayrılmış bir MAC (mesaj kimlik doğrulama kodu) algoritmaları listesi. Daha fazla bilgi için ssh_config(5) içindeki MACs anahtar sözcüğüne bakın.

  • -N: Uzak bir komut yürütmez. Bu seçenek, yalnızca port yönlendirme yapmak için kullanışlıdır. Ayrıntılar için ssh_config(5) içindeki SessionType açıklamasına bakın.

  • -n: stdin'i /dev/null adresine yönlendirir (aslında stdin'den okunmasını engeller). ssh arka planda çalıştırıldığında bu seçenek kullanılmalıdır. Yaygın bir yöntem, uzak bir makinede X11 programlarını çalıştırmak için bunu kullanmaktır. Örneğin, ssh -n shadows.cs.hut.fi emacs & shadows.cs.hut.fi üzerinde bir emacs başlatacaktır ve X11 bağlantısı şifrelenmiş bir kanal üzerinden otomatik olarak yönlendirilecektir. ssh programı arka plana yerleştirilecektir. (ssh'ın bir şifre veya parola sorması gerekiyorsa bu yöntem çalışmaz; ayrıca -f seçeneğine bakın.) Ayrıntılar için ssh_config(5) içindeki StdinNull açıklamasına bakın.

-O ctl_cmd Etkin bir bağlantı çoğullama ana (master) sürecini kontrol eder. -O seçeneği belirtildiğinde, ctl_cmd argümanı yorumlanır ve master sürece iletilir. Geçerli komutlar şunlardır: “check” (master sürecin çalışıp çalışmadığını kontrol eder), “forward” (komut yürütmeden yönlendirme ister), “cancel” (yönlendirmeleri iptal eder), “proxy” (çalışan bir çoğullama master sürecine proxy modunda bağlanır), “exit” (master sürecin çıkmasını ister) ve “stop” (master sürecin daha fazla çoğullama isteği kabul etmeyi durdurmasını ister).

-o option Yapılandırma dosyasında kullanılan biçimde seçenekler sunmak için kullanılabilir. Bu seçenek, ayrı bir komut satırı bayrağı olmayan seçenekleri belirtmek için yararlıdır. Aşağıda listelenen seçeneklerin ve olası değerlerinin tüm ayrıntıları için ssh_config(5) kılavuzuna bakın.

AddKeysToAgent AddressFamily BatchMode BindAddress BindInterface CASignatureAlgorithms CanonicalDomains CanonicalizeFallbackLocal CanonicalizeHostname CanonicalizeMaxDots CanonicalizePermittedCNAMEs CertificateFile ChannelTimeout CheckHostIP Ciphers ClearAllForwardings Compression ConnectTimeout ConnectionAttempts ControlMaster ControlPath ControlPersist DynamicForward EnableEscapeCommandline EnableSSHKeysign EscapeChar ExitOnForwardFailure FingerprintHash ForkAfterAuthentication ForwardAgent ForwardX11 ForwardX11Timeout ForwardX11Trusted GSSAPIAuthentication GSSAPIDelegateCredentials GatewayPorts GlobalKnownHostsFile HashKnownHosts Host HostKeyAlgorithms HostKeyAlias HostbasedAcceptedAlgorithms HostbasedAuthentication Hostname IPQoS IdentitiesOnly IdentityAgent IdentityFile IgnoreUnknown Include KbdInteractiveAuthentication KbdInteractiveDevices KexAlgorithms KnownHostsCommand LocalCommand LocalForward LogLevel LogVerbose MACs NoHostAuthenticationForLocalhost NumberOfPasswordPrompts ObscureKeystrokeTiming PKCS11Provider PasswordAuthentication PermitLocalCommand PermitRemoteOpen Port PreferredAuthentications ProxyCommand ProxyJump ProxyUseFdpass PubkeyAcceptedAlgorithms PubkeyAuthentication RekeyLimit RemoteCommand RemoteForward RequestTTY RequiredRSASize RevokedHostKeys SecurityKeyProvider SendEnv ServerAliveCountMax ServerAliveInterval SessionType SetEnv StdinNull StreamLocalBindMask StreamLocalBindUnlink StrictHostKeyChecking SyslogFacility TCPKeepAlive Tag Tunnel TunnelDevice UpdateHostKeys UseKeychain User UserKnownHostsFile VerifyHostKeyDNS VisualHostKey XAuthLocation

  • -P tag: ssh_config(5) içinde yapılandırma seçmek için kullanılabilecek bir etiket adı belirtir. Daha fazla bilgi için ssh_config(5) içindeki Tag ve Match anahtar kelimelerine bakın. -p port Uzak ana bilgisayarda bağlanılacak port. Bu durum, yapılandırma dosyasında ana bilgisayar bazında da belirtilebilir.

-Q query_option Aşağıdaki özelliklerden biri tarafından desteklenen algoritmaları sorgular: cipher (desteklenen simetrik şifreler), cipher-auth (kimlik doğrulamalı şifrelemeyi destekleyen desteklenen simetrik şifreler), help (-Q bayrağıyla kullanılmak üzere desteklenen sorgu terimleri), mac (desteklenen mesaj bütünlüğü kodları), kex (anahtar değişim algoritmaları), key (anahtar türleri), key-ca-sign (sertifikalar için geçerli CA imza algoritmaları), key-cert (sertifika anahtar türleri), key-plain (sertifika olmayan anahtar türleri), key-sig (tüm anahtar türleri ve imza algoritmaları), protocol-version (desteklenen SSH protokolü sürümleri) ve sig (desteklenen imza algoritmaları). Alternatif olarak, ssh_config(5) veya sshd_config(5) içinden bir algoritma listesi alan herhangi bir anahtar kelime, ilgili query_option için bir takma ad olarak kullanılabilir.

  • -q: Sessiz mod. Çoğu uyarı ve teşhis mesajının bastırılmasına neden olur.

-R [bind_address:]port:host:hostport -R [bind_address:]port:local_socket -R remote_socket:host:hostport -R remote_socket:local_socket -R [bind_address:]port Uzak (sunucu) ana bilgisayardaki belirtilen TCP portuna veya Unix soketine yapılan bağlantıların yerel tarafa yönlendirileceğini belirtir.

Bu seçenek, uzak tarafta bir TCP portunu veya bir Unix soketini dinlemek için bir soket tahsis ederek çalışır. Bu porta veya Unix soketine her bağlantı yapıldığında bağlantı güvenli kanal üzerinden yönlendirilir ve yerel makineden host port hostport ile belirtilen açık bir hedefe ya da local_socket soketine veya açık bir hedef belirtilmemişse ssh bir SOCKS 4/5 proxy gibi davranarak bağlantıları uzak SOCKS istemcisi tarafından talep edilen hedeflere yönlendirecektir.

Port yönlendirmeleri yapılandırma dosyasında da belirtilebilir. Ayrıcalıklı portlar, yalnızca uzak makinede root olarak oturum açıldığında yönlendirilebilir. IPv6 adresleri, adres köşeli parantez içine alınarak belirtilebilir.

Varsayılan olarak sunucudaki TCP dinleme soketleri yalnızca loopback arayüzüne bağlanacaktır. Bu durum bir bind_address belirtilerek geçersiz kılınabilir. Boş bir bind_address veya ‘*’ adresi, uzak soketin tüm arayüzlerde dinlemesi gerektiğini gösterir. Uzak bir bind_address belirtmek, yalnızca sunucunun GatewayPorts seçeneği etkinleştirildiğinde başarılı olacaktır (bkz. sshd_config(5)).

Port argümanı ‘0’ ise, dinleme portu sunucuda dinamik olarak tahsis edilecek ve çalışma zamanında istemciye bildirilecektir. -O forward ile birlikte kullanıldığında, tahsis edilen port standart çıktıya yazdırılacaktır.

-S ctl_path Bağlantı paylaşımı için bir kontrol soketinin konumunu veya bağlantı paylaşımını devre dışı bırakmak için “none” dizesini belirtir. Ayrıntılar için ssh_config(5) kılavuzundaki ControlPath ve ControlMaster açıklamalarına bakın.

  • -s: Uzak sistemde bir alt sistemin (subsystem) çağrılmasını talep etmek için kullanılabilir. Alt sistemler, SSH'ın diğer uygulamalar için güvenli bir taşıyıcı olarak kullanılmasını kolaylaştırır (örneğin sftp(1)). Alt sistem uzak komut olarak belirtilir. Ayrıntılar için ssh_config(5) içindeki SessionType açıklamasına bakın.

  • -T: Sözde terminal (pseudo-terminal) tahsisini devre dışı bırakır.

  • -t: Sözde terminal (pseudo-terminal) tahsisini zorlar. Bu seçenek, uzak bir makinede ekran tabanlı herhangi bir programı yürütmek için kullanılabilir, bu da örneğin menü hizmetleri uygularken çok yararlı olabilir. Birden fazla -t seçeneği, ssh'ın yerel bir tty'si olmasa bile tty tahsisini zorlar.

  • -V: Sürüm numarasını görüntüler ve çıkar.

  • -v: Ayrıntılı mod. ssh'ın ilerleyişi hakkında hata ayıklama mesajları yazdırmasını sağlar. Bu seçenek; bağlantı, kimlik doğrulama ve yapılandırma sorunlarının giderilmesinde yardımcı olur. Birden fazla -v seçeneği ayrıntı düzeyini artırır. Maksimum değer 3'tür.

-W host:port İstemcideki standart girdi ve çıktının, güvenli kanal üzerinden host üzerindeki port bağlantı noktasına yönlendirilemesini talep eder. -N, -T, ExitOnForwardFailure ve ClearAllForwardings seçeneklerini gerektirir, ancak bunlar yapılandırma dosyasında veya -o komut satırı seçenekleri kullanılarak geçersiz kılınabilir.

-w local_tun[:remote_tun] İstemci (local_tun) ile sunucu (remote_tun) arasında belirtilen tun(4) aygıtları ile tünel aygıtı yönlendirmesi talep eder.

Aygıtlar sayısal kimlikle (ID) veya kullanılabilir bir sonraki tünel aygıtını kullanan “any” anahtar kelimesiyle belirtilebilir. remote_tun belirtilmemişse, varsayılan olarak “any” değerini alır. Ayrıca ssh_config(5) içindeki Tunnel ve TunnelDevice yönergelerine bakın.

Tunnel yönergesi ayarlanmamışsa, varsayılan tünel modu olan “point-to-point” moduna ayarlanacaktır. Farklı bir Tunnel yönlendirme modu isteniyorsa, bu mod -w seçeneğinden önce belirtilmelidir.

  • -X: X11 yönlendirmesini etkinleştirir. Bu durum, bir yapılandırma dosyasında her ana bilgisayar bazında da belirtilebilir.

X11 yönlendirmesi dikkatli bir şekilde etkinleştirilmelidir. Uzak ana bilgisayarda dosya izinlerini (kullanıcının X yetkilendirme veritabanı için) aşma yeteneğine sahip kullanıcılar, yönlendirilen bağlantı aracılığıyla yerel X11 ekranına erişebilirler. Bu durumda bir saldırgan, tuş vuruşlarını izleme gibi etkinlikler gerçekleştirebilir.

Bu nedenle, X11 yönlendirmesi varsayılan olarak X11 SECURITY uzantısı kısıtlamalarına tabi tutulur. Daha fazla bilgi için ssh -Y seçeneğine ve ssh_config(5) içindeki ForwardX11Trusted yönergesine bakın.

  • -x: X11 yönlendirmesini devre dışı bırakır.

  • -Y: Güvenilir X11 yönlendirmesini etkinleştirir. Güvenilir X11 yönlendirmeleri, X11 SECURITY uzantısı kontrollerine tabi değildir.

  • -y: syslog(3) sistem modülünü kullanarak günlük bilgilerini gönderir. Varsayılan olarak bu bilgiler stderr'e gönderilir.

ssh ek olarak kullanıcıya özel bir yapılandırma dosyasından ve sistem genelindeki bir yapılandırma dosyasından yapılandırma verileri elde edebilir. Dosya biçimi ve yapılandırma seçenekleri ssh_config(5) kılavuzunda açıklanmıştır.

Kimlik Doğrulama

OpenSSH SSH istemcisi SSH protokol 2'yi destekler.

Kimlik doğrulama için kullanılabilen yöntemler şunlardır: GSSAPI tabanlı kimlik doğrulama, ana bilgisayar tabanlı (host-based) kimlik doğrulama, ortak anahtar (public key) kimlik doğrulaması, klavye etkileşimli (keyboard-interactive) kimlik doğrulama ve şifre (password) kimlik doğrulaması. PreferredAuthentications varsayılan sırayı değiştirmek için kullanılabilse de, kimlik doğrulama yöntemleri yukarıda belirtilen sırada denenir.

Ana bilgisayar tabanlı (host-based) kimlik doğrulama şu şekilde çalışır: Kullanıcının oturum açtığı makine uzak makinedeki /etc/hosts.equiv or /etc/shosts.equiv dosyalarında listelenmişse, kullanıcı root değilse ve kullanıcı adları her iki tarafta da aynıysa veya uzak makinede kullanıcının ana dizinindeki ~/.rhosts veya ~/.shosts dosyaları mevcutsa ve istemci makinesinin adını ve o makinedeki kullanıcının adını içeren bir satır içeriyorsa, kullanıcının oturum açması değerlendirilir. Ek olarak, oturum açmaya izin verilmesi için sunucunun istemcinin ana bilgisayar anahtarını doğrulayabilmesi gerekir (aşağıdaki /etc/ssh/ssh_known_hosts ve ~/.ssh/known_hosts açıklamalarına bakın). Bu kimlik doğrulama yöntemi; IP sahtekarlığı (IP spoofing), DNS sahtekarlığı (DNS spoofing) ve yönlendirme sahtekarlığından (routing spoofing) kaynaklanan güvenlik açıklarını kapatır. [Yöneticiye not: /etc/hosts.equiv, ~/.rhosts ve genel olarak rlogin/rsh protokolü doğası gereği güvensizdir ve güvenlik isteniyorsa devre dışı bırakılmalıdır.]

Ortak anahtar (public key) kimlik doğrulaması şu şekilde çalışır: Şema, şifreleme ve şifre çözmenin ayrı anahtarlar kullanılarak yapıldığı ve şifre çözme anahtarının şifreleme anahtarından elde edilmesinin imkansız olduğu ortak anahtarlı şifrelemeye dayanır. Buradaki fikir, her kullanıcının kimlik doğrulama amacıyla bir ortak/özel anahtar çifti oluşturmasıdır. Sunucu ortak anahtarı bilir ve yalnızca kullanıcı özel anahtarı bilir. ssh; ECDSA, Ed25519 veya RSA algoritmalarından birini kullanarak ortak anahtar kimlik doğrulama protokolünü otomatik olarak uygular.

The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account.

The server may inform the client of errors that prevented public key authentication from succeeding after authentication completes using a different method. These may be viewed by increasing the LogLevel to DEBUG or higher (e.g. by using the -v flag).

The user creates their key pair by running ssh-keygen(1). This stores the private key in ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (authenticator-hosted ECDSA), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (authenticator-hosted Ed25519), or ~/.ssh/id_rsa (RSA) and stores the public key in ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (authenticator- hosted ECDSA), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (authenticator-hosted Ed25519), or ~/.ssh/id_rsa.pub (RSA) in the user's home directory. The user should then copy the public key to ~/.ssh/authorized_keys in their home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, the user can log in without giving the password.

A variation on public key authentication is available in the form of certificate authentication: instead of a set of public/private keys, signed certificates are used. This has the advantage that a single trusted certification authority can be used in place of many public/private keys. See the CERTIFICATES section of ssh-keygen(1) for more information.

The most convenient way to use public key or certificate authentication may be with an authentication agent. See ssh-agent(1) and (optionally) the AddKeysToAgent directive in ssh_config(5) for more information.

Keyboard-interactive authentication works as follows: The server sends an arbitrary "challenge" text and prompts for a response, possibly multiple times. Examples of keyboard-interactive authentication include BSD Authentication (see login.conf(5)) and PAM (some non-OpenBSD systems).

Finally, if other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network.

ssh automatically maintains and checks a database containing identification for all hosts it has ever been used with. Host keys are stored in ~/.ssh/known_hosts in the user's home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user's file. If a host's identification ever changes, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could otherwise be used to circumvent the encryption. The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed.

When the user's identity has been accepted by the server, the server either executes the given command in a non-interactive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interactive session. All communication with the remote command or shell will be automatically encrypted.

If an interactive session is requested, ssh by default will only request a pseudo-terminal (pty) for interactive sessions when the client has one. The flags -T and -t can be used to override this behaviour.

If a pseudo-terminal has been allocated, the user may use the escape characters noted below.

If no pseudo-terminal has been allocated, the session is transparent and can be used to reliably transfer binary data. On most systems, setting the escape character to “none” will also make the session transparent even if a tty is used.

The session terminates when the command or shell on the remote machine exits and all X11 and TCP connections have been closed.

Escape Characters

When a pseudo-terminal has been requested, ssh supports a number of functions through the use of an escape character.

A single tilde character can be sent as ~~ or by following the tilde by a character other than those described below. The escape character must always follow a newline to be interpreted as special. The escape character can be changed in configuration files using the EscapeChar configuration directive or on the command line by the -e option.

The supported escapes (assuming the default ‘~’) are:

~. Disconnect.

~^Z Background ssh.

~# List forwarded connections.

~& Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.

~? Display a list of escape characters.

~B Send a BREAK to the remote system (only useful if the peer supports it).

~C Open command line. Currently this allows the addition of port forwardings using the

  • -L, -R and -D options (see above).: It also allows the cancellation of existing port- forwardings with -KL[bind_address:]port for local, -KR[bind_address:]port for remote and -KD[bind_address:]port for dynamic port-forwardings. !command allows the user to execute a local command if the PermitLocalCommand option is enabled in ssh_config(5). Basic help is available, using the -h option.

~R Request rekeying of the connection (only useful if the peer supports it).

~V Decrease the verbosity (LogLevel) when errors are being written to stderr.

~v Increase the verbosity (LogLevel) when errors are being written to stderr.

Tcp Forwarding

Forwarding of arbitrary TCP connections over a secure channel can be specified either on the command line or in a configuration file. One possible application of TCP forwarding is a secure connection to a mail server; another is going through firewalls.

In the example below, we look at encrypting communication for an IRC client, even though the IRC server it connects to does not directly support encrypted communication. This works as follows: the user connects to the remote host using ssh, specifying the ports to be used to forward the connection. After that it is possible to start the program locally, and ssh will encrypt and forward the connection to the remote server.

The following example tunnels an IRC session from the client to an IRC server at “server.example.com”, joining channel “#users”, nickname “pinky”, using the standard IRC port, 6667:

$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10 $ irc -c '#users' pinky IRC/127.0.0.1

The -f option backgrounds ssh and the remote command “sleep 10” is specified to allow an amount of time (10 seconds, in the example) to start the program which is going to use the tunnel. If no connections are made within the time specified, ssh will exit.

X11 FORWARDING If the ForwardX11 variable is set to “yes” (or see the description of the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell (or command) will go through the encrypted channel, and the connection to the real X server will be made from the local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configuration files.

The DISPLAY value set by ssh will point to the server machine, but with a display number greater than zero. This is normal, and happens because ssh creates a “proxy” X server on the server machine for forwarding the connections over the encrypted channel.

ssh will also automatically set up Xauthority data on the server machine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain).

If the ForwardAgent variable is set to “yes” (or see the description of the -A and -a options above) and the user is using an authentication agent, the connection to the agent is automatically forwarded to the remote side.

Verifying Host Keys

When connecting to a server for the first time, a fingerprint of the server's public key is presented to the user (unless the option StrictHostKeyChecking has been disabled). Fingerprints can be determined using ssh-keygen(1):

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

If the fingerprint is already known, it can be matched and the key can be accepted or rejected. If only legacy (MD5) fingerprints for the server are available, the ssh-keygen(1) -E option may be used to downgrade the fingerprint algorithm to match.

Because of the difficulty of comparing host keys just by looking at fingerprint strings, there is also support to compare host keys visually, using random art. By setting the VisualHostKey option to “yes”, a small ASCII graphic gets displayed on every login to a server, no matter if the session itself is interactive or not. By learning the pattern a known server produces, a user can easily find out that the host key has changed when a completely different pattern is displayed. Because these patterns are not unambiguous however, a pattern that looks similar to the pattern remembered only gives a good probability that the host key is the same, not guaranteed proof.

To get a listing of the fingerprints along with their random art for all known hosts, the following command line can be used:

$ ssh-keygen -lv -f ~/.ssh/known_hosts

If the fingerprint is unknown, an alternative method of verification is available: SSH fingerprints verified by DNS. An additional resource record (RR), SSHFP, is added to a zonefile and the connecting client is able to match the fingerprint with that of the key presented.

In this example, we are connecting a client to a server, “host.example.com”. The SSHFP resource records should first be added to the zonefile for host.example.com:

$ ssh-keygen -r host.example.com.

The output lines will have to be added to the zonefile. To check that the zone is answering fingerprint queries:

$ dig -t SSHFP host.example.com

Finally the client connects:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com [...] Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?

See the VerifyHostKeyDNS option in ssh_config(5) for more information.

SSH-BASED VIRTUAL PRIVATE NETWORKS ssh contains support for Virtual Private Network (VPN) tunnelling using the tun(4) network pseudo-device, allowing two networks to be joined securely. The sshd_config(5) configuration option PermitTunnel controls whether the server supports this, and at what level (layer 2 or 3 traffic).

The following example would connect client network 10.0.50.0/24 with remote network 10.0.99.0/24 using a point-to-point connection from 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway to the remote network, at 192.168.1.15, allows it.

On the client:

ssh -f -w 0:1 192.168.1.15 true

ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252

route add 10.0.99.0/24 10.1.1.2

On the server:

ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252

route add 10.0.50.0/24 10.1.1.1

Client access may be more finely tuned via the /root/.ssh/authorized_keys file (see below) and the PermitRootLogin server option. The following entry would permit connections on tun(4) device 1 from user “jane” and on tun device 2 from user “john”, if PermitRootLogin is set to “forced-commands-only”:

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Since an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More permanent VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).

Environment

ssh will normally set the following environment variables:

DISPLAY The DISPLAY variable indicates the location of the X11 server. It is automatically set by ssh to point to a value of the form “hostname:n”, where “hostname” indicates the host where the shell runs, and ‘n’ is an integer ≥ 1. ssh uses this special value to forward X11 connections over the secure channel. The user should normally not set DISPLAY explicitly, as that will render the X11 connection insecure (and will require the user to manually copy any required authorization cookies).

HOME Set to the path of the user's home directory.

LOGNAME Synonym for USER; set for compatibility with systems that use this variable.

MAIL Set to the path of the user's mailbox.

PATH Set to the default PATH, as specified when compiling ssh.

SSH_ASKPASS If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)

SSH_ASKPASS_REQUIRE Allows further control over the use of an askpass program. If this variable is set to “never” then ssh will never attempt to use one. If it is set to “prefer”, then ssh will prefer to use the askpass program instead of the TTY when requesting passwords. Finally, if the variable is set to “force”, then the askpass program will be used for all passphrase input regardless of whether DISPLAY is set.

SSH_AUTH_SOCK Identifies the path of a UNIX-domain socket used to communicate with the agent.

SSH_CONNECTION Identifies the client and server ends of the connection. The variable contains four space-separated values: client IP address, client port number, server IP address, and server port number.

SSH_ORIGINAL_COMMAND This variable contains the original command line if a forced command is executed. It can be used to extract the original arguments.

SSH_TTY This is set to the name of the tty (path to the device) associated with the current shell or command. If the current session has no tty, this variable is not set.

SSH_TUNNEL Optionally set by sshd(8) to contain the interface names assigned if tunnel forwarding was requested by the client.

SSH_USER_AUTH Optionally set by sshd(8), this variable may contain a pathname to a file that lists the authentication methods successfully used when the session was established, including any public keys that were used.

TZ This variable is set to indicate the present time zone if it was set when the daemon was started (i.e. the daemon passes the value on to new connections).

USER Set to the name of the user logging in.

Additionally, ssh reads ~/.ssh/environment, and adds lines of the format “VARNAME=value” to the environment if the file exists and users are allowed to change their environment. For more information, see the PermitUserEnvironment option in sshd_config(5).

Files

~/.rhosts This file is used for host-based authentication (see above). On some machines this file may need to be world-readable if the user's home directory is on an NFS partition, because sshd(8) reads it as root. Additionally, this file must be owned by the user, and must not have write permissions for anyone else. The recommended permission for most machines is read/write for the user, and not accessible by others.

~/.shosts This file is used in exactly the same way as .rhosts, but allows host-based authentication without permitting login with rlogin/rsh.

~/.ssh/ This directory is the default location for all user-specific configuration and authentication information. There is no general requirement to keep the entire contents of this directory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others.

~/.ssh/authorized_keys Lists the public keys (ECDSA, Ed25519, RSA) that can be used for logging in as this user. The format of this file is described in the sshd(8) manual page. This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.

~/.ssh/config This is the per-user configuration file. The file format and configuration options are described in ssh_config(5). Because of the potential for abuse, this file must have strict permissions: read/write for the user, and not writable by others.

~/.ssh/environment Contains additional definitions for environment variables; see ENVIRONMENT, above.

~/.ssh/id_ecdsa ~/.ssh/id_ecdsa_sk ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_sk ~/.ssh/id_rsa Contains the private key for authentication. These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute). ssh will simply ignore a private key file if it is accessible by others. It is possible to specify a passphrase when generating the key which will be used to encrypt the sensitive part of this file using AES-128.

~/.ssh/id_ecdsa.pub ~/.ssh/id_ecdsa_sk.pub ~/.ssh/id_ed25519.pub ~/.ssh/id_ed25519_sk.pub ~/.ssh/id_rsa.pub Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone.

~/.ssh/known_hosts Contains a list of host keys for all hosts the user has logged into that are not already in the systemwide list of known host keys. See sshd(8) for further details of the format of this file.

~/.ssh/rc Commands in this file are executed by ssh when the user logs in, just before the user's shell (or command) is started. See the sshd(8) manual page for more information.

/etc/hosts.equiv This file is for host-based authentication (see above). It should only be writable by root.

/etc/shosts.equiv This file is used in exactly the same way as hosts.equiv, but allows host-based authentication without permitting login with rlogin/rsh.

/etc/ssh/ssh_config Systemwide configuration file. The file format and configuration options are described in ssh_config(5).

/etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ed25519_key /etc/ssh/ssh_host_rsa_key These files contain the private parts of the host keys and are used for host-based authentication.

/etc/ssh/ssh_known_hosts Systemwide list of known host keys. This file should be prepared by the system administrator to contain the public host keys of all machines in the organization. It should be world-readable. See sshd(8) for further details of the format of this file.

/etc/ssh/sshrc Commands in this file are executed by ssh when the user logs in, just before the user's shell (or command) is started. See the sshd(8) manual page for more information.

Exit Status

ssh exits with the exit status of the remote command or with 255 if an error occurred.

See Also

scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

Standards

S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, January 2006.

J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, January 2006.

F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, January 2006.

J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, January 2006.

M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, January 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, January 2006.

M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006.

J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, November 2006.

D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, December 2009.

A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

Authors

OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH. Markus Friedl contributed the support for SSH protocol versions 1.5 and 2.0.

macOS 26.4 December 4, 2024 macOS 26.4