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/id_rsa.pub
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 
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
UPDATE:
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.
