Your Kempt.net account comes with several basic services. These include shell (login) access, email, and web hosting. This document gives some information that you'll need to start using these services. (You may also have dialup capability; that is not explained in this document.)
In several places in this document, you'll have to substitute the example user name, username, with your actual user name that was given to you when your account was created.
These services require authentication, which is usually accomplished using a single, convenient Kerberos password. See the Kempt.net authentication page for more information.
You have an email mailbox. You can use either the POP3 or IMAP protocol to read your mail. There are a couple authentication options, discussed below.
|Sending (SMTP) mail server:||
|Receiving (POP3/IMAP) mail server:||
|Authentication:||Kerberos 5 (GSSAPI), CRAM-MD5, or APOP|
|SSL:||Optional for sending or receiving|
You should use SMTP AUTH (authentication) to send your email through smtp.kempt.net. As more and more sites on the internet adopt SPF and other sender verification techniques, you may find that your mail is refused delivery unless you send it through smtp.kempt.net.
You should use port 587, the Mail Submission Protocol port, to send mail. The mail transfer port, 25, will be the default in many mail clients, but it will work in fewer situations (many ISPs block connections on port 25), and it's not really correct, anyway.
You will probably want to use your Kerberos password to authenticate. If you have not set up a Kerberos password, or if your mail client is not capable of using GSSAPI/Kerberos 5 authentication, then you can set up a special password just for using mail, and use the CRAM-MD5 authentication method. (Note that this is not SCRAM-MD5, which is actually a different algorithm.)
For help setting up a Kerberos or CRAM-MD5 password, contact email@example.com.
If you use SSL, you will want to obtain the CA certificate used by Kempt.net, to avoid certificate validation warnings when you connect.
Mac OS X 10.4 (Tiger) Mail.app appears to have a bug in its GSSAPI encryption, which you can work around by turning on SSL. For more details, see this message. The summary is: If you use GSSAPI for sending mail, also turn on SSL.
You may also use
mailhost.kempt.net in place of the specific
imap hostnames, although
it is not guaranteed to work at all times in the future, and you may not be
able to take advantage of some redundancy features using that hostname.
You have a shell account. You can log into this account using
When you use ssh to log into shell.kempt.net, you must use your Kempt.net Kerberos password (if you don't have one, contact us to set one up). Note that if you have Kerberos client software on your computer, you can get a ticket once and log in for the rest of the day with either ssh or telnet using that ticket. Alternatively, you can set up a DSA public key in the .ssh directory in your kempt.net home directory, but obviously, you'll have to log in some other way to do that, first.
When you use telnet to log in to shell.kempt.net, you must either use a Kerberos-capable version of telnet, or use S/Key to prove your identity when you connect. To use Kerberized telnet, see the Kempt.net Authentication page.
To use S/Key, type your user name at the "login:" prompt. You will then be issued an S/Key challenge, which you must answer in order to log in. Some more advanced telnet clients (such as BetterTelnet on Mac OS) will recognize the S/Key challenge and do all the work for you, so all you need to do is type in your secret passphrase. Otherwise, you will need to feed the challenge and your secret password into an S/Key calculator, and respond with the calculated string. You can use the Kempt.net S/Key calculator applet to do this. Otherwise, you'll need a calculator that will run on your particular machine. Look at the BellCore distribution site.
If you use S/Key, you will need to renew your password every once in a while (every 100 logins) by using the 'skeyinit -s' command. If you forget this, simply type 'passwd'—the normal unix password changing utility—and it will remind you to use the 'skeyinit -s' command. S/Key-enabled telnet clients will warn you when the need to renew your password approaches.
You have a personal web space. Your web directory resides in public_html in your home directory. (Note that this directory only appears to reside in your home directory; it actually resides on a different server machine and is mapped into your directory.) All your web pages will appear under the root of your web hierarchy:
You may also have a virtual domain, in which case your URL will be different.
Directory URLs [URLs that end in a slash ("/")] will be resolved by the web server by returning a file called "index.html" within the specified directory. If there is no such file, a listing of the directory is generated; if you don't want that to happen, make sure there's an index.html file there. File names within this hierarchy are, like all Unix file names, case-sensitive. You can use any of the unix permissions that you like to control access to your web pages, including the index.html files and directories.
Maintaining your web pages
The easiest ways to manage the files in your web space are probably to
Either one can be used with your Kerberos password. With ftp, you can also
use S/Key, and with ssh, you can also set up a DSA public key. See
Shell access, above.
Those methods assume you maintain your web pages on a local computer and wish to transfer them into your public_html directory. Of course, you can also edit your web pages directly from your shell account, using tools such as vi or emacs.
Or, maybe we can help you in other ways. Send mail to firstname.lastname@example.org telling us what you need.