SSH tuşları yasaklanmışsa şifreyi önbelleğe al


46

Bunu hesapladığım için ssh üzerinden sık sık erişmem gereken bir sunucum var. Şimdi, bilgi işlem merkezi açıkça "güvensiz" oldukları için SSH anahtarlarını yasaklıyor . Şifremi klavyede yazmak her zaman, diğer insanların önünde mümkün olsa da, giriş yapmak için çok daha güvenli bir yol olduğunu düşünüyorlar.

Şimdi; Fikirlerini değiştiremiyorum (denedim).

En azından SSH şifrelerini geçici olarak saklamanın bir yolu var mı, GIT'in belirli bir süre boyunca şifreleri bir önbellekte saklayabilmesi?


55
the computing center explicitly forbids SSH-keys because they are "insecure"- bu konuda fikrimi? Sizinki açıkçası beceriksiz olduğu için yeni bir sunucu ana bilgisayarı bulun.
Matt Clark

18
@Matt: "bilgi işlem merkezi", sanırım neredeyse rekabet etmeyen, akademik bir grid sistemine benziyor
Grawity

27
Onlar yanlış. Muhtemelen hesaplarının süresi dolduğunda ssh anahtarlarını devre dışı bırakmayı unutmuşlardır, bu yüzden ssh anahtarlarının sorun olduğuna karar vermişlerdir.
Joshua,

10
yerçekimi haklıdır. bu bir ulusal süper bilgisayar, bu yüzden ona bağlı kaldım. Buna değer, makine güzel. Joshua muhtemelen de haklıdır, ama, bu, hiçbir şey için iyi olmayan bir tür haktır
user2667180

7
@TheHansinator Eğer kurulu bir keylogger varsa, ssh bağlantılarınızı koruyup korumamadığınızın artık önemli olmadığı noktalardan ödün verdiniz. Ancak, publickeykimlik doğrulamanın başka avantajları da vardır . passwordSunucuda kimlik doğrulamasını devre dışı bırakırsanız , tüm saldırganların parola tahmin etmeye çalışmasını önlersiniz. Bir saldırgan daha önce sunucunun genel anahtarını kaydetmemiş bir istemciye yönelik bir saldırı saldırısı girişiminde publickeybulunursa, passwordkimlik doğrulaması kullandığınızdan çok daha iyi korunursunuz .
kasperd

Yanıtlar:


63

Bağlantı yeniden

SSHv2, aynı kimliği doğrulanmış bağlantının, birden fazla 'kanal' (etkileşimli kabuk, toplu komut, SFTP, ayrıca aracı iletme veya TCP iletme gibi ikincil olanlar) kurmasına olanak tanır. Sunucunuz muhtemelen varsayılan olarak bağlantı çoklamayı desteklemektedir. (Yöneticileriniz şikayet ederse, şifrenizi hiçbir yerde önbelleğe almaz - tüm bağlantıyı önler.)

OpenSSH ile var ControlMasterve ControlPathbu marka kullanımına seçenekleri (-M ve -S):

  1. 'Master' SSH bağlantısını kullanarak başlatın -M. (Konfigürasyonunuzda henüz bir ControlPath bulunmadığından, onu komut satırında belirtmeniz gerekir -S. Uzun sürmesi gerekiyor, bu yüzden -fNarka plana bırakma seçeneklerini ekliyorum ; aksi takdirde teknik olarak isteğe bağlılar.)

    $ ssh foo@bar.example.com -fNMS ~/.ssh/bar.socket
    foo@bar.example.com's password:
    

    Yerel kabuğa geri döndün.

  2. Master üzerinden yeni bir bağlantı başlatın:

    $ ssh foo@bar.example.com -S ~/.ssh/bar.socket
    

    İçindesin.

  3. Bunu Git / rsync / SFTP için kullanışlı hale getirmek için ControlPath, yapılandırmanızı ayarlamanız gerekir , çünkü -Sher zaman belirleyemezsiniz :

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p
    

Bunu otomatikleştirebilirsiniz - yakın zamanda açılmış ControlPersistolan OpenSSH sürümleri , henüz bir tane yoksa arka planda otomatik olarak bir ana bağlantı kuranlar da var . Bu, adım 1'i atlamanıza ve normalde yaptığınız gibi sadece ssh kullanmanıza izin verir .

  1. Yapılandırma ~/.ssh/config:

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p
        ControlMaster auto
        ControlPersist 15m
    
  2. İlk bağlantı şifre ister:

    $ ssh foo@bar.example.com
    foo@bar.example.com's password:
    [foo@bar:~]$ exit
    
  3. İkincisi:

    $ ssh foo@bar.example.com
    [foo@bar:~]$ yay
    

Çoklayıcı ana kontrol etmek için (durdur ya da TCP yönlendirmelerini yapılandır), -Oseçeneği kullanın.

Benzer bir yöntem, son PuTTY sürümleri tarafından desteklenmektedir .


1
bu güzel cevap için çok teşekkür ederim. google bu sorun için faydalı değildi, çünkü her zaman ssh-keys'e dönüştü ve doğru anahtar kelimeleri bilmiyordum. bana çok yardım etti!
user2667180

1
Söylemeden geçmesi gerekir, ancak bu yapılandırmayı kullanırsanız, hesabınızın güvende olduğundan emin olmanız ve .ssh klasörünüzün o makinedeki kanal dosyalarına erişimi olan herhangi birisinin cihazınızdan çıkabilmesi nedeniyle doğru şekilde kilitlendiğinden emin olmanız zorunludur. bağlantıya geçin ve sunucuya sizin gibi erişin.
shellster

3
@shellster: "Aynı kullanıcı kimliğine sahip olan herkes" demek, tıpkı ssh-agent'ta olduğu gibi. Soket dosyasının izinlerini bilerek açsanız bile (varsayılan olarak 0600 olan), diğer kullanıcılar yalnızca "multiplex uid uyuşmazlığı" nı alırlar.
04'te

3
@shellster Kök olan biri bir keylogger yükleyebilir ve şifrenizi uzaktaki sisteme yine de çalabilir ya da çok sayıda gereksiz şey yapabilir. Yerel kök konusunda endişeleniyorsak, bu bir SSH özel anahtarı kaydetmekten daha az güvenli değildir.
amalloy

1
Yerel kökü bir tehdit olarak görmüyorum çünkü eğer bir tehdit olursa, ne olursa olsun tostsunuz. (Devlet notunda casuslukta olduğu gibi.) Açıkçası yerel bir kök, ssh müşterinizi ve ssh-ajanını istediği şeyle değiştirebilir. Tüm şifreler ve özel anahtarlar /root/.secret? Elbette.
Grawity

19

kullanım sshpass

sshpass ( github , man page ), parolayı otomatik olarak ssh'ye besleyen bir araçtır. Bunu kullanmanın güvenli yolu şudur:

% echo 'correct horse battery staple' > ~/.ssh/compute_password
% chmod go-rw ~/.ssh/compute_password

% sshpass -f ~/.ssh/compute_password ssh foo@host

Bu, parolayı, parola ~/.ssh/compute_passwordiçermeyen özel bir anahtar dosyasına benzer olarak okur . sshpassKomutu yazmaktan kaçınmak için komutu küçük bir kabuk komut dosyasına veya bir kabuk diğer adına koyabilirsiniz . Ne yazık ki, bunu yapmanın bir yolunu bulamadım ~/.ssh/config.

(Şifreyi doğrudan komut satırında belirtmek de mümkündür sshpass, ancak şifreyi yapabilecek herkese sızdırdığı için bundan kaçınılmalıdır ps)

Diğer yöntemlerle karşılaştırılması

Elbette bu yaklaşım, genel anahtar kimlik doğrulamasının doğru şekilde kurulmasından daha az güvenlidir, ancak muhtemelen bunu zaten biliyorsunuzdur.

Ayrıca @ Grawity'nin bağlantının yeniden kullanımı konusundaki cevabından daha az güvenlidir, ancak şifreyi hiçbir zaman etkileşimli olarak girmemesi avantajına sahiptir.

@ Grawity'nin cevabını parola ve özel anahtar önbelleğe alma (yani ssh-agent) ile pubkey auth için bir alternatif olarak düşünebilirsiniz . O zaman cevabım özel anahtar dosyasında bir parola olmadan pubkey auth için bir alternatif olacaktır.


3
Eğer bilgi işlem merkezinin politikası "ama anahtarlar birisinin onları çalabileceği diskte saklanıyor!" Temeline dayanıyorsa, o zaman politika geri tepmeye başlayacak gibi görünüyor.
Grawity

6
@grawity Kötü politikalar daha kötü çalışma ortamlarına bile yol açıyor ¯ \ _ (ツ) _ / ¯
mart

1
Parolanızı yeterince uzun rastgele karakterler akışı olarak oluşturursanız ( head -c 16 /dev/urandom | base64128 bit için söyleyin ) ve diğer sistemlerde kullanmıyorsanız, güvenlik açısından bir tuşa benzer. Kaba kuvvet zor ve şifreli değilse dosyadan kullanmak kadar basit. Dosyayı alırlarsa, bu kötü adam için de geçerli. Tek fark, şifrenin sunucuya olduğu gibi gönderilmesidir. Anahtarlar, açık anahtarı olmadan doğru özel anahtara sahip olduğunuzu kanıtlamak için daha iyi matematiklere sahipken ve kullanılabilirlik açısından, şifreyi içeren dosyayı şifrelemek daha zordur (hayır standart araçlar).
ilkkachu

1

Şifre yöneticisini kullanın.

Bazı şifre yöneticileri (ör. KeePassXC) 'otomatik yazma' özelliğine sahiptir. Şifreyi şifre yöneticisinde saklar, yöneticiyi çalıştırdığınızda veritabanının kilidini açarsınız ve her seferinde sshşifrenizi isterse, şifre yöneticisinin konsola uzun şifrenizi yazmasını sağlayan bir tuş bileşimine basarsınız.

Kopyalamaya gerek yok, herhangi bir şey hatırlayın (veritabanının kilidini açmak için parola hariç) ve her 30 giriş yaptığınızda o şifreyi ezmeden güçlü bir parolanız olabilir.

En sevdiğiniz listeden seçebilirsiniz: https://en.wikipedia.org/wiki/List_of_password_managers


3
Otomatik tür özelliğinin terminal tabanlı programlarla iyi çalışıp çalışmadığından emin değilim. Algılama belirli bir pencere başlığı arayacak ve ototipleme en iyi şekilde KeePass2'nin sahip olduğu "anti-keylogging" özelliklerine sahip olmasa da ...
grawity

1
@grawity , ssh benden parola istediğinde gnome-terminalbaşlığını değiştirir ssh somehost, böylece başlık penceresini bu sorunla eşleştirebilirsiniz. Anti-keylogging (anti-keylogging) özellikleri hakkında hiçbir şey bilmiyorum - Günlük olarak terminalde KeePassXC kullanıyorum ve uğraşmam en kötüsü listeden uygun hesabı seçmek.
Strafor fly

2
@grawity Anti-keylogging özelliklerinin zaten giriş başına etkinleştirilmesi gerekir (tam olarak birçok programın yapıştırmayı desteklememesi nedeniyle).
Bob

0

Başka bir alternatif bir GUI ssh istemcisi kullanmaktır. Windows'ta bariz seçenek PuTTY olurdu . Ayrıca PuTTY'nin bir Linux sürümü var, özellikle Ubuntu gibi Debian tabanlı dağıtımlar normalde depolarında PuTTY içeriyor.

Gerçekten iyi bir müşteri de Termius . Sadece Windows ve Linux'u değil aynı zamanda OSX, iOS ve Android'i de destekliyor. Öncelikle telefonlar için tasarlanmış olmasına rağmen, masaüstü sürümü aslında oldukça iyi.

Yanılmıyorsam, Windows'taki saygıdeğer Hyperterminal'in yerleşik bir ssh istemcisi var / var ancak çok uzun zamandır pencereleri kullanmadım, bu yüzden tamamen emin değilim.

Tüm GUI istemcileri, kullanıcı adınızı ve şifrenizi içeren bağlantı ayarlarını kaydetme özelliğini içerir.


2
"GUI tabanlı", PuTTY'nin açıkça yapmayı reddettiği , şifrenizi saklamanıza izin vereceği anlamına gelmez . Windows ile birlikte gelen HyperTerminal sürümü yalnızca Telnet'tir, daha çok seri bağlantılara odaklanırdı. Belki de SSH desteği olan Windows için CKermit'i düşünüyorsunuz, ancak şifre desteği o kadar eski ki, pek çok geçerli sunucuya kolayca bağlanamayacak.
Grawity
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.