SMH... I just moved and pulled out my router after ~6 months of not messing with it and it seems I have deleated my enitre U/N P/W file for a few of my devices... Anyway had SSH working before (did the whole dropbear thing) and trying to go thru the backdoor (Telnet) to try get in but that is asking for a password as well.
=== LOGIN ===============================
Please enter your password,It's the same
with DUT login password
------------------------------------------
I still have web access to the router but aside from that I'm boxed out.
Any suggestions to get around/in or do I just need to reset? I supose insults are welcome/deserved as well.
Ohh, and I'm running voxels lastest firmware V1.0.2.54SF
So I figured out my old password to get in through telnet but still cannot figure out my username to ssh in for the life of me.. Any idea where it could be hiding?
Funnily... Well, sometimes it happens. SSH username is just "root". SSH to "[email protected]".
Voxel.
Voxel,
... It's offical, I'm brain dead! Well, ssh is working fine when on the network, however I am having issues trying to remotely SSH into the router. I have created a netwall.conf that does open up port 22, and I am using a static IP address (not the routers 192.168.xx.xx). Any suggestions? I supposed the other option would be to set up openvpn, however I would think ssh would be just as secutre if I am using dropbear keys.
Also, if I wanted to install nano text editor I am assuming the best way to do it would be to install debain-jessie and then pull it in through a repo? If so is there a repo or repo manager you would recomend?
Thanks as always,
- Stavi
Make sure that:
1. Your /etc/netwall.conf is in Unix format, i.e. LF is at the end of line, but not CR+LF (Windows) or CR (Mac)
2. Check that this file really has LF at the end of your line. It should look as:
ACCEPT net fw tcp 22<LF>
(where <LF> is not a part of text, but symbol). It works for me and I do use SSH externally.
Regarding nano. Well, vi is nice editor ;-). If you need nano maybe it has sense to install lightweight Entware. If Debian anyway: it is beeter to use Strech (not Jessie).
Voxel.
Voxel,
I have exactly that but stiil get a "port 22: operation time out". I am using the same id_rsa key I use if I am on the network as well (not sure if thats an issue?).
I use a config file in my ~/.ssh folder to keep things simple, the first to login to the router when home and the second when remote.
Host router_home
HostName 192.168.1.1
User root
Port 22
IdentityFile /Users/me/.ssh/id_rsa
Host router_remote
HostName XX.XXX.XX.XXX
User root
Port 22
IdentityFile /Users/me/.ssh/id_rsa
Within the GUI (routerlogin.net)
- I do not have port forwarding turned on yet (I can't put the actual local 192.168.1.1 so I don't see the point untill I get other devices pluged in).
- I do not have IPv4 turned on.
-Stavi
I am using the same id_rsa key I use if I am on the network as well (not sure if thats an issue?).
No of course. The same id_rsa is OK. I am using the same.
I do not have IPv4 turned on.
? You mean IPv6?
Well. Maybe your ISP blocks the port 22? And did you try to ping your router? I mean that there is Advanced->Setup->WAN Setup->Respond to Ping on Internet Port checkbox. If checked you should be able to ping your router from external node.
Maybe it has sense to change the port for dropbear (e.g. 22->8022). /etc/init.d/dropbear init script. Change
PORT=22
to
PORT=8022
Also change the /etc/netwall.conf and reboot your router.
Voxel.
Voxel,
Agg, sorry meant IPv6.
Using ping (on mac) I dont get any issues
USER:.ssh me$ ping -c3 **.***.**.***
PING **.***.**.*** (**.***.**.***): 56 data bytes
64 bytes from **.***.**.***: icmp_seq=0 ttl=46 time=352.282 ms
64 bytes from **.***.**.***: icmp_seq=1 ttl=46 time=579.909 ms
64 bytes from **.***.**.***: icmp_seq=2 ttl=46 time=149.215 ms
--- **.***.**.*** ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 149.215/360.469/579.909/175.925 ms
*************************************************************************************************************************************************************************
However using this website (https://www.ipfingerprints.com/portscan.php) to ping both port 22 & 8022 comes back as filtered with the only open port I found being 443. In fact I have to use the "don't ping" option to get any response from port 22/8022 as "TCP" ping comes back as IP offline.... Looking at my internet companies web page (https://www.spectrum.net/support/internet/blocked-ports/) they do not "claim" to block port 22 so I am assuming I am having some type of firewall issue on my end... In the router GUI under advance > Security > Block Services I have never selected and I use my own modem so no firewall there., my computer also does not have a firewall setup.
If it helps below is a log how far I get everytime when trying to log in remotely. Below that is a sucsessfull log in when on the network.
USER:.ssh me$ ssh -v ROUTER_REMOTE
OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /Users/me/.ssh/config
debug1: /Users/me/.ssh/config line 9: Applying options for ROUTER_REMOTE
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to **.***.**.*** port 8022.
ssh: connect to host **.***.**.*** port 8022: Operation timed out
************** Sucessfull SSH on Network *******************
debug1: Reading configuration data /Users/me/.ssh/config
debug1: /Users/me/.ssh/config line 1: Applying options for M8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 192.168.1.1 port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version dropbear_2018.76
debug1: no match: dropbear_2018.76
debug1: Authenticating to 192.168.1.1:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp521 SHA256:a/************************************
debug1: Host '192.168.1.1' is known and matches the ECDSA host key.
debug1: Found key in /Users/me/.ssh/known_hosts:1
debug1: rekey after ********** blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after *********** blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/me/.ssh/id_rsa
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.1 ([192.168.1.1]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
I am thinking I might just reflash your firmware and start from scratch...
Voxel,
I wrote up a very lengthy response, however the webpage decided to eat it all..
When I use the "ping" command from terminal on my mac everthing looks fine. However, when I using some online utilites it seems that the only port open is 443. Port 22 and 8022 both are "filtered" which acoridng to the website means there is some sort of firewall. I dont have one setup on the router or the my computer and my ISP provider (https://www.spectrum.net/support/internet/blocked-ports/) indicates they dont block it either.
Now I recently upgraded to your latest firmware (last one I had was likely from nov/dec 12), and I did not reset it to factory settings after. I figured if I was upgrading from a prior version of yours it wouldn't be needed. Could this be the case? if not I might just reflash your latest realsease again and set back to factory settings and try all over again.
nov/dec 17* (don't know how I did that).
1. Check that your netwall.conf is really working. Run the commands:
net-wall rule
cat /tmp/netwall-rules
you should see your 22 port (very first line)
ACCEPT net fw tcp 22
#Accept Rules Begin:
ACCEPT net fw udp 520,5050
. . .
2. Check iptables settings:
iptables –L –n | less
Scroll down its output and check that rule exists:
Chain net2fw
. . .
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
. . .
Voxel.
Voxel,
After checking the net-wall rules and IPtables were correct I went ahead and "clean installed" per your direction I ->
1. Backup your current settings
2. Flash some old version of firmware, e.g. 1.0.2.54SF
3. Perform revert to factory settings
4. Flash my latest version 1.0.2.59SF
5. Perform revert to factory settings
6. Restore your settings from backup
However.. Now I am not able to even SSH into router when on the network ->
MDMBP:.ssh md$ ssh -v [email protected]
OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 192.168.1.1 port 22.
ssh: connect to host 192.168.1.1 port 22: Connection refused
Looking through your above thread, both the iptables and net-wall rules are configured correctly. I went through and made new id_rsa keys at least three times but that doesnt seem to help either. I am wondering if my old ssh_config & sshd_config files (on my mac /etc/ssh) are configured wrong? In any case they are below.
SSH_ CONFIG
# $OpenBSD: ssh_config,v 1.33 2017/05/07 23:12:57 djm Exp $
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
# Host *
# ForwardAgent no
# ForwardX11 no
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Protocol 2
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,[email protected]
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
Host *
SendEnv LANG LC_*
***************************************************
SSHD_CONFIG
File: sshd_config
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# pass locale information
AcceptEnv LANG LC_*
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Talking to another ISP rep, I was told that we cannot use a static IP for remote SSH login (the opposite of what I was told before). I am not sure who to belive. He said they switch the IP's every two weeks or so but I havent seen it switch yet...
I just relized I didnt copy in the 1st half (more import) part of the sshd_config file (see below). I am a bit confused where I should place my id_rsa file as ssh_config and sshd_config both look at different places ( ~/.ssh/id_rsa vs .ssh/authorizedkeys respectively). From my undersatnind the #HostKeys dont matter though since we are authticating from the dropbear "key" instead of the "host", correct?
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#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
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing
After talking with Voxel, there was defniately some wierd issue with the router. However, flashing netgear stock firmware, hard reset, and flash back to voxels newst firmware fixed the issue. SSH now works on network and remotely.