• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

SSH / Telnet on Webif settings

Seems to be a problem using keys, probably my error as I've never done this before...

1, Used PuttyGen to create new keys, created a 1024 bit dsa key
2, copied the public key from puttygen to /mod/.ssh/authorized_keys
3, tried to log in from putty after using the private key via the 'auth' section of putty

Get an error about 'server refused our key', same problem with an rsa key.
 
It's most likely a problem with the permissions, try this from the telnet CLI:

Code: 
humax# chmod 700 /mod/.ssh
humax# chmod 600 /mod/.ssh/authorized_keys
 
af123 said:
The dropbear-ssh package provides SSH access to the box and adds an option to disable the default telnet server to the settings page. It was requested at some point but most people probably don't use it. As xyz321 says, it can complicate recovery, although there are some things built-in to help if anyone gets into that situation.
Click to expand...
It would seem to me to be a sensible mod. to force enable the Telnet server in maintenance mode i.e. ignore /var/lib/humaxtv/notelnet for those people who have set SSH only. One for 2.20 perhaps?
 
There is an additional telnet server available on port 24 in maintenance mode which is unaffected by the notelnet flag.
 
OK, is that documented anywhere (apart from here now!)?
Seems a bit odd though. Why not just enable it on 23?
 
We seem to have wandered off the original fault report. When one visits http://humax/cgi-bin/settings.jim, the "Disable telnet server ?" option is always "NO" or unchecked (assuming that one does have the dropbear-ssh package installed).
Looks like there's no code to change the dropbear_disable_telnet variable from its initial value of no. So, despite having touched both /mod/boot/notelnet and /var/lib/humaxtv/mod/notelnet and there being no telnet daemon running, the web interface doesn't reflect the running configuration.

Oh, and while we're at it, why isn't etc/dropbear/_config marked in the Debian control area of the package as a conffile ? It's user configuration, just like etc/dropbear/passwd and etc/dropbear/shadow (which are declared as conffiles) and updating the package shouldn't overwrite user configuration.
 
You must log in or register to reply here.
Back
Top