http:// www.jms1.net / client /

Information for my clients

This information is here for my clients to use. If you've stumbled on to the page but you're not one of my clients, there's probably not much here for you.

Last updated 2018-03-29

Email issues

Email hosting setup

If you have a domain and want me to handle its email, there is a specific DNS entry (called an "MX record") which needs to be created. If I'm handling your domain's DNS, I will do this for you. Otherwise, you will need to set up this DNS record, with the following values:

Record Type	`MX`
Priority	`0`
Server Name	`a.mx.jms1.net`

Let me know when you have done this, and I will set up the domain and its postmaster mailbox on the server.

Mailbox administration

The "qmailadmin" interface for your domain is accessible using https://admin.jms1.net/ to access qmailadmin.

Note: this address will redirect you to the actual address, which is https://secure.jms1.net/qmailadmin.cgi. Feel free to use either address, I just find the first one easier to remember.

Email client setup directions

If I am hosting your domain's email on my server, you will need the directions on this page to set up an email client (such as Thunderbird) to access your mailboxes.

Webmail

If you wish to use a webmail interface to access your mailboxes, you can use https://webmail.jms1.net/ to access the webmail interface. It's not the fanciest interface out there, but it works.

Mail filtering rules

I have written an interface which allows my users to control the filtering of their incoming email. You can use it by visiting https://rules.jms1.net/.

If you're curious, this page has information about the system itself, including instructions on how to set it up on your own qmail server.

Allowing me remote SSH access

If you are my client because I am managing, maintaining, or otherwise accessing your server without physically being in the same room with it, this section is for you.

In order to allow me to remotely access your server via ssh, you first need to make sure your sshd allows logins with public keys. Check and/or edit your /etc/ssh/sshd_config file. You need to make sure it has the following entries:

PubkeyAuthentication   yes
This may be commented out. Since the
default is "yes", this is fine. The point is that it cannot be
"no".



AuthorizedKeysFile     .ssh/authorized_keys
Some older systems used the name
".ssh/authorized_keys2" instead. If yours is one of them (i.e.
if this line already exists and has the other filename) that's fine- you
just need to adjust the filename when installing the key
(below.)



AllowUsers
If this line exists and is un-commented
in your sshd_config file, you should make sure that the userid
as which you wish me to log in is listed.

In addition, if the userid you wish me to log into is "root", you will need to check this line as well:

PermitRootLogin        without-password
Note that you could also have
"yes" here, although it's not as secure. The difference is that
"without-password" means that root is allowed to log in, but only
if they use an authentication method other than "password". This way if
somebody happens to find out what your root password is, they can't use it
to ssh into your machine.



I know the phrase "without-password" can be a bit misleading. You should 
type "man ssh_config" to read more abut this option.

If you had to change the /etc/ssh/sshd_config file, you will need to restart sshd. This is usually done with a command like this...

# /etc/init.d/sshd restart

Adding my ssh public key

After checking the configuration of sshd, you will need to add my current ssh public key to the ".ssh/authorized_keys" file within the home directory of the user you wish me to access. This example shows how to set it up. Note that if your system uses the name ".ssh/authorized_keys2" in the AuthorizedKeysFile line (see above) you should substitute that filename below.

I have changed to a new SSH key as of 2017-11-27, with the private key stored only on a YubiKey 4 which I carry on my keyring. If you have one of my older keys on your server, please remove it, and install the new one instead.

# cd ~userid

Substitute the userid as which you wish me to log in.

# mkdir -f -m 700 .ssh
# cd .ssh
# wget http://www.jms1.net/sshkey.txt

The file should transfer. If you don't have wget on the system but you do have curl, you can replace "wget" with "curl -O" (that's a capital "o", not a zero) and accomplish the same thing.

# cat sshkey.txt >> authorized_keys
# chmod 600 authorized_keys
# chown uid:gid authorized_keys

Substitute the userid and that user's login group ID as which you wish me to log in.

Accessing files via FTP

If your web site is hosted on my server, this section is for you.

The normal FTP protocol involves the client sending the password to the server, across the internet, in plain text. This means that anybody with a packet sniffer in the right place is able to literally READ your password right off the wire.

Because of this inherent insecurity, I do not, and will not, allow any access to my server using the FTP protocol.

There is a protocol called SFTP, which is part of the SSH protocol suite. My server does allow SFTP access, using the same port number used for SSH logins (in fact, SFTP can happen over the same SSH tunnel which carries your login session.) More programs every day are starting to support it, but not all of them.

If you are using a program which knows how to do FTP, but doesn't know how to do SFTP, all is not lost. There are ways around the problem, depending on your system.

Cyberduck is the client I use myself. It's a free, open source (GPL licensed) client for FTP and SFTP, which also supports WebDAV and some other things as well. It is designed exclusively for Mac OS X 10.4 and later.
FileZilla is a free and open source FTP and SFTP client for Mac OS X, Linux, and Windows. It's free in both senses of the word- both the pricetag (i.e. "free beer") and your right to see, change, and re-distribute the source code (i.e. "free speech".)

I've played with the Mac version a little bit. It does work, although I'm not crazy about their interface- it has "local" and "remote" areas in the program's main window, and you have to use them in order to copy files in either direction. Personally, I prefer the interface used by Cyberduck (above), where the program's window shows the contents of the remote server and you can drag and drop into and out of normal Finder windows. However, I also know that the differences between how the various desktops (Mac OS X, KDE, Gnome, Windows, etc.) implement "drag and drop" functionality would make this a very complicated thing to support on all platforms.

I did also find a minor bug- nothing which would affect most people, unless you use an SSH agent on a regular basis.
WinSCP is another open source SFTP and FTP client, however it's only for Windows. This one is easy enough to use that even my mother can figure it out.
SecureFX is probably the best Windows-only FTP/SFTP client on the market. It's so good that even though I don't have a Windows desktop, I still keep my license up to date so I can legally use it (from a USB stick) when working on clients' Windows machines.

It's not free- the price is currently USD $59.95 with one year of free updates, however if you use Windows and you do file transfers on a regular basis, it is definitely worth the money.
Tunnelier is a different kind of animal entirely. It's an SSH tunneling program for Windows which includes, among other things, an FTP-to-SFTP translator. This means you can use Tunnelier to open an SSH tunnel to the server, and then use any FTP client you like, including the FTP clients which are built into many "web authoring" programs, to upload and download files on the server.

It's not open source, but it is free for personal use, up to five copies. My personal opinion is that if you're using it to update a business-related web site (or any web site, if you're being paid to do it) would be commercial (i.e. not "personal") use, however I don't think it's my job to act as the licensing police. If you plan to use it for non-personal use, I encourage you to do the right thing and pay for a license. A one-seat commercial license is only USD $45.00 (as of the last time I looked at their web site.)

Tunnelier includes a built-in graphical SFTP program, which allows you to drag and drop files from your local machine to the server, as well as change the permissions of the files on the server. It also has an SSH terminal emulator, which does work, but isn't nearly as good as SecureCRT (which is made by the same people who make SecureFX, above.) Of course, if you rarely or never use a command line, this may not be an issue for you.
FUSE is yet another "different" kind of program. It's a system, available for Linux and Mac OS X, which allows filesystem drivers to run in user-space (i.e. not as part of the kernel.) One of the filesystem drivers available for it is SSHFS, which allows you to "mount" a directory on the server as part of your local filesystem, using an SSH connection. (Both pieces of software are open source.)

Once you have mounted the server's directory on your machine, uploading files to the server is just like copying them- you can use the same tools you would to work with any other disk (i.e. Finder, KDE or gnome file manager, cp or mv, etc.) It will work, although it will be slower than working with a local disk. You can also use your web authoring software and work with the files on the server "directly", as if they were stored on your local machine.

For Mac OS X 10.4 and higher, there is a binary distribution of FUSE called macfuse, which includes the SSHFS filesystem module. It includes some options to improve integration with Finder, as well as an unsupported GUI front-end for setting up mounts.

SSL Certificates

If I'm hosting web sites for you, those web sites really need to be encrypted (i.e. served using the https protocol.) In order to do that, the server needs an SSL certificate and the corresponding private key.

If I'm handling your domain's DNS, then I can get these certificates for free, and renew them automatically, using Let's Encrypt.

If your domain's DNS is hosted somewhere else, I can help you get them, but it will be a manual process to get and renew the certificates. The first part of the process is to generate the key and a CSR (Certificate Signature Request). In order to maintain security, I normally generate these things on the server (where the key file has to be anyway), and then you use the CSR to get the actual Certificate.

Either way, the web server has to be manually configured to use the key and certificate, and to set up a non-encrypted redirector so that users who request your site using http:// are automatically redirected to the https:// URL. Talk to me about it and we can go over the details.