Sshd parameter "ListenAddress"

Enhancement Request for
–> IPfire WebGui dialog “Remote access - SSH”

Please, add an option for the sshd parameter “ListenAddress”
to be limited from “” to an internal address range.
This could be done by input of the appropriate Interface IP,
or - even more luxorious - by tick-marks enabling the colors respectively;
e.g. only tickmarking “Green” would limit access to “from my internal physical network only”.

So far, I have to use ssh to edit /etc/sshd_conf manually - no problem.
In my view, ease of above option could persuade also less experienced people
to this reasonable limitation.

If you change the Default firewall behaviour under the Firewall Options to blocked and add a firewall rule to permit tcp/222 from the green network (or specific IPs) only and not anywhere you will have that result. No need to edit sshd_conf.
Better yet change to key based authentication as well.

1 Like


IPFire’s SSH daemon cannot be accessed from RED or ORANGE by default, and - as @troll-op mentioned - further access can be limited by creating firewall rules.

@manfred_knick: I thereof have not seen your point yet. :slight_smile:

Thanks, and best regards,
Peter Müller

Andreas, Peter: thanks for your answers.

Searching the Wiki: ,
I was not able to grasp above information,
e.g. from .
Question: How is this achieved?

Well, since 1999 / OpenSSH 1.2.2, “ListenAddress” has been one of the base security mechanisms
to self-limit this precious access, independent of any other tools.
IPFire is a very good firewall, indeed - but I don’t buy “Nail everything with the same biggest hammer”.
I can’t help Andreas’ suggestion reminding me about a german saying:“Von hinten durch die Brust ins Auge” - unfortuantely, I don’t know any adequate translation.

Personally, I will continue to exploit this proven security means on all my firewalls / servers / … :
Limit to a dedicated cabled network (no wifi !), even accept access only from selected address(es).

Taking Peter’s assurance as a Given, having less experienced users in mind,
I would still value something as simple like “Limit to Green only”.
But that decision is purely up to IPFire’s Designers, for sure.

Kind regards

Just as an example, OpenMediaVault consequently uses optional “Additional Parameters:” input fields throughout it’s Web Interface to enable input of specialized ssh | samba | nfs | … configurations without having to code hundreds of possible options, eliminating temptations to by-pass.

Hi Manfred

The process to generate an authentication key is very clear.

If you are on a Mac you would run the command in terminal
ssh-keygen -f ~/.ssh/id_rsa -P ''
This will create a key on your Mac in a hidden folder within your user home folder. If you want to see if this happened you can just
cat /Users/you_username_here/.ssh/
And it will spit out a long string starting with ssh-rsa and ending with your_username@your_machine_name

On the FW GUI go System > SSH Access and click Allow password based authentication, if it is not already and Allow public key based authentication. Click save

ssh-copy-id -p222 root@your_ipfire_green_IP

That ^ will copy that authentication key across. You will need to provide your root password.

Now if you do a ssh -p 222 root@your_ipfire_green_IP
It should log you in without asking for a password.
You can untick System > SSH Access > Allow password based authentication and save.
No more SSH access without a key. And your machine is the only one with a key.

Under Windows a similar process except you would use something like PuttyGen to create it.
See here for details

I hope that helps :slight_smile:

Regarding the “ListenAddress”… It won’t listen to anything unless the firewall rules are defined correctly. After all ssh is a service running ontop of the firewall. Your “listenaddress” is set there, and not the config via terminal.
I for one don’t believe the default Firewall Options should be forward, but should rather be blocked. I would rather run around, opening doors as need be, than to run about like a headless chicken trying to get things closed. Like Honecker… or someone of similar questionable character said “Vertrauen ist gut, kontrolle ist besser”. This applies to the FW as a complete holistic environment and not only how ssh should be treated.

My personal view…
Whilst I subscribe to a certain amount of paranoia when it comes to security, ssh is not as vulnerable as some believe it is. If you already have security through obscurity by moving the standard port number, and using authentication keys instead of a password (a pass phrases would be better) which is the correct approach, you can still add an IPSET with ssh-block list of known culprits to your iptables (highly recommended) drop list, you should be as secure as it comes. If you now still get bend over the table without dinner first, then ssh was not the problem but something else caused it.

Cheers, have a nice evening

As added security bonus.

vi /etc/sysconfig/rc.local
and add the following towards the beginning.

iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh -j DROP
iptables -A INPUT -p tcp -m state --syn --state NEW --dport 222 -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp -m state --syn --state NEW --dport 222 -j DROP

The rules rate limit connections to ssh. I don’t recall if this comes standard or I kept adding them into my fw configuration.

Hi Manfred,

Question: How is this achieved?

by iptables default policy, which is set to DROP for incoming connections on the RED interface.

Limiting services on certain interfaces is twofold: On the one hand, it prevents accidental exposure to untrusted networks, on the other hand, it makes things much more complicated under the hood. The web proxy, for example, is currently not usable from ORANGE, since it listens on GREEN and/or BLUE only - extending the CGI is possible, but takes some time as it is rather difficult to read. :expressionless:

Personally, I take advantage of ListenAddress on other machines as well. However, as @troll-op mentioned, this does not solve weak authentication mechanisms enabled, such as passwords.

Taking Peter’s assurance as a Given, having less experienced users in mind,
I would still value something as simple like “Limit to Green only”.
But that decision is purely up to IPFire’s Designers, for sure.

This is tricky. To put it simple: If we imagine an IPFire user not being aware of what exactly he/she is doing, is it better to try to make the distribution idiot-proof (if you do not mind myself putting it that way) or do we instead recommend such people not to use IPFire without additional knowledge?

Personally, I am in favour of the latter: If anybody lacks knowledge about writing firewall rules, he/she should not run a firewall. Unfortunately, we cannot prevent ignorance in front of the keyboard, an aspect of information security I tried to stress further here.

Perhaps these thoughts help why we are currently doing things the way we do. At some points, they are inconsistent, primarily for reasons of lacking time or man-power.

Thanks, and best regards,
Peter Müller