OpenWrt Forum Archive

Topic: Openssh - public key only via WAN, key or password via LAN?

The content of this topic has been archived on 25 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi!  I have kind of a long question that I suspect can be answered quite succinctly.

Short version: I've recently been running both openssh as a tunneling proxy on port 22 of my WAN interface, and dropbear, as a backup server in case I lose my private key and need to actually log in to my wrt with a password, on port 2222 of my LAN interface.  I'd like to know if I can either:

1. Run just one instance of openssh that will accept only my private key on the WAN interface, but will accept either the public key or password-interactive on the LAN interface, or

2. Keep running openssh as a daemon on the WAN interface, and then maybe fire up another instance of openssh per connection to port 2222 of the LAN interface, inetd style (maybe this one would specify an alternate config file on the command-line or something).

Basically I'm just trying not to need to run openssh+dropbear, or two instances of openssh - one, because I'm hoping for less memory in use on the wrt, and two, because I'm just kind of OCD that way.

The reason I need to run openssh, and not dropbear, on my public WAN interface is that my workplace firewall has recently started blocking outbound traffic on ports other than 22, 80, and, uh, https, and I need to be able to send and receive non-work email from there (ie, IMAP, POP and SMTP).  In my current setup I'm using PuTTY from my laptop to connect through the work firewall to my wrt at home; PuTTY is set up to act as a SOCKS proxy, and then my mail client is pointing to it as a SOCKS proxy.  This is all working perfectly right now.

The idea of having a password-enabled ssh server from the LAN comes from my profound distrust of hardware, coupled with some confidence in the two ideas that (1) my LAN is reasonably secure and (2) my passphrase isn't terribly vulnerable to dictionary attacks.  If there are security implications that I'm overlooking I'd love to hear about them, though.

The thing is that openssh only has one config file, and I can't see any way for it to alter its configuration based on the interface that a connection comes from.  I did grep the openssh site and the openwrt site before asking this, but it's still quite possible that I missed something, in which case please point me in the right direction.  In fact, I'd be happy to run dropbear on the WAN instead, but AFAICT it still doesn't do SOCKS proxying.

I should also mention for the record that I'm currently running White Russian, but I've been meaning to upgrade to Kamikaze for a while, so I'll most likely do so before going ahead with any openssh/dropbear changes.

TIA for any advice.

I would simplify that all a bit.  Instead of using a proxy, just use port forwarding.  Dropbear does port forwarding just fine.  For the two different configurations, run two instances of dropbear.

I've considered it, but I'd really like to keep the dynamic proxying going if at all possible.  I only have three outbound ports to use from the firewall, and I'd need two of them for incoming IMAP / outgoing SMTP on my main account.  I also have two secondary POP accounts that I'd like to be able to watch over during the day, if I can.  (The proxy is also nice for getting through my company's HTTP content filters if I need to.)

Hi,

Do you want to use the password-login on a regular basis, or do you only want to have the possibility to login if you lost your private key?
If you only need a emergency-login, you should try if the failsafe-mode is working, so you should have a telnet or ssh-login through dropbear, when you need it to fix your box or enable passwordlogin in openssh... 
This way you have a emergency-login, and you don´t have to try to put it into your normal config.
Or you get a serial-console cable so you don´t have to care about services, firewalls, and ports at all

The discussion might have continued from here.