NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Looking for thought on SSH performance on RN systems
Having issues with SSH connections on all the ReadyNAS systems running 6.10.10. The problem is all the connection stages take close to 2 minutes to complete. It's insane and I can't figure out why. ...
Thanks StephenB, good thinking on the disk spin down and while it's enabled it's not a factor. AFAIK the ssh client (always running in the background) doesn't need disk access and is just like any other background task. I confirmed the device doesn't spin up the drive on ssh connect until you start interacting with the OS.
I tried your test and found the exact same response both times, nearly 3 minutes with connect, disconnect, connect:
C:\Users\iceweasel>ssh root@192.168.1.200
root@192.168.1.200's password:
Welcome to ReadyNASOS 6.10.10
Last login: Fri Sep 6 14:27:30 2024 from readynas-204
root@ReadyNAS-204:~# exit
logout
Connection to 192.168.1.200 closed.
C:\Users\iceweasel>ssh root@192.168.1.200
root@192.168.1.200's password:
Welcome to ReadyNASOS 6.10.10
Last login: Sat Sep 7 10:19:10 2024 from thefactory
root@ReadyNAS-204:~# exit
logout
Connection to 192.168.1.200 closed.
C:\Users\iceweasel>ssh root@192.168.1.200
root@192.168.1.200's password:
Welcome to ReadyNASOS 6.10.10
Last login: Sat Sep 7 10:21:51 2024 from thefactory
root@ReadyNAS-204:~# exit
logout
Connection to 192.168.1.200 closed.
C:\Users\iceweasel>
You may have noticed the first connect message shows the prior connect from the readynas itself. I had been doing testing with tunneling with paramiko to work around the slow connect. But that got me thinking...what if I ssh from the RN to the RN?
If from an active ssh session on the RN I ssh at the LAN address I get the same results
If I try again but accessing with localhost (127.0.0.1) the connection process is nearly instant. Which would suggest there's something on the LAN interfering? I'm not sure of that but may need to try a direct connect PC->RN and see if things go faster but that will take some work and I'm hoping there may be something else easier than reconfiguring the NAS for a test.
I also checked that only the required system tools are enabled in the web interface.
There's an interesting tangent problem I need to address with uninstalling some old apps, but none of those are running there're just taking up disk space and the UI remove fails. But I'll save that until this gets resolved.
FWIW,I see the banner in a second or so on my RN102 after I enter the password.
So this could be something on your network (perhaps internet security software???).
Thanks again StephenB. I did a bit more testing and found some interesting things...
first I was not too sure my PC wasn't a problem so I did some things to clear up some of the "questionable" networks stuff... removed npcap, unistalled wireshark, etc.
I found the password to banner did speed up which I found very odd as there's really nothing on the client side that should be affecting that. But the initial password challenge of 16 to display "password:" challenge was not acceptable.
So I dug a little deeper and looked at the ssh -vvv details a little closer. I found there was a 16 second (or so) timeout from when the client sends an authentication packet to when the server responds with the password challenge. The debug was helpful.
Looking online I see a common issue with this is a default setting to use DNS for something in this process which... doesn't make much sense unless some CA or other 3rd party is involved.... so I followed the advice of others and ignored the note at the top of the /etc/ssh/sshd_config and added this::
UseDNS no
I now get the password challenge immediately!!
One note on my setup, is my NAS devices are internal only so they couldn't reach an external NAS if they had to. I didn't run any tests to see if exposing them to the WAN would change the behavior, but for the knowledge of the greater good I may do that when I have a few minutes to spare.Thanks for the suggestions and nudges in the right direction to find and remedy this problem!!
In the interest of discovery... confirmed, if the NAS can access the WAN (DNS really) the "UseDNS no" is not needed.
If the ReadyNAS systems are behind a firewall and only available to the LAN then yes, the "UseDNS no" makes a big difference in the authentication timing.
iceweasel wrote:
In the interest of discovery... confirmed, if the NAS can access the WAN (DNS really) the "UseDNS no" is not needed.
If the ReadyNAS systems are behind a firewall and only available to the LAN then yes, the "UseDNS no" makes a big difference in the authentication timing.
My own NAS are behind a NAT router, so they can connect to the internet, but not be reached over the internet. As I posted above, I am not seeing the authenication LAG that you were seeing before you made this change.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
