How to get a Domain name???

[#1]

I'd like to be able to access my home computer(s) externally.
Presumably  I'd need a domain name - preferably free of charge 
I'm not planning on providing a web server or mail server, so it wouldn't need to be hosted anywhere.
My DNS records could be periodically amended by a program checking if my dynamic ip address has changed.
The actual domain name wouldn't matter too much as it would only be used occasionally by services such as ssh.
Do such services - ideally free - actually exist?

[#2]

I don't see the connection between accessing your computers externally and a domain name

[#3]

Don't really see the connection either. But there are plenty of Dynamic DNS services (free and paid) that will give you an easy to remember host name and keep track of/update dynamic IP address changes

[#4]

be cheaper in the long run to pay a fiver for a static ip address, if I want to access anything remotely I just use my static ip rather than any domain names I have.

[#5]

dyndns is free and works with the 582n

[#6]

Hmmm...if you just want to access your home computer externally (and aren't running a website or mail server), why not simply run TeamViewer (free for personal use) or Logmein?
No domain name or fixed IP address is needed.
And no firewall problems.

[#7]

It's a good idea - but you are handing all your keys protecting access to a 3rd party.
If they have your password, they can remotely help themselves to your information.
So there are big firewall problems!
I've managed to get a free domain name; now I've just got to:-
Open a port on my router to accept unsolicited input.
Create a public/private key pair for ssh.
Place copies of my public key where it can be accessed as needed.
Then just use ssh (and associated commands) to access my PC.
[I've tested the above with a underpowered netbook - it works with no noticeable delay on 2048 bit keys]

[#8]

Quote from: vilefoxdemonofdoom

Place copies of my public key where it can be accessed as needed.

You shouldn't need your public key copied anywhere else, unless I've misunderstood what it is you're trying to achieve?

Quote

[I've tested the above with a underpowered netbook - it works with no noticeable delay on 2048 bit keys]

Note that the 2048 key length only applies to the public-private key pair used for initial authentication. They are also used to exchange a much smaller (e.g. 128 bit) symmetrical key which is then used for the actual transfer of data hence why there shouldn't be any discernable delay in use even on underpowered devices.

[#9]

My understanding is that the public key needs to exist on both ends of the link?
I was simply expecting that the initial setup, involving the generation of large numbers - and checking that they are prime (to a high "probability") to be very CPU intensive.
I appreciate your point about the session key.
The biggest problem seems to be (as always) coming up with a memorable pass phrase. 

[#10]

Quote from: vilefoxdemonofdoom

My understanding is that the public key needs to exist on both ends of the link?

The public key needs only to reside at the server end, and will be tied to a particular username on the system. Only the holder of the corresponding private key will be able to successfully authenticate against it. There's no security required on the public key hence why you are not expected to have it to connect.

Quote

I was simply expecting that the initial setup, involving the generation of large numbers - and checking that they are prime (to a high "probability") to be very CPU intensive.

Gotcha. It is CPU intensive, but all things are relative.

Quote

The biggest problem seems to be (as always) coming up with a memorable pass phrase.

It's amazing really that the more choice you've got the harder it is to settle on one.... With an infinite number of options here that presents a challenge!
A technique I quite like is thinking of a phrase and taking the first letters of each word and using that as your passphrase. Assuming that doesn't end up resulting in anything like a dictionary word then it becomes secure (appearing somewhat 'random') whilst still being easy to remember by virtue it being directly linked to your phrase (but shorter hence easier to use, particularly on something like a touchscreen).

[#11]

I seem to recall an article by a ex-cracker who would take a database (from a broken web site) of user names and matching hashes.
He would then run his dictionaries of typical passwords against the user names to see if he could match the hashes.
He claimed a 70% success rate - but apparently he always spent a lot of additional time brute-forcing password attacks.
This was just so he could monitor fashions in "secure" passwords - and add them to his dictionaries for future use.
For example, transliterating letter o to zero, i to 1 and similar tricks is quite common; merging two words together (AOL style) is another common way.
Passwords that are required to contain a numeric character almost always contain just a single digit at the end...

[#12]

There have been quite a few analyses done over the years on large samples of real-world passwords and they nearly always conclude that we are generally very poor at picking 'random' passwords. As you say, most users tend to follow the same patterns over and over resulting in 'clever modifications' not being all that clever afterall.

[#13]

It wouldn't be to bad if there was some degree of consistency on the web...
Some sites require the the use of  numbers and special characters where others forbid them.
It gets a pain in the posterior trying to remember what password was used where (even with a clever scheme) when the rules keep changing.
Then there's the other problem of using a clever password on that encrypted backup,  but forgetting what it is next time you want to use it.

[#14]

Fully agree. I've suffered on both points... numerous times!!