First, all credit to Vladimir Parkhaev as this is his code. He may have submitted this before for all I know, but I for one definitely would like to see this end up in the codebase, so I'm submitting it. *** openssh-5.1p1/serverloop.c Fri Jul 4 09:10:49 2008 --- openssh-5.1p1-RCFHACKS/serverloop.c Thu Jan 29 08:56:11 2009 *************** *** 957,962 **** --- 957,968 ---- c = channel_connect_to(target, target_port, "direct-tcpip", "direct-tcpip"); + if (c == NULL){ + verbose("Tunnel denied: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } else { + verbose("Tunnel opened: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } + xfree(originator); xfree(target);
we should look at this for 5.4
logging all port forwards would be noisy even for verbose. I think a better way to do this would be to: 1) make AllowTcpForwarding a tri-state, with value 2 meaning "allow, but log". Server admins could turn it on for verbose logging for forwarding activity 2) Add a verbose() call to channel_connect_to(). This will catch both ssh1 and ssh2 cases. 3) We would also need to explicitly log requests of -R port forwardings and tunnel forwards for consistency.
Upstream has locked already, so we will look at this in 5.7
Retarget unclosed bugs from 5.7=>5.8
Retarget unresolved bugs/features to 6.0 release
Retarget unresolved bugs/features to 6.0 release (try again - bugzilla's "change several" isn't)
Retarget from 6.0 to 6.1
Retarget 6.0 => 6.1
Retarget uncompleted bugs from 6.1 => 6.2
Retarget bugs from 6.1 => 6.2
retarget to openssh-6.3
Retarget to openssh-6.4
Retarget 6.3 -> 6.4
This needs more design and probably a new configuration item, since AllowTCPForwarding has already grown options beyond 'yes' and 'no'. Maybe a "LogForwarding yes|no|local|remote|tunnel" Detargetting from a release until we come up with something concrete.
I can see this kind of thing coming up for logging other things too. How about an option like Logging forwarding,commands,thing,otherthing,... which internally is a bit vector. We'd have to annotate some logging calls with what kind of info they're logging, but once that's done the logging infrastructure can log at normal logging level (if you care about it) or debug3 (if you don't).