New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSH proxy failed backup until disconnect/timeout #3114
Comments
As I neither use Mikrotik nor ssh proxy, it's quite difficult form me to help. From your description, if the ssh session never ends, the oxidized/lib/oxidized/model/routeros.rb Line 61 in c79826a
How do you logout when using a proxy? Do you have to enter something else as just |
Hi, The pre_logout command seems to be good for exit classic and proxy connections. When I log on to the docker and I testing this : The simple 'quit' disconnects client and proxy and sends me back to the oxidized bash terminal. In parallel, I've tried adding a 2sd quit to the model, but this doesn't solve the problem : |
I've added the logs if that helps. Ssh_proxy is '192.168.99.35' and routerOS is '10.20.0.10' (APSiegeLABviaProxy).
When I force disconnect :
|
To make this work temporarily, I've set up a script that disconnects my SSH user 'oxidized' on the end device every hour. |
Hello,
First thanks for you job.
I've a problem with backing up a Mikrotik router via ssh proxy, ok with direct ssh access.
I use docker with last version of oxidized (0.29.1-207-gea40b51), I generated an rsa key to the oxidized user, and added the mapping for the ssh proxy which works fine (I see ssh session on first equipement for proxy and on the final router) but the connection (forward then ssh on the router) never ends (so no backup even when I change the router configuration).
But when I force the closure of this session (the proxy part or the ssh client part), or when I reboot the router, the backup is carried out correctly (with data).
On the web interface of the routerOS, when I close client ssh, I see the backup performed correctly, but average run time is necessarily very long, since it depends on the time I took to close the connection (1195.83s for example in my last test).
From what I understand, the session doesn't close properly at the end of the information retrieval command, so the backup never takes place.
Thanks for your help.
The text was updated successfully, but these errors were encountered: