Bir ortam değişkenini ssh komutuyla nasıl iletebilirim? [çift]


42

Bir ssh komutuna bir değeri nasıl iletebilirim, öyle ki ana makinede başlatılan ortam benim seçimime ayarlanmış belirli bir ortam değişkeni ile başlar.

DÜZENLEME: Amaç benim için bir nfs yerleri geri geçirebilmesi için oluşturulan yeni kabuğuna (dcop kwin KWinInterface currentDesktop itibaren) geçerli KDE masaüstü geçmektir JEdit her KDE masaüstü için benzersizdir orijinal sunucuda örneği. ( Emacsserver / emacsclient gibi bir mekanizma kullanarak )

Birden fazla ssh örneğinin aynı anda uçuşta olmasının nedeni, ortamımı kurarken, farklı makinelere bir grup farklı ssh örneği açmamdır.

Yanıtlar:


17

~/.ssh/environmentDosya uzak komutlar için kullanılabilir olmasını istediğiniz set değişkenlere kullanılabilir. PermitUserEnvironmentSshd yapılandırmasında etkinleştirmek zorunda kalacaksınız .

Bu şekilde ayarlanan değişkenler alt işlemlere aktarılır, böylece:

echo "Foo=Bar" > sshenv
echo "Joe=37" >> sshenv
scp sshenv user@server:~/.ssh/environment
ssh user@server myscript

ve myscript, Foo'nun Bar ve Joe'nun 37 olduğunu bilecek.


3
değişkenin potansiyel olarak her ssh aramasını değiştirmesi gerekir
Ross Rogers

1
Ne yapmaya çalıştığını ve nedenini açıklamak daha iyi olabilir. Başka çözümler olabilir. Ortam dosyasının her ssh çağrısında dinamik olarak oluşturulması gerekir, bu imkansız değildir.
EmmEff

Ne değişecek? Bu değişkenlerin değerleri hatta isimleri?
innaM

lanetlemek. Bu çözümü denedim, ancak sshd config dosyasına erişemiyorum ve ~ / .ssh / ortamına değişkenler koyarak ~ / .ssh2 / ortamlarına çalışmıyor. Sanırım bu değişkeni bir nfs diskinde bıraktığımda bir kludge kullanacağım ve sonra ~ / .tcsh kurulum dosyamla kapacağım.
Ross Rogers

2
Bu cevabı gerçekten soruya cevap görünmüyor.
intuited

55

SendEnvSeçenek adam.

~ / .ssh / config: (yerel olarak)

SendEnv MYVAR

/ etc / ssh / sshd_config: (uzak uçta)

AcceptEnv MYVAR

Şimdi, $MYVARyerel olarak değer ne olursa olsun , uzak oturumda da kullanılabilir hale gelir.
Birden çok kez giriş yaparsanız, her oturumun $MYVARmuhtemelen farklı değerlere sahip bir kopyası olacaktır .

~/.ssh/environmentdiğer amaçlar için tasarlanmıştır. Kabuk olmayan komutları uzaktan $ENVçalıştırırken dosya görevi görür .


6
ayrıca komut satırından (daha kullanışlı şekilde) geçirilebilir ssh myserver -o SendEnv="MYVAR", böylece komut dosyalarında dinamik hale getirebilirsiniz.
Mike Campbell,

30

Değerleri aşağıdakine benzer bir komutla iletebilirsiniz:

ssh username@machine VAR=value cmd cmdargs

İle test edebilirsiniz:

ssh machine VAR=hello env

Tcsh'de aşağıdakiler çalışıyor gibi görünüyor:

ssh machine "setenv VAR <value>; printenv"

Bash ortamları için iyi çalışıyor gibi görünüyor. Çok kötü bir tcsh ortamındayım.
Ross Rogers

2
Oturumu etkileşimli olarak nasıl kullanabilirim?
luckydonald

1
İlk örneğin, birlikte komutları zincirleyecekseniz yalnızca ilk komut için çalıştığını unutmayın &&. Bash kullanmak export VAR=value;, üçüncü formda setenv yerine bu durum için çalışıyor.
contrebis

2
Yaptığım şey bu! Nereye giderseniz gidin, çevrenizi yanınıza alın. Sizin böyle yapabilirsiniz: ssh user@host "$(<env_to_source.sh) command ..." . Env kaynağında, export var=value ; ayrı satırlarım var (noktalı virgülleri hatırla).
Tomasz Gandor

@TomaszGandor: yıllar sonra, yine de mükemmel - PROMPT_COMMAND gibi karmaşık şeyleri bile geçmeme izin veriyor, :-) kaçma konusunda endişelenmenize gerek kalmadan.
Kırmızı Hap

29

Ayrıca korkunç, korkunç bir kesmek var.

Komut dosyanız uzak uçtaki değişkeni kullanıyorsa (örneğin, istediğiniz şekilde adlandırabilirsiniz), yerel değişkenleri kötüye kullanabilirsiniz. LC_ * biçimindeki herhangi bir değişken, herhangi bir yapılandırma gereksinimi olmadan sözlü olarak iletilir.

Örneğin, müşterilerimden birinde bir dizi temel sunucu var. Her seferinde başka bir sunucuya ... ve başka bir sunucuya bağlanmak için ... ... bağlanmak zorunda kalmaktan nefret ediyorum. Zekice olması dışında SSH gibi davranan bir senaryom var.

Temel olarak, eğer LC_BOUNCE_HOSTS ayarlanmışsa, onu uzaylara böler ve ilk ana bilgisayarı soyar. Daha sonra zıplar ve aynı betiği çalıştırır. Hedef düğümde, bu liste sonunda boştur, bu yüzden komutu çalıştırır. Ayrıca LC_BOUNCE_DEBUG tarafından ayarlanan bir hata ayıklama moduna (ağ sorunları sırasında harika olan) sahibim. Ssh tüm bunları benim için sihirli bir şekilde geçtiğinden, ana bilgisayar listesinin sonunu tanımaktan başka bir şey yapmak zorunda değilim (bir - seçeneğiyle yapıyorum).

Bunu her kullandığımda kendimi kirli hissediyorum, ama denediğim her yerde çalışıyor.


2
OpenSSH'nin yerleşik ProxyCommandseçeneği yerine neden böyle bir şey kullandınız ? Düzenleyin ~/.ssh/configve benzeri bir blok ekleyin Host *.example.com: ProxyCommand -ssh -W %h:%p bastionhostve bağlantılarınızı sizin için tünel etmesine izin verin.
Kirk Strauser

1
Tüneller için o kadar da kötü değil. Env değişkenleri için iki neden vardır: Birincisi, PermitUserEnvironment, sunucuda onları doğrudan iletecek şekilde yapılandırmak için yönetici erişimi gerektirir. Onları komut satırından geçmek, kaçmayı doğru yapmak için de çok zor. İki, çok sayıda burcun sıçraması gerekir, bu da biraz daha karmaşık hale gelir - özellikle kaynak ana bilgisayardan belirli bir hedef ana bilgisayara hangi yoldan gideceği belli olmadığı zaman. Söylemek daha kolay: "ssh bast1 bast2 nodeX nodeX - rm -rf /", bir dizi ssh-config dosyasında evrimleşen bir ana bilgisayar popülasyonunun yollarını sürdürmekten daha iyidir.
Jayson

İyi yakalama !! Çok güzel ve biraz kirli!
zw963

2
Bu korkunç. Bravo. Del
Pi Delport

1
Bu korkunç harika, teşekkürler! Ben kullandım bir daha korkunç güzel hack ! :)
lumbric

1
bla="MyEnvSelection=dcop"
ssh user@host "export $bla && ./runProg"

Bash ile test ettik:

$ echo '#!/bin/sh' > readEnv.sh
$ echo 'echo "MyEnv: "$MyEnvFromSSH' >> readEnv.sh

$ scp readEnv.sh user@host:~/
$ bla="MyEnvFromSSH=qwert"
$ ssh user@host "export $bla && ./readEnv.sh"
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.