Right. Was planning on shared-key authentication. I'll have to study up on firewalling but do have at least a bit of experience with iptables. I was actually thinking of running ssh on an alternate port as well. And so far as I understand it, port 5269 is so that xmpp can communicate with other xmpp servers, which will not be necessary in my scenario. So I was thinking of opening only port 5222.
That's just what I was planning to do.

I'd also need to decide which distro to run there. I use mostly Arch these days so I initially thought of using that. But I've run Debian/Ubuntu for years as well and have begun to wonder whether, since so many of the how-to's I run across on the web are oriented toward Ubuntu--including the prosody how-to we've discussed in this thread--it might not be better to go with it. Which do you use?

Also, a coupla questions about SSL/TLS as stipulated in the how-to. It makes clear that using SSL/TLS (in order for clients to authenticate before they can log into the server?) is optional. He also mentions that OTR encryption can be used in addition to SSL/TLS for super-secure instant messaging. I'm just trying to ascertain that I understand correctly all these pieces of the puzzle and which are necessary and which optional.

Here's what I'm gathering at the moment. First, this whole scheme can work without either SSL/TLS or OTR encryption in the client, correct? The SSL/TLS piece is being implemented to make it more difficult (impossible?) for someone to masquerade as an authorized user on the system, yes? And the OTR encryption part can be implemented to keep middlemen who might intercept the IM stream from deciphering it, correct? And, finally, with regard to SSL/TLS: implementing this will necessitate that only certain clients capable to that sort of authentication will be able to log into the server, correct? I.e., enabling this might preclude use of certain older clients, yes?

Furhter input will be appreciated.

I use debian stable 7. Debian 8 is out and if you're ok with systemd, use that. Debian stable is well known for its stability and you should expect services there to run without some random crash - solid but it will likely be a old version. This shouldn't be a issue however since you're not looking for the newest features. If it really bothers you, you can always compile your own (requiring increased maintenance). As for arch.. well it's your server, but if you're looking for less work... go with debian
So my suggestion is - use debian and whatever is in the repo. Assuming for a moment you use prosody, install is as simple as apt-get install prosody.
Conveniently, when it comes to configuring programs ubuntu is similar to debian (it is a derivative of it!)
It is optional, but if you don't the authentication will probably occur in clear text. This could include your username and password in clear text. If you ever plan on using a non-secured wifi (like a public wifi.. anywhere) it is trivial to steal your authentication.
The reasons not to are generally:

Self-signed shows a error and getting a "official" one is too expensive/extra work.
You plan on having two users. Once you accept the self-signed certificate (pidgin is one-time), it should not bother you again. The encryption however still applies. While you're at it, double check everything lines up. I would suggest using it unless you're 100% certain you will never be using any public wifi and completely trust your connection to the server. That's a lot of worry over something that is easily remedied for such a small user base. If the error bugs you, Startssl provides free certs. But you must have a domain for this to apply!
So... generate a self-signed cert and use it. It'll provide very little trouble and a lot of extra security at no cost.

As for OTR, this link may explain it a little bit https://otr.cypherpunks.ca/help/4.0....ls.php?lang=en

You don't have to require encryption. In prosody there is a option - --c2s_require_encryption, to permit usage of non-encryption. That should permit usage with older clients.

You can, but alternate port is security by obscurity and easily discovered. If you want to minimize brute force attempts, there are a few tricks you can do with iptables and ssh to secure it. I can list my iptables rules if you're interested as they've been effective for me. The #1 thing to fix that is with public key access and not allowing passwords.

In summary so far (so I can keep track, this is a interesting thread for me as a method of autonomy and communication between small groups)

• Using very low-end VPS and static ip as host
• Opening ports 22 (ssh) and 5222 (xmpp client to server).
• Installation of xmpp server (prosody in my use)
• Generating self-signed certificates
• Adding users accounts and usage of ip address instead of domain (eg foo@42.523.66.33 instead of foo@bar.org)
• Add user to client and accepting self-signed certificates manually (since it'll present a error when adding a user to client - not when adding a friend however)
• Setting up OTR between everyone

Yeah, Debian stable. I should have thought of that. I don't like systemd, but have been forced to come to terms with it under Arch. I know from personal experience that Ubuntu is a derivative of Debian: years ago, after having experimented with Mandrake, Red Hat, Redmond Linux (remember that one?), and various Slackware derivatives, I'd finally settled on Debian as my distro of choice. It was about a year after I'd begun running Debian unstable that Ubuntu came out. I stuck with Debian for awhile longer but, once I began to experience system breakages that required sometimes-lengthy troubleshooting sessions to restore the system to functionality, I decided to switch over to Ubuntu; it had the up-to-date packages Debian stable and experimental lacked, but offered much better stability than unstable.
This looks like a good set of directives for generating a self-signed certificate: https://help.ubuntu.com/12.04/server...-security.html What do you think?
I'd like to go with dropbear, given the fairly paltry system resources of this VPS. I'm still trying to figure out how to make it use public key authentication only. I guess maybe you forgot but I already, subsequent to another thread on this forum where we discussed firewalling by means of iptables, appropriated some of your firewall rules on another machine of mine. So I know where to find them Thanks

LATER EDIT: looking over the man page for dropbear, it looks like the way to force public key authentication is to pass it the -s option. Passing the -w option disables root logins. Under Ubuntu, those switches can be passed by editing /etc/default/dropbear.

Has anybody mentioned Firefox Talk yet? I've only tested it and it seems there may be problems with AddBlock or NoScript but otherwise it seems fine.
Personally I use BBM on my Blackberry (as I am now) and I would be expressely forbidden to install or run anything on either of my work machines unless approved my a committee.

I would have to say that running on a non-standard port is still a good idea. I've been running SSH on my home server for over a year on a random port, and I don't think I've had a single unauthorized login attempt.

So while it should by no means be your only method of securing SSH, I would still recommend running SSH on some port other than 22.

If you're looking for alternatives (and have access to a webserver) you might want to look at phpfreechat. Since it's web-based, it shouldn't require any special software other than a web browser.

Yup, you could also use this one-liner. For common name, you'll probably want to use the servers ip address.

Curious why using dropbear over openssh. openssh is developed by OpenBSD - essentially the go to if you want solid security and is installed by default like anywhere... It works well on my raspberry pi which is very low power. The greatest usage of time would probably be the encryption method rather then the rest of it.

There's nothing inherently wrong and against mass attacks would be a effective deterrent. I suppose my other argument is convenience as it would require remembering where the new port or configuring it. Then later if you try to login on a different computer and forget the port could create some un-needed stress. (IMO)
Past rsa only auth, my favorite move is the usage of AllowUsers, which only permits certain users to login and denies everyone else.
Commonly I'll do something like

and occasionally get login attempts that all fail because they're not in the AllowUsers. Very effective

Wait, I'm getting confused. The relevant files referenced in the prosody how-to we've been discussing and as designated in /etc/prosody/prosody.cfg.lua are /etc/prosody/certs/localhost.cert and /etc/prosody/certs/localhost.key (to which the how-to adds /etc/prosody/certs/dh-2048.pem), right? So what role do your files key.pem and cert.pem play in relation to these? Where are key.pem and cert.pem to be placed and how referenced in /etc/prosody/prosody.cfg.lua? I don't understand terribly well this encryption stuff, as I've mentioned, so am trying to follow step-by step instructions. The files created at the Ubuntu how-to I referenced are named server.key, server.key.secure, server.key.insecure, server.csr, and server.crt, and two of those are to be copied to /etc/ssl/certs and /etc/ssl/private (adapting those directives to my task, I've been assuming that server.key and server.crt should replace /etc/prosody/certs/localhost.cert and /etc/prosody/certs/localhost.key). All this gets a bit confusng to someone who has already only a vague conception concerning these matters.

Also, you speak of "common name," but what is asked for in creation of these keys is FQDN. So, is "common name" synonymous with FQDN for purposes of this task? Such that when it asks for FQDN I put there the IP of my VPS, something like 10.20.30.40?

I'm intending to go with dropbear because it is a low-resource application and this VPS is a low resource system. I'm not absolutely insisting on it, it just seemed like a good idea. I'm aware that dropbear does not have all the capabilites that openssh has, but it seemed its capabilities might suffice for purposes of administering this VPS. That said I'm not trying to rule out consideration of the alternative.

LATER EDIT: found this http://prosody.im/doc/certificates, which contains relevant information.

Encryption with modern IM clients is transparent. You just need a shared secret between you, such as a question and answer. Once set up, you don't even know about the encryption. IM+ on Android and iOS is a good client. I don't know much about Windows because I don't use it, but it does have a browser extension. Mostly I use Google Hangouts for IM with family. We all use it for chatting and for video conferencing. That's how we get to see the grandchildren daily, or nearly, from long distance. It also works on phones and tablets. On a Windows machine you may need to keep Chrome browser open, I don't really know. For texting, I use Pushbullet. It installs on your phone and on PC, and I can send and receive texts on my PC. The phone keyboard is a major PITA for me, and I avoid it if possible.

What an interesting suggestion. Setting up apache with authorzation--something I've managed to do recently--could be a decent way of having semi-secure communications with select users in combination with this software. I'm going to continue looking into this--thanks for the suggestion.

Looks like I got everything configured right and am up and running with this new instant messaging solution (with the exception of implementing OTR clients, something I will experiment with soon). I ended up going with an Ubuntu 14.04 server LTS installation for this. Thanks for all the help offered in this thread.

One clarification regarding iptables rules. Seyfir's recipe for defeating bots attempting ssh connections looks as follows: This is clearly written with a view to having a certain set of local network addresses be exempt from the drop policy--namely 192.168.1.1/24. That part of the rule, however, is inapplicable to the VPS situation where I'm setting this up, since there's no LAN in play there. So part of that stanza needs to be removed. My rather sketchy comprehension of iptables rules indicates that I could remove the ! -s 192.168.1.1/24 part of this rule and leave the rest intact, thereby winding up with a rule that will accomplish the end at which I'm aiming (dropping ssh log-in attempts that occur more frequently than twice in a 10 second interval). So, is my deduction about that correct?

Yup and yup
make sure to ensure a method of access in case you bork the iptables rules and prevent access to the server (like a crontask of resetting rules) unless you have some alternate access to it.
Then test it

Edit:
You might even try conversejs. Basically, it's a xmpp client but browser based. That way you can use a cli-based one (or whatever) and whoever else just use the web one. The problem here would be having to setup a webserver which invites its own whole field of complexity. I just tried it and it's basically a clone of https://conversejs.org/ itself. Nifty!

As for installing apache - watch that ram. apache uses a lot and could overwhelm a low-end VPS.

Further edit:
JappixApp has a pretty nice browser based xmpp client. It feels like a actual program meant for xmpp (opposed to conversejs, which is meant to be integrated into stuff).