Broadband Related > Router Monitoring Software
Can DSLstats use SSH instead of Telnet?
d2d4j:
Hi
I hope you don't mind, but just arrived back and having a quick read
Does ssh allow more then 1 connection to zylex
If not, there's no benefit sorry
Also, if wanting to use ssh to secure connection over telnet, then this is Internal network only (cannot see ssh been open to Internet on router), so mostly I cannot reason for this sorry
Lastly, it maybe most routers do not use ssh but perhaps could if ssh were to be installed
Sorry if I am wrong and willl look tommorow after a good sleep
Many thanks
John
roseway:
John, I don't think that there is any intention to use ssh for remote connections to the modem. As far as I understand, we're talking about local connections on port 22, which is supported on some modems but not others. If I try on my VMG8324-B10A (with firmware 6b1) this is what I get:
--- Code: ---eric@great-tit:~$ ssh admin@192.168.1.1
Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
eric@great-tit:~$
--- End code ---
So the protocol is supported, but I'm not there yet.
d2d4j:
Hi roseway
Many thanks, and apologies for not been clear sorry. I think sometimes my mind knows what I want to say and fills the gaps in from what I type sorry
I can see the use of ssh if it allows more then 1 connection (using same credentials), so is this possible
In terms of secure connection on local Lan, might be needed but I know ssh is secure, so have to use secure. However, if above is limited to 1 connection, then in my mind, may as well use telnet
I'm sorry, I do not use zylex so cannot test, just did not want you to waste time
I know our platforms are limited to single user ssh (where we allow), and must use sudo to gain root commands.
I hope that explains a little more of what I was trying to say sorry but I could be entirely wrong, so I apologise in advance
Many thanks
John
d2d4j:
Hi Roseway
I hope you do not mind, but below is a manual connection from command prompt on windows (openssh), which may help perhaps.
I have included a picture and text, so it is clearer.
A thought came to me though, could you not use a third party SSH like putty, and make a call to start in CLI, maybe easier (or bitvise for scripting)
I hope that helps a little but sorry of I am wrong or confusing issues for you sorry
Many thanks
John
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\*****>ssh nnn.co.uk -l root
root@nnn.co.uk's password:
Last login: Mon Aug 7 09:30:42 2017 from nnn.nnn.nnn.nnn
[root@nnn ~]# logout
Connection to nnn.co.uk closed.
C:\Users\*****>ssh
usage: ssh [-1246AaCfghkNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
[-D port] [-e escape_char] [-F configfile] [-i identity_file]
[-L port:host:hostport] [-l login_name] [-m mac_spec] [-o option]
[-p port] [-R port:host:hostport] [user@]hostname [command]
C:\Users\*****>
d2d4j:
Hi Roseway
Sorry, rereading I think I may have made a mistake, as you are using linux, not windows.
I could be entirely wrong sorry, but do you have openssl installed. If not, this could explain the failure sorry.
To try to help a little, please see a SSH from a linux to linux server, but I am sure you have this anyway sorry
Many thanks
John
Actually, you may have OpenSSL installed, but the old cipher maybe disabled in your version of OpenSSL (http://blog.ffelix.eti.br/ssh-no-matching-key-exchange-method-found-their-offer-diffie-hellman-group1-sha1/)
When a SSH client connects to a server, each side offers lists of connection parameters to the other. These are, with the corresponding ssh_config keyword:
•KexAlgorithms: the key exchange methods that are used to generate per-connection keys
•Ciphers: the ciphers to encrypt the connection
•MACs: the message authentication codes used to detect traffic modification
•PubkeyAcceptedKeyTypes: the public key algorithms that the server can use to authenticate itself to the client
•For a successful connection, there must be at least one mutually-supported choice for each parameter.
If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:
Unable to negotiate with legacyhost: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
In this case, the client and server were unable to agree on the key exchange algorithm. The server offered only a single method diffie-hellman-group1-sha1. OpenSSH supports this method, but does not enable it by default because is weak and within theoretical range of the so-called Logjam attack.
The best resolution for these failures is to upgrade the software at the other end. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. In some cases, this might not be immediately possible so you may need to temporarily re-enable the weak algorithms to retain access.
For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithms option - either on the command-line:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@legacyhost
or in the ~/.ssh/config file:
Host somehost.example.org
KexAlgorithms +diffie-hellman-group1-sha1
The ‘+’ before the list instructs ssh to append the algorithm to the client’s default set rather than replacing the default. By appending, you will automatically upgrade to the best supported algorithm when the server starts supporting it.
Another example, this time where the client and server fail to agree on a public key algorithm for host authentication:
Unable to negotiate with legacyhost: no matching host key type found. Their offer: ssh-dss
OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. It can be re-enabled using the HostKeyAlgorithms configuration option:
ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost
or in the ~/.ssh/config file:
Host somehost.example.org
HostKeyAlgorithms +ssh-dss
Depending on the server configuration, it’s possible for other connection parameters to fail to negotiate. You might find the Ciphers and/or MACs configuration options useful for enabling these. It’s also possible to query which algorithms ssh supports:
ssh -Q cipher # List supported ciphers
ssh -Q mac # List supported MACs
ssh -Q key # List supported public key types
ssh -Q kex # List supported key exchange algorithms
Finally, it’s also possible to query the configuration that ssh is actually using when attempting to connect to a specific host, by using the -G option:
ssh -G user@somehost.example.com
which will list all the configuration options, including the chosen values for the Ciphers, MACs, HostKeyAlgorithms and KexAlgorithms parameters.
Last login: Mon Aug 7 09:34:43 2017 from nnn.nnn.nnn.nnn
[root@nnn ~]# ssh external.ssh.server
The authenticity of host 'external.ssh.server (nnn.nnn.nnn.nnn)' can't be established.
RSA key fingerprint is 57:vv:vv:vv:vv:vv:vv:vv:vv:vv:vv:vv:vv:vv:vv:vv.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'external.ssh.server,nnn.nnn.nnn.nnn' (RSA) to the list of known hosts.
reverse mapping checking getaddrinfo for . [nnn.nnn.nnn.nnn] failed - POSSIBLE BREAK-IN ATTEMPT!
root@external.ssh.server's password:
Last login: Thu Jul 27 09:19:27 2017 from hostnnn-nnn-nnn-nnn.in-addr.btopenworld.com
[root@444 ~]# logout
Connection to external.ssh.server closed.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version