Router2 doesn't need to do port forwarding, it needs to do routing.
If client has address 192.168.1.123 say and default gateway 192.168.1.1 then all you need to do is set a static route on router 1 that directs traffic for 192.168.2/24 to Router 2 (192.168.1.2).
When client sends traffic to router1 for the file-server, Router1 will reply with an ICMP redirect and the clients will thus learn of the appropriate router for the address of the file server.
It is far better to have the routers manage routing than to set static routes on clients.
Port forwarding is the wrong tool for this job. Port forwarding is mainly useful when an external client is attempting to access resources in an unrouteable LAN. Within one organisation's use of 192.168 block of private addresses, all subnets are routeable. Of course it is possible to mess up address allocation to subnets but port forwarding is not the answer to that either.
You need a NAT rule (to direct the traffic) and a regular firewall rule (to permit it).
The former will look something like
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 4444 -j DNAT --to-destination 192.168.122.50:22
The latter will look something like
iptables -A FORWARD -i eth0 -p tcp --dport 4444 -j ACCEPT
It's up to you to make sure those come at the right point in your existing PREROUTING and FORWARD chains, and in addition you may need a second firewall rule to permit the back-half of those connections out, if you don't already have a general ACCEPT for ESTABLISHED packets.
Edit: the order of your rules is extremely important. The right rule in the wrong place will do no good. Could you replace the grep output above with the result of iptables -L -n -v and iptables -t nat -L -n -v? And if you want port 4444 to be forwarded, don't run a local sshd also bound to that port.
Edit 2: and there's your problem. The ACCEPT you've added in the FORWARD chain is line 7, but line 4 has already explicitly denied all not-previously-permitted traffic from everywhere (*) to virbr0. You need to make arrangments for the line you've added to come before line 4, perhaps by adding the rule with
iptables -I FORWARD 4 -i eth0 -p tcp --dport 4444 -j ACCEPT
which will insert it at line 4, displacing the current line 4 to be line 5 (and so on).
Regarding the current sshd, I mean what I said: that you shouldn't have a daemon bound to port 4444 if you're trying to forward that port. I don't care what other ports it's bound to, only that 4444 is a bad idea.
Edit 3: the machine you're testing this from, this is completely outside the serv05 system, yes? And (after a very trying day putting Fedora 16 on several boxes) I fear you may be right, could you put a comparable ACCEPT rule for 4444 in the INPUT chain as well, being careful to get it before any REJECTs?
Best Answer
Instead of punching multiple holes in your router you may decide to use the following trick:
open a connection to the first machine in one terminal window with the following command:
ssh -L 10022:machine-2-local-ip:22 user-on-machine-1@router
open another terminal window and you will be able to securely connect to machine-2 using
ssh -p10022 user-on-machine-2@0
To describe it in plain English:
The first command starts up an ssh session with the router on port 22 and sets up ssh port-forwading binding your localhost's port 10022 to the machine-2-local-ip address on port 22 (as visible from the router). So, if you have proper internal DNS or a name defined in /etc/hosts on the router you can use a name in place of machine-2-local-ip, otherwise use the internal IP address of the second machine there.
The second command connects to port 10022 on your localhost. This port is forwarded through the established ssh session in step 1 to machine-2. :)
Hope this helps.