|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
User Information Home
 NCSA's Help Desk is available 24 hours a day, seven days a week, 365 days a year: Kerberos and SSH through Firewalls and NATsThis document is meant as a guide to a firewall administrators or site administrators who use Network Address Translation (NAT) trying to allow users behind their firewall or NAT to use SSH (secure shell) or Kerberos clients to access servers outside. Much of the information on this page, while believed accurate, has not been tested, because we don't have a firewall.
Table of Contents
What traffic must I allow through my firewall in order to use SSH?A SSH connection looks very much like a telnet connection, except that the SSH daemons runs on tcp port 22 and not port 23. So from the client to the daemon you need to allow tcp traffic on port 22. In the return direction you will need to allow tcp traffic on an ephemeral port number (>1024).
What if I want to access NCSA's internal server through a firewall?Connecting to NCSA's internal server is very similar to connecting to a standard web server, however, the secure server runs on port 443. So you need to allow tcp traffic on port 443. In the return direction you will need to allow tcp traffic on an ephemeral port number (>1024).
What traffic must I allow through my firewall in order to use Kerberos?There are three components in the Kerberos world: the kerberos client applications (e.g. kinit, telnet, pop), the server applications (e.g. telnetd, popper), and the Kerberos KDC. Each pair has different types of traffic that go between them. Depending on the pair of components your firewall is between, you will need to allow different types of traffic through your firewall.The notation 'xxxx/udp' or 'xxxx/tcp' below refers to an ephemeral port number (>1024). This refers to a return port that is assigned by the system. The only assumption you can make about the port number is that it will be greater than 1024. Between a client program and the KDC, your firewall may need to allow traffic on the folowing ports/protocols:
Between an application server and the KDC, your firewall may need to allow traffic on the folowing ports/protocols:
Between an client program and an application server, your firewall may need to allow traffic on the folowing ports/protocols:
An ExampleA common example is that you are on one side of a firewall (call it the inside) and you want to make a Kerberos telnet connection to a box on the outside of the firewall. First you would need to run kinit, which means the firewall would need to allow your udp traffic to port 88 to pass out and the return traffic to some ephemeral udp port (>1024) to pass back in. This allows you to get your Kerberos ticket.Now you run telnet to connect to the tar host outside the firewall. First telnet gets a Kerberos service ticket. It does this using the same UDP ports as kinit does, so assuming kinit works this poses no additional requirements. Then telnet would make a connection to the telnet deamon running on the target machine. Note that this uses the same ports for here on out as a non-kerberized telnet connection. So you would need to allow traffic to TCP port 23 out of the firewall and return traffic to some ephemeral tcp port (>1024) to pass back in. If you wanted to make a Kerberos rlogin connection (un-encrypted) instead. The example would be the same as the above, except instead of allowing traffic on TCP port 24 out, you would need to allow traffic on TCP port 543 out.
Questions or comments about this page may be sent to kerberos@ncsa.uiuc.edu
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
