autossh w tle nie działa

12

Założyłem tunel za pośrednictwem autossh.

To działa:

autossh -M 33201 -N -i myIdFile -R 33101:localhost:22 [email protected]

Chciałbym uruchomić autossh w tle. Wydaje się łatwe przy użyciu tej -fopcji.

Nie działa to jednak:

autossh -f -M 33201 -N -i myIdFile -R 33101:localhost:22 [email protected]

Autossh działa poprawnie w tle, ale połączenie ssh wydaje się nie działać za każdym razem. W / var / syslog widzę wiele razy:

autossh[3420]: ssh exited with error status 255; restarting ssh

Co ja robię źle? Powszechnie wiadomo, że ma to związek z uwierzytelnianiem za pomocą pliku klucza. Jak mogę to debugować (dodanie opcji -v do opcji ssh nigdzie się nie loguje).

Edycja: Mam dzienniki ssh przy użyciu opcji -y

/usr/bin/ssh[3484]: debug1: Next authentication method: publickey
/usr/bin/ssh[3484]: debug1: Trying private key: /home/myuser/.ssh/id_rsa
/usr/bin/ssh[3484]: debug1: Trying private key: /home/myuser/.ssh/id_dsa
/usr/bin/ssh[3484]: debug1: Trying private key: /home/myuser/.ssh/id_ecdsa
/usr/bin/ssh[3484]: debug1: No more authentication methods to try.
/usr/bin/ssh[3484]: fatal: Permission denied (publickey).
autossh[3469]: ssh exited with error status 255; restarting ssh

Wygląda więc na to, że autossh nie akceptuje mojego pliku tożsamości ( -i myIdFile) przy użyciu opcji -f. Dlaczego?

(autossh 1.4c na Raspian)

henning77
źródło
Po co w ogóle korzystać z autossh? Możesz użyć systemd do „restartu po awarii”. Stworzyłem istotę z moim rozwiązaniem: gist.github.com/guettli/…
guettli

Odpowiedzi:

29

Wygląda na to, że gdy autossh spada do tła (opcja -f), zmienia katalog roboczy, co oznacza, że ​​ścieżki względne już nie działają. Lub bardziej konkretnie: wpisując bezwzględną ścieżkę pliku identyfikatora prawdopodobnie odniesiesz sukces.

Ponownie utworzyłem scenariusz, tworząc klucz bez hasła w lokalizacji innej niż domyślna:

~/$ mkdir test
~/$ cd test
~/test$ ssh-keygen -f test_id_rsa

Po prostu nacisnąłem Enter dwa razy, aby wygenerować klucz, który nie jest chroniony hasłem.

Skopiowałem nowy klucz na mój serwer (który umożliwia obecnie uwierzytelnianie za pomocą hasła):

~/test$ ssh-copy-id -i test_id_rsa user@server

Najpierw potwierdziłem, że klucz działa z normalnym ssh, a następnie za pomocą autossh takiego jak ty:

~/test$ ssh -i test_id_rsa user@server
~/test$ autossh -M 13000 -N -i test_id_rsa user@server
^C

Oba działały dobrze, więc odtworzyłem problem, który miałeś:

~/test$ autossh -f -M 13000 -N -i test_id_rsa user@server

To nie zadziałało i napisano do /var/log/syslog:

autossh [2406]: ssh zakończył pracę przedwcześnie ze statusem 255; automatyczne opuszczanie

Zmieniając ścieżkę pliku kluczy na wartość bezwzględną, zadziałało:

~/test$ autossh -f -M 13000 -N -i /home/user/test/test_id_rsa user@server

Brak błędów w /var/log/syslog.

jmidgren
źródło
super, to działa.
henning77
Uratowałeś mi dzień!
arno_v
2
Opcja -N jest ważna, w przeciwnym razie uzyskasz „ssh zakończony ze statusem 0; autossh exit”. Dzięki!
user30747,
Potwierdzono, że ja też musiałem dodać ścieżkę do pliku „id_rsa” w następujący sposób: autossh -M 19001 -fN -y -i /home/pi/.ssh/id_rsa (dzięki @jmidgren)
Rich
4

Nie jestem pewien, co się dzieje z opcją -f, ale możesz też tego nie robić:

nohup autossh -M 33201 -N -f -i myIdFile -R 33101:localhost:22 [email protected] &
Brian P.
źródło
nohup działa dla mnie, nawet bez określania pliku klucza.
valadil
nohuppracował także dla systemu autosshpod runitAlpine Linux
Stuart Cardall
0

Dodaj następujące parametry do SSH, aby ominąć „Czy na pewno chcesz kontynuować łączenie (tak / nie)?”

-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

Ostateczne polecenie będzie miało następujący format:

autossh -f -M $BASE_PORT -N -R $LOCAL_PORT:$LOCALHOST:$REMOTE_PORT $USER@$SERVER -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
Vahid-Dan
źródło
mi to pasuje.
bluebird_lboro,
Nie włączaj, StrictHostKeyChecking=nochyba że łączysz się ze znaną dobrą efemeryczną zabawką - i wybierasz leniwość.
Dolph