Publickey authentication *from* Asus(merlin) router

[hutchinsfairy]

Apologies if I have missed this elsewhere. It is difficult to search the forum when most of the terms get excluded for being too short (i.e. ssh, rsa)!

I have successfully got my RT-N66U (FW:378.55_0) to run SSHD and can login remotely using publickey authentication. What I am now struggling with is to SSH from the Asus to another machine on my LAN that only accepts publickey authentication (i.e. no password).

I can't find ssh-keygen on the router and I'm not sure how else to create a keypair. Any help appreciated!

 

[martinr]

When you say you want to SSH from the router to another device on the LAN, is there a reason why you'd rather do that than say use Putty or Xshell 5 on a Windows or Linux device to SSH to the other device?

 

[hutchinsfairy]

I'm ssh-ing into my router from elsewhere so I'm not actually on my LAN when I'm trying to do it.

I could open yet another port in the firewall but it becomes complicated because all other traffic for the target device (a microserver) is being sent via a VPN.

 

[hutchinsfairy]

OK, I'm actually getting there on this one. First, I have to use dropbearkey rather than ssh-keygen to generate the files:

cd /tmp/home/root/.ssh
/usr/bin/dropbearkey -f id_rsa -t rsa
/usr/bin/dropbearkey -y -f id_rsa > id_rsa.pub
chmod 600 id_rsa
chmod 644 id_rsa.pub

Then I copied id_rsa.pub over to the target machine and appended it's contents to authorized_keys.

Now I can ssh without PW:

ssh -i /tmp/home/root/.ssh/id_rsa user@host

Now I just need to try to make this persist over reboot, probbaly by copying the files to /jffs/scripts/ and then amending services-start to create an alias:

alias Host='ssh -i /jffs/scripts/id_rsa user@host'

 

[martinr]

Sorry, I understand now. And when I've done what you're trying to do, my internal device fortunately accepts a username and password. In your case you need to authenticate first to the router with PKI and then further authenticate using PKI with the internal device. I take it that you can't do that with Putty?

What about establishing an OpenVPN connection to the router and SSHing using Putty with PKI through the VPN tunnel?

 

[hutchinsfairy]

I've actually been able to get this to work as per my previous post. The only bit I'm struggling with now is getting the Alias to persist between reboots. Sorry for wasting your time!

 

[pmosher441]

Just a note about searching for short terms -- use google.com and specify the site you're interested in, as here:

site:snbforums.com ssh

You're able to search for short strings such as "ssh" or "rsa".

 

[martinr]

....Sorry for wasting your time!

Not at all: I'm very interested in the outcome, as I'm sure others will be. And it's good to refresh my memory: with my connections pre-set in Putty/Xshell and similar apps, I tend to forget the underlying commands etc.

 

[sfx2000]

might consider using an internal host as a jump box, and disable direct WAN access to dropbear on the router itself...

Any Raspberry Pi can do this - tighten up the openssh-server config file as the default is fairly open...

 

[martinr]

might consider using an internal host as a jump box, and disable direct WAN access to dropbear on the router itself...

Any Raspberry Pi can do this - tighten up the openssh-server config file as the default is fairly open...

What exactly is meant by a jump box, and which bits of the config file would you recommend be tightened and in what way?

 

[sfx2000]

What exactly is meant by a jump box, and which bits of the config file would you recommend be tightened and in what way?

A 'jump box' is a trusted intermediary that normally lives in a DMZ or similar...

the settings of concern in sshd_config are as below;

# Authentication:
# LoginGraceTime 120
LoginGraceTime 30

# PermitRootLogin prohibit-password
PermitRootLogin no
StrictModes yes

#MaxStartups 10:30:60
MaxStartups 2:30:10

MaxAuthTries 3
DebianBanner no
AllowUsers (some username, see below)

Then create a specific user, and this is your 'jump' user, and it does not have admin privileges on the machine itself - this is the user that would be in the AllowUsers line I mentioned above... if you need to do admin on the 'jump' box, then just su over to an account that does have sudo..

There are more settings, but the ones I mention above should be a good start...

Once the edits are done, restart OpenSSH...

sudo adduser (see above)

follow the prompts...

Since Raspbian is basically the same as Debian (or derivatives like ubuntu), the rest is pretty easy - lot's of recipes out there...

Once that's all done - if one wants certificates, can generate them there...

Little tip - Raspbian includes the UFW (uncomplicated firewall) - which is a nice frontend to iptables...

might have to do an apt-get install ufw perhaps...

then...

sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw limit ssh

sudo ufw allow from 192.168.1.0/24
sudo ufw allow from fe80::/64
# done for most purposes

you can always query the ufw by doing sudo ufw status...

So it's a little bit of work - should take a couple of minutes - once done however, that 'jump' box and user can then be used to ssh over to other hosts on the trusted side of the firewall as needed - and remember, OpenSSH has some very nice things, like the ability to tunnel other things thru that connection...

 

[sfx2000]

So once that's all done (and tested), then just port forward the jump box - and even there, one doesn't have to do a direct map - so the internal side might be 22/TCP, then map that to some other port on the WAN side - so port 8022/TCP or whatever...

This protects the most important part of your network - the firewall - only expose essential ports to the WAN, and never expose something you don't want to...

 

[martinr]

Many thanks. That ties in very well with a Udemy course I'm going through on network security, and would be a great practical exercise, especially to play with UFW.

 

[sfx2000]

A Pi model B works fine at this - any Pi should, but keep in mind that PiZero would need a USB-ethernet adapter...

 

[sfx2000]

Many thanks. That ties in very well with a Udemy course I'm going through on network security, and would be a great practical exercise, especially to play with UFW.

Cool - I like the Udemy courses - we get a free license thru work

 

[martinr]

Cool - I like the Udemy courses - we get a free license thru work

I'm really impressed with what I've seen: the quality of the instructors and their delivery, and, of course, the superb course material. And when they have sales on, with courses reduced to around £10, it's exceptionally good value, and beats doing dozens of Google searches
to sites of varying quality, by which time I would either have forgotten why I was searching or would have lost the will to live.

You must be working for an enlightened organization.

 

[hutchinsfairy]

So once that's all done (and tested), then just port forward the jump box - and even there, one doesn't have to do a direct map - so the internal side might be 22/TCP, then map that to some other port on the WAN side - so port 8022/TCP or whatever...

This protects the most important part of your network - the firewall - only expose essential ports to the WAN, and never expose something you don't want to...

Yes, this is pretty much what I'm doing with the router. I have a single, non standard, port open on the WAN side which accepts SSH with publickey auth only. I can now use the router as my jump box to access the home network. I'm going to setup an OpenVPN server as well but for most things SSH gets me what I need.

 

[sfx2000]

Yes, this is pretty much what I'm doing with the router. I have a single, non standard, port open on the WAN side which accepts SSH with publickey auth only. I can now use the router as my jump box to access the home network. I'm going to setup an OpenVPN server as well but for most things SSH gets me what I need.

Sounds good - the intent of doing a jump box is to keep the integrity of the router/gateway that is also the firewall - it's becoming a much bigger deal these days as the blackhats are beating up on these things much harder than they have in the past...

dropbear, by itself, is secure - the concern is that the basic OS in most consumer routers do not have any level of access control - everything runs with elevated privileges, so it doesn't take much to break any one of them, and "get root" on the box.

 

[busch09]

So I'm trying the same thing but get stuck on a variant:

from my PC to the SSH ...1.12 host I am using the following and it works fine on a bunch of hosts without entering the pw for the hosts:

ssh-keygen -t rsa
ssh [email protected] mkdir -p .ssh
cat .ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'
ssh [email protected] "chmod 700 .ssh; chmod 640 .ssh/authorized_keys"

Now I want to do this from my asus ...1.1 to ...1.12 :
ssh into ASUS
cd /tmp/home/root/.ssh
/usr/bin/dropbearkey -f id_rsa -t rsa
/usr/bin/dropbearkey -y -f id_rsa > id_rsa.pub
chmod 600 id_rsa
chmod 644 id_rsa.pub
cat .ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'

The host still asks me for a password. What am I missing?

 

[dave14305]

So I'm trying the same thing but get stuck on a variant:

from my PC to the SSH ...1.12 host I am using the following and it works fine on a bunch of hosts without entering the pw for the hosts:

ssh-keygen -t rsa
ssh [email protected] mkdir -p .ssh
cat .ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'
ssh [email protected] "chmod 700 .ssh; chmod 640 .ssh/authorized_keys"

Now I want to do this from my asus ...1.1 to ...1.12 :
ssh into ASUS
cd /tmp/home/root/.ssh
/usr/bin/dropbearkey -f id_rsa -t rsa
/usr/bin/dropbearkey -y -f id_rsa > id_rsa.pub
chmod 600 id_rsa
chmod 644 id_rsa.pub
cat .ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'

The host still asks me for a password. What am I missing?

The dropbear ssh client default identityfile is expected to be ~/.ssh/id_dropbear so you may need to pass the id_rsa.pub file to your ssh command via the -i parameter.