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
 
Perfect! Many thanks.

I found the first chmod 700 from an earlier thread, but adding the second has done the trick.
 
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.
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.
 
Back
Top