LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   logging in using ssh via external ip (https://www.linuxquestions.org/questions/linux-server-73/logging-in-using-ssh-via-external-ip-4175632616/)

theoriginaltoad 06-25-2018 04:50 AM

logging in using ssh via external ip
 
I've setup port 22 forwarding on my router, installed openssh-server and copied over my keys etc to my Asus eeebox pc (with user toady) i have set this up as my file server. I can ssh on my local network via my linux mint laptop (user kabuki) and it logs me in without fuss! But..
If I try to log in using my public ip, either locally on my laptop or at my workplace, it gives me grief about the insecure sha1 diffie-hellman thing and ciphers etc, so i type this line:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -vvv toady@101.xxx.xxx.xxx

At which point, It seems to get a bit further but stops me with a password entry.
However, Despite entering the password for the toady login, it doesn't let me in.

Here is the output of my console:

kabuki@kabuki-eME644 ~ $ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -vvv toady@101.xxx.xxx.xxx
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "101.xxx.xxx.xxx" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 101.xxx.xxx.xxx [101.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/kabuki/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kabuki/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kabuki/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kabuki/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kabuki/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kabuki/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kabuki/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/kabuki/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version dropbear_0.46
debug1: no match: dropbear_0.46
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 101.xxx.xxx.xxx:22 as 'toady'
debug3: hostkeys_foreach: reading file "/home/kabuki/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/kabuki/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 101.xxx.xxx.xxx
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: ssh-rsa-cert-v01@openssh.com,rsa-sha...01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: 3des-cbc
debug2: ciphers stoc: 3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm...28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm...28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: 3des-cbc
debug2: ciphers stoc: 3des-cbc
debug2: MACs ctos: hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha1,hmac-md5
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: diffie-hellman-group1-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: 3des-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: 3des-cbc MAC: hmac-sha1 compression: none
debug1: sending SSH2_MSG_KEXDH_INIT
debug2: bits set: 515/1024
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:ZwXvvqj4c4qxW5Ko8GL+d2uCCWt4CE1LGyZx3zlzTcM
debug3: hostkeys_foreach: reading file "/home/kabuki/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/kabuki/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 101.xxx.xxx.xxx
debug1: Host '101.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/kabuki/.ssh/known_hosts:1
debug2: bits set: 490/1024
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/kabuki/.ssh/id_rsa (0x55b224796260)
debug2: key: /home/kabuki/.ssh/id_dsa ((nil))
debug2: key: /home/kabuki/.ssh/id_ecdsa ((nil))
debug2: key: /home/kabuki/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kabuki/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/kabuki/.ssh/id_dsa
debug3: no such identity: /home/kabuki/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/kabuki/.ssh/id_ecdsa
debug3: no such identity: /home/kabuki/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/kabuki/.ssh/id_ed25519
debug3: no such identity: /home/kabuki/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
toady@101.xxx.xxx.xxx's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
toady@101.xxx.xxx.xxx's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
toady@101.xxx.xxx.xxx's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password).
kabuki@kabuki-eME644 ~ $


My eeebox sshd_config looks like this (minus some commenting):

----
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
Banner /etc/issue.net
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM no
AllowUsers toady kabuki

-----

Do I need to modify anything in the client (kabuki) ssh_config?
Is there anything in sshd_config or router page that could be at fault?

Your help would be greatly appreciated!

Turbocapitalist 06-25-2018 04:55 AM

Quote:

Originally Posted by theoriginaltoad (Post 5871650)
If I try to log in using my public ip, either locally on my laptop or at my workplace, it gives me grief about the insecure sha1 diffie-hellman thing and ciphers etc ...

As well it should and so do we.

What version of OpenSSH-server are you runnning on the box you are connecting to? And which distro, including version, is there?

ondoho 06-25-2018 06:05 PM

you make using ssh keys sound very difficult indeed.
is there a reason for this?
there's more than a handful of concise tutorials on how to do it, i usually recommend this one:
https://wiki.archlinux.org/index.php/SSH_keys

jlinkels 06-25-2018 07:01 PM

I think you should try and try the simple case first. The simple case is that you generate one keypair as user foo.

Copy the pubkey to the ssh server. Add it to /home/foo/.ssh/known_hosts. On you client, be user foo when you try to connect. Do not use any additional parameter.

It is possible to be user bar on the client and user foo on the server, but it is more complicated.

The reason that you can connect on the local network and can not connect over the internet seems not to be an internet problem, but something unknown which happens on your local network which allows authentication where it should not. If port 22 is properly forwarded there can be no difference where the connection is coming from.

And use a standard sshd_config first. Change only to allow key authentication if it is not set.

Then, step by step add customization and test after each step. You will find the one which causes the failure. It is basic debugging.

jlinkels

theoriginaltoad 06-26-2018 12:03 AM

linux and ssh versions
 
Quote:

Originally Posted by Turbocapitalist (Post 5871651)
What version of OpenSSH-server are you runnning on the box you are connecting to? And which distro, including version, is there?

Eeebox PC toady is as follows..

1. uname -a gives:
Linux toady-EB1007 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:30:51 UTC 2017 i686 i686 i686 GNU/Linux

2. cat /proc/version gives:
Linux version 4.10.0-38-generic (buildd@lgw01-amd64-020) (gcc version 5.4.0 20160609 (Ubuntu5.4.0-6ubuntu1~16.04.4) ) #42~16.04.1-Ubuntu SMP Tue Oct 10 16:30:51 UTC 2017

3. uname -m gives:
i686

4. ssh -V gives:
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016


For my laptop:
1. Linux kabuki-eME644 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
2. Linux version 4.10.0-38-generic (buildd@lgw01-amd64-059) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) )
3. #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017
4. OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016

Thankyou.

theoriginaltoad 06-26-2018 12:25 AM

login parameters
 
Quote:

Originally Posted by ondoho (Post 5871907)
you make using ssh keys sound very difficult indeed.

Indeed, it is difficult. I'm not complicating the command line parameters just for fun, that's for sure!

Quote:

is there a reason for this?
The reason I use the following line:
"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -vvv toady@101.xxx.xxx.xxx"

is because when I tried "ssh toady@101.xxx.xxx.xxx", i receive the message:
"Unable to negotiate with 101.xxx.xxx.xxx port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1"

So after some research I tried the line:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 toady@101.xxx.xxx.xxx

and i receive:
Connection closed by 101.xxx.xxx.xxx port 22

so i researched a little more and added in:
"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc toady@101.xxx.xxx.xxx"

it seems i get a little further 'into-the-system' i guess and i receive:
toady@101.xxx.xxx.xxx's password:

Even though, there was no password required when logging in locally on my network. There was also no key phrase set either.
Note that all I have to do to log in locally is "ssh toady@192.168.1.7" and bam, i'm in like flynn.

The lines mentioned above are what im told is a supposed workaround to log in using the insecure diffie-hellman method. Ultimately it would be great to not write that into the console in order to login, but if I could just test that logging in works using my public ip i would be very pleased.

Thankyou.

theoriginaltoad 06-26-2018 12:36 AM

Quote:

Originally Posted by jlinkels (Post 5871925)
I think you should try and try the simple case first. The simple case is that you generate one keypair as user foo.

Copy the pubkey to the ssh server. Add it to /home/foo/.ssh/known_hosts. On you client, be user foo when you try to connect. Do not use any additional parameter.

It is possible to be user bar on the client and user foo on the server, but it is more complicated.

The reason that you can connect on the local network and can not connect over the internet seems not to be an internet problem, but something unknown which happens on your local network which allows authentication where it should not. If port 22 is properly forwarded there can be no difference where the connection is coming from.

And use a standard sshd_config first. Change only to allow key authentication if it is not set.

Then, step by step add customization and test after each step. You will find the one which causes the failure. It is basic debugging.

jlinkels

Ok will try these out and reply soon. Cheers :)

Turbocapitalist 06-26-2018 12:40 AM

Quote:

Originally Posted by theoriginaltoad (Post 5871991)
Eeebox PC toady is as follows..
[...]
4. ssh -V gives:
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016


For my laptop:
[...]
4. OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016

Thanks. Those are both reasonably new. Neither of them should downgrade to 3DES or any of the other deprecated ciphers. Can you show the distro and version for both the Eeebox PC and the laptop?

Code:

lsb_release -rd

theoriginaltoad 06-26-2018 01:21 AM

distro versions
 
Quote:

Originally Posted by Turbocapitalist (Post 5872004)
Thanks. Those are both reasonably new. Neither of them should downgrade to 3DES or any of the other deprecated ciphers. Can you show the distro and version for both the Eeebox PC and the laptop?

Code:

lsb_release -rd

Ok, using "lsb_release -rd"

Laptop i get:

Description: Linux Mint 18.3 Sylvia
Release: 18.3

Eeebox i get:

Description: Linux Mint 18.3 Sylvia
Release: 18.3

both are KDE desktops.

theoriginaltoad 06-26-2018 03:47 AM

known hosts.
 
Quote:

Originally Posted by jlinkels (Post 5871925)
I think you should try and try the simple case first. The simple case is that you generate one keypair as user foo.

Copy the pubkey to the ssh server. Add it to /home/foo/.ssh/known_hosts. On you client, be user foo when you try to connect. Do not use any additional parameter.

It is possible to be user bar on the client and user foo on the server, but it is more complicated.

The reason that you can connect on the local network and can not connect over the internet seems not to be an internet problem, but something unknown which happens on your local network which allows authentication where it should not. If port 22 is properly forwarded there can be no difference where the connection is coming from.

And use a standard sshd_config first. Change only to allow key authentication if it is not set.

Then, step by step add customization and test after each step. You will find the one which causes the failure. It is basic debugging.

jlinkels

Ok i'm a bit confused ..

Do you mean I create a user called 'foo' on my client machine and create a keypair. I then create another user on the host machine, also called foo. I copy the pubkey generated for user 'foo' on the client machine to the other user 'foo' on the host machine,
Then I add the pubkey to /home/foo/.ssh/known_hosts on the host machine, and log in e.g "foo@kabuki-eME644 ~ $ ssh foo@192.168.1.7" ?

Quote:

It is possible to be user bar on the client and user foo on the server, but it is more complicated.
From this I gather that you mean there ideally should be a 'foo' user on the client that ssh's in as the 'foo' user on the host machine, no? again e.g foo@kabuki-eME644 ~ $ ssh foo@192.168.1.7 ?

In other words, the host machine should be expecting a client user 'foo' to ssh in only if there's a 'foo' user account on the host?

Sorry about this confusion lol.

jlinkels 06-26-2018 04:27 AM

Quote:

Originally Posted by theoriginaltoad (Post 5872046)
In other words, the host machine should be expecting a client user 'foo' to ssh in only if there's a 'foo' user account on the host?
Sorry about this confusion lol.

Yes.

After all it is foo who is logged in on his local machine. And he wants to log in as foo on the remote machine. Why would foo want to become bar on the remote machine?

jlinkels

michaelk 06-26-2018 06:52 AM

Quote:

debug1: Remote protocol version 2.0, remote software version dropbear_0.46
debug1: no match: dropbear_0.46
Are you positive that your using the correct public IP address? It looks like your trying to login to your router and not the server. What is the make/model of your router? Is it possible that you have a ssh server running on port 22 of the router and regardless of forwarding port 22 you are trying to login to it and not the intended server?

ondoho 06-26-2018 04:42 PM

Quote:

Originally Posted by theoriginaltoad (Post 5871996)
Indeed, it is difficult. I'm not complicating the command line parameters just for fun, that's for sure!



The reason I use the following line:
"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -vvv toady@101.xxx.xxx.xxx"

is because when I tried "ssh toady@101.xxx.xxx.xxx", i receive the message:
"Unable to negotiate with 101.xxx.xxx.xxx port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1"

So after some research I tried the line:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 toady@101.xxx.xxx.xxx

and i receive:
Connection closed by 101.xxx.xxx.xxx port 22

so i researched a little more and added in:
"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc toady@101.xxx.xxx.xxx"

it seems i get a little further 'into-the-system' i guess and i receive:
toady@101.xxx.xxx.xxx's password:

Even though, there was no password required when logging in locally on my network. There was also no key phrase set either.
Note that all I have to do to log in locally is "ssh toady@192.168.1.7" and bam, i'm in like flynn.

The lines mentioned above are what im told is a supposed workaround to log in using the insecure diffie-hellman method. Ultimately it would be great to not write that into the console in order to login, but if I could just test that logging in works using my public ip i would be very pleased.

Thankyou.

my, oh my.

all that for a simple ssh connection from machine a to machine b.

i think you got lost in the woods, probably when ssh suggested some diffie-hellman although the problem & solution is much simpler than changing algorithms.

you should go back to start, try to forget what you did so far, get yourself a good tutorial, and try again.

Turbocapitalist 06-26-2018 10:10 PM

Quote:

Originally Posted by ondoho (Post 5872274)
you should go back to start, try to forget what you did so far, get yourself a good tutorial, and try again.

I agree with this advice. I suspect that you are seeing the connection to Dropbear or something on your router rather than OpenSSH on your other computer. You can look in ~/.ssh/known_hosts and compare the keys for both login destinations. If the keys do not match then you need to fix the port forwarding. The utility ssh-keygen might help, especially if the hostnames are hashed.

Code:

ssh-keygen -F 192.168.1.7 -l -f ~/.ssh/known_hosts
ssh-keygen -F 101.xx.xx.xx -l -f ~/.ssh/known_hosts

PS. If your router is using those ciphers, other things are probably also out of date and it really, really should be updated.

theoriginaltoad 06-28-2018 03:12 AM

Solved! It's the routers on-board SSH server in the way!
 
Quote:

Originally Posted by michaelk (Post 5872075)
Are you positive that your using the correct public IP address? It looks like your trying to login to your router and not the server. What is the make/model of your router? Is it possible that you have a ssh server running on port 22 of the router and regardless of forwarding port 22 you are trying to login to it and not the intended server?

Quote:

Originally Posted by Turbocapitalist (Post 5872364)
I suspect that you are seeing the connection to Dropbear or something on your router rather than OpenSSH on your other computer.

Quote:

Originally Posted by Turbocapitalist (Post 5872364)
PS. If your router is using those ciphers, other things are probably also out of date and it really, really should be updated.

haha Thanks MichaelK and Turbocapitalist, that was it! It's the router in the way with its own ssh server and as you said, out of date ciphers. Before testing your code I just tried the router 'admin' as login:

"ssh admin@101.xxx.xxx.xxx"

and was denied for the diffie-hellman issue. Then I tried

"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -vvv admin@101.xxx.xxx.xxx"

and put in my router password, and i logged right in! I'll see if I can find software/firmware upgrades for it.

Btw I called the Slingshot ISP 'tech support' earlier today. The fella said he had never heard of SSH :foot: ..and that all Slingshot-NetComm NF4V routers were 'locked' down to some sort of basic internet-only features. But this is not the case..

I've since disabled the existing dropbear ssh server in the router and forwarded port 2222, I can now login successfully to my Openssh 7.2 server using my public ip and without having to try the deprecated diffie-hellman+old cipher workaround!

Thank you for your patience and detailed info, Turbocapitalist, MichaelK and jlinkels et al!

Also, the router info is as follows:

Manufacturer: NetComm Wireless
Product Class: NF4V
Software Version: NF4V_Slingshot-R5B024.EN
Bootloader (CFE) Version: 1.0.38-114.170
DSL PHY and Driver Version: A2pv6F039k.d25b
VDSL PROFILE: 17a
Wireless Driver Version: 6.30.163.23.cpe4.12L
Voice Service Version: V2.4

I will post screenshots of the router config for others and try to create a step by step guide to getting around this problem using our convos.

theoriginaltoad


All times are GMT -5. The time now is 08:42 PM.