Have you ever wondered how long it would take to create a 32768 bit RSA key with ssh-keygen? Well, I did.
$ time ssh-keygen -t rsa -b 32768 -f ~/.ssh/tmp32768 -N foobar -q real 244m31.259s user 244m15.664s sys 0m4.736s
In other words, on my test system (AMD X2 CPU with 1.8 GHz per core) it took ca. 4 hours. This is likely very dependent on how much entropy you can get (and how fast), so take the numbers with a grain of salt. A second key with 32767 bits (one less) took 16 hours, for instance.
The resulting tmp32768 (private key) file is ca. 25 KB big, the tmp32768.pub (public key) file is 5 KB big.
There's likely no noticeable performance hit for ssh or scp AFAICS, as all data transfers are done with a symmetrical session key, not the RSA key itself. Only the initial connection "handshake" will take ca. 40 seconds longer...
And yes, 32768 is the maximum RSA key size you can currently create with OpenSSH, go file a bug report if that's not enough for you ;-) However, as I then noticed, this key will not actually work. When you put it in some authorized_keys file and try to login, the handshake will fail and the server-side will see the following error in /var/log/auth.log:
sshd[xxxxxx]: error: RSA_public_decrypt failed: error:04067069:lib(4):func(103):reason(105)
I first thought I found an off-by-one error, but the 32767 bit key (one bit less) didn't work either. After looking through the OpenSSH and OpenSSL code as well as the RSA_private_decrypt(3SSL) manpage a bit, I saw that OpenSSH uses the RSA_PKCS1_PADDING parameter. My current theory is thus that some padding is making the key not work. I'm now creating a key with 11 bits less bits than 32768, let's see what happens. For the record, a key with 16384 bits does work just fine.
Anyway, I'll probably report this as "bug" (more a theoretical than a practical problem, though) as ssh-keygen let's you generate RSA keys which will never work in practice...
I've just updated my DIY secure pseudo-DDNS setup using ssh article/HOWTO a bit, in order to make it simpler to set up (no more extra scripts required) and a bit more secure (by using command= and no-port-forwarding,no-X11-forwarding,no-agent-forwarding in the /home/user/.ssh/authorized_keys file, for instance).
If you've considered employing such as solution please revisit the article for updated instructions.
Here's a quick HOWTO for setting up your own secure pseudo-dynamic DNS (DDNS) server.
It's not a "real" DDNS service, i.e. you won't be able to use standard DNS tools or protocols to talk to the server, but it covers 98% of all functionality I expect from a service such as DynDNS or similar ones: It tells me the IP address of a certain box which doesn't have a static IP address (e.g. my home-server).
On the homeserver:
5,15,25,35,45,55 * * * * user ssh -x user@publicserver ls
On the publicserver:
command="echo $SSH_CLIENT | cut -d \" \" -f 1 > /home/user/homeserverip.txt && chmod 644 /home/user/homeserverip.txt",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAAAAAAA...AAAAAAA user@homeserver
So to summarize: the homeserver's user simply executes the above commands on the remote publicserver, which in turn abuses the $SSH_CLIENT environment variable which contains the public IP the ssh connection was coming from (which is exactly what we're looking for). We store that IP in the homeserverip.txt file, which will always contain the latest-known IP address of the homeserver (because of the cronjob).
You can now retrieve the current IP address of your homeserver easily from anywhere (e.g. from your laptop when you're in another, possibly hostile network) in order to connect to your homeserver:
$ ssh -x otheruser@publicserver cat /home/user/homeserverip.txt
To make this a bit more convenient you can add a shell alias (e.g. into ~/.bashrc):
alias homeserverip='ssh -x otheruser@publicserver cat /home/user/homeserverip.txt'
Or, to conveniently login to your homeserver as johndoe:
alias homeserverlogin='ssh -x johndoe@`ssh -x otheruser@publicserver cat /home/user/homeserverip.txt`'
This may not be the most elegant solution, and it has a number of drawbacks when compared to services such as DynDNS, but it's sufficient for me and it also has some advantages:
Personally I'm currently using this mechanism for two things, more might follow:
So far it works pretty nicely.
Update 2008-06-24: Various fixes and simplifications. SSH key must be password-less. Don't run cronjob once per minute, that's overkill.
Update 2008-07-02: Simplify setup by removing the need for extra scripts. Limit the commands the user can perform via ssh in the authorized_keys file. Make the RSA keys 4096 bits strong.
I have always wondered whether it is possible to "hijack" an already running X11 application on a remote server...
Say I have a box at home which has a running X11 server with many applications, e.g. Firefox, xchat, xmms, whatever. Now, say I'm somewhere else with my laptop and login with "
ssh -X" into my home box. I can now start X11 applications and they will be shown on my laptop screen. So far so good.
But... how can I get one of the applications that were already running before I logged in from remote to be displayed on my laptop screen? Is it possible? How?
Some interesting Free Software releases:
Lots of stuff to try out...