As was explained correctly:
INPUT : incoming packets, i.e. packets with the host as destination IP
OUTPUT : outgoing packets, i.e. packets with the host as source IP
FORWARD : packets where neither source ip nor destination ip is the host’s IP
As a side note, talking about the host’s IP is an abuse of language. In reality, the IP belongs to the network interface, not the host. Indeed many hosts have several network interfaces (e.g. wifi radio, ethernet port), each with its own IP.
It was incorrectly stated however that to allow ssh you only need to add a rule that allow incoming ssh packets. This is incorrect, as you can easily see yourself: you’ll allow ssh packets but your firewall will drop (or reject - depending on your default settings) anything that you send back in response to that ssh connection.
The trick is to allow incoming ssh connection and communication, and to allow outgoing ssh communication (but not connection, if you do not want your host to make outgoing ssh connection).
Practically, you set this up this way in iptables:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
(With a default behaviour to drop or reject)
Note that on many clients, you actually want the opposite setting : allow new
and established
on the OUTPUT (to allow yourself connecting to the outside world), and allow established
only on the INPUT (to protect yourself against unwanted connection attempt).
PS: I am playing the necromancer here, but google redirects to this (partially) incorrect accepted answer, so I thought it’d be worth correcting it.