Dlaczego polecenie `cd` nie działa przez SSH?

Próbowałem wykonać kopię zapasową niektórych plików przez SSH, ale zamiast tartych, które chciałem, dostałem swój folder domowy. Zrobiłem kilka dalszych testów i sprowadza się to do tego:

ssh root@server /bin/sh -c "cd /boot && ls -l"

Który do moich plików list niespodzianka w /rootnie /boot. Ale jeśli uruchomię całe /bin/shpolecenie z terminala, to odpowiednio cds wydrukuje /bootpliki.

Co tu się dzieje?

ssh nie pozwala ci precyzyjnie określić polecenia, tak jak to zrobiłeś, jako serii argumentów, które mają zostać przekazane do execvp na zdalnym hoście. Zamiast tego łączy wszystkie argumenty w ciąg i przepuszcza je przez zdalną powłokę. Moim zdaniem wyróżnia się to jako poważna wada projektowa ssh ... jest to dobrze zachowujące się narzędzie unixowe pod wieloma względami, ale kiedy przychodzi czas na określenie polecenia, wybrał użycie pojedynczego monolitycznego łańcucha zamiast argumentu argv, jak został zaprojektowany dla MSDOS lub coś takiego!

Ponieważ ssh przekaże twoje polecenie jako pojedynczy ciąg sh -c, nie musisz podawać własnego sh -c. Kiedy to zrobisz, wynik będzie

sh -c '/bin/sh -c cd /boot && ls -l'

z oryginalnym cytatem utraconym. Tak więc polecenia rozdzielone przez &&:

`/bin/sh -c cd /boot`
`ls -l`

Pierwszy z nich uruchamia powłokę z tekstem polecenia „cd” i $0= "boot". Polecenie „cd” zakończyło się pomyślnie, nie $0ma znaczenia, a /bin/sh -coznacza sukces, a potem się ls -ldzieje.

To kwestia cytowania. Ssh już uruchamia polecenie, które przekazujesz w powłoce. Po przekazaniu wielu parametrów są one łączone ze spacją między nimi, aby utworzyć ciąg. Tak więc zdalne polecenie uruchamiane zdalnie to /bin/sh -c cd /boot && ls -l(bez cudzysłowów, ponieważ cudzysłowy w twoim poleceniu zostały zinterpretowane przez lokalną powłokę).

/bin/sh -c cd /booturuchamia się /bin/shi każe mu uruchomić polecenie, cda także ustawić $0na /boot. Po wykonaniu tej czynności uruchomiona jest powłoka nadrzędna (ta uruchomiona przez sshd) ls -l.

W twoim przypadku po prostu usuń ten, sh -cktóry jest całkowicie bezużyteczny, chyba że zdalna powłoka (jak wskazano w /etc/passwdlub w innej bazie danych haseł) nie zrozumie tego polecenia.

ssh root@server "cd /boot && ls -l"

Jeśli potrzebujesz wywołać inną powłokę, musisz zacytować komendę zdalną, aby chronić ją przed rozszerzeniem przez zdalną powłokę wywoływaną przez sshd. Na przykład, jeśli twoja powłoka logowania to myślnik i chcesz uruchomić polecenie bash:

ssh root@server 'bash -c "cd ~bob && ls -l"'

Myślę, że ma to więcej wspólnego z tym, jak opcje są analizowane przez powłokę. Na przykład to działa:

$ ssh root@server /bin/sh -c '"cd /boot && ls -l"'

Ma to ten sam problem, co twoje polecenie:

$ ssh root@server /bin/sh -c 'cd /boot && ls -l'

Jeśli włączysz -vprzełącznik ssh, możesz zobaczyć, co się dzieje:

1. polecenie:

debug1: Wysyłanie polecenia: / bin / sh -c "cd / boot && ls -l"

2. polecenie:

debug1: Wysyłanie polecenia: / bin / sh -c cd / boot && ls -l

Zazwyczaj wysyłając polecenia za pośrednictwem ssh, należy zwrócić szczególną uwagę na cytowanie i zawijać cytaty w cudzysłowy, gdy różne warstwy je usuwają. Również nie zawracaj sobie głowy wysyłaniem /bin/sh.

Możesz zrobić bardzo przydatną rzecz, gdy zrozumiesz cytowanie sshtakich jak następujące. Spowoduje to uruchomienie polecenia na zdalnym serwerze, ale zebranie wyników w pliku lokalnie w systemie, w którym uruchomiono sshpolecenie:

$ ssh root@server 'free -m' > /tmp/memory.status

lub to, gdzie zapisujesz katalog na zdalnym serwerze i tworzysz go w systemie lokalnym:

$ ssh remotehost 'tar zcvf - SOURCEDIR' | cat > DESTFILE.tar.gz

Referencje

• Pchanie i ciągnięcie plików za pomocą tar, ssh, scp i rsync

Zazwyczaj nie musisz określać, jakiej powłoki użyć. To działa:

ssh user@host "cd /boot && pwd"

Ale jeśli twoja domyślna powłoka jest problematyczna, upewnij się, że zacytowałeś całe polecenie, w tym wywołanie powłoki. Każda z poniższych prac

ssh user@host '/bin/sh -c "cd /boot && pwd"'
ssh user@host "/bin/sh -c \"cd /boot && pwd\""