So I did what any good programmer would do… I tried it anyways. It failed. So I fixed the bug and tried it again. That one failed. So I went to the forums and got another suggestion and tried that one. It failed, burned down, fell over and sank into the swamp. So Installed 6.06.1 and the FOURTH ONE STAYED.

So don’t try virtualmin with 7.1, unless you’re glutton for punishment too…

Please insert a rewritable or blank CD.

I hit the forums and found this very relevant discussion.[/url] Apparently the forums hit the forums… because their solution pointed to [url=http://www.xcdroast.org]www.xcdroast.org, who had this to say:

Linux Kernel 2.6.8 broke CD-Writing:
I had several reports that the last 2.6.x kernel broke CD-Writing using the ATAPI driver. Don’t update if you want to continue to use X-CD-Roast, or switch back to SCSI-emulation.
Update: When started from a root shell burning still works, but non-root mode is disabled by this kernel.

So the solution is to run the programs as root. I was able to burn my cd using:

root@Tiki:~# cdrecord dev=/dev/cdrw1 driveropts=burnfree -v -data /home/kato/Desktop/tmp/ubuntu-6.06.1-server-i386.iso

Looks like others used sudo k3d with comparable success.

I didn’t bother trying to figure out which program the “Write to Disk” command traces back to. But it looks like K3d already has a fix. Maybe Ubuntu will provide a fix soon, too…

Set up an RSA key to use instead of a password
This is an encrypted file which is used to replace your password, providing significant login security (there’s no way someone will guess one of these in the next 10,000 years).

This step assumes you are logged into the server where you will be ssh’ing to. To do this from the client, you create the keygen file as normal, but you then have to upload the id_rsa to your web server’s ~/.ssh/known_hosts (instead of copying it locally as shown below).

Here is the procedure for generating the keyfiles:

#generate the public/private key pair
#leave the passphrase blank (or you'll have to type it constantly)
kato@zephyr:~/$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kato/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kato/.ssh/id_rsa.
Your public key has been saved in /home/kato/.ssh/id_rsa.pub.
The key fingerprint is:
0d:a6:cd:1c:53:ab:b2:1b:b5:7e:ce:15:96:35:97:f9 kato@zephyr
kato@zephyr:~/.ssh$ cd /home/kato/.ssh
kato@zephyr:~/.ssh$ ls -l
-rw------- 1 kato kato 1675 2007-11-19 16:56 id_rsa
-rw-r--r-- 1 kato kato  393 2007-11-19 16:56 id_rsa.pub
#your server might show identity and identity.pub... that's fine, use those in place of id_rsa
$ cat id_rsa.pub >> authorized_keys
$ chmod 644 authorized_keys
kato@zephyr:~/.ssh$ ls -l
-rw-r--r-- 1 kato kato  214 2007-11-19 16:04 authorized_keys
-rw------- 1 kato kato 1675 2007-11-19 16:56 id_rsa
-rw-r--r-- 1 kato kato  393 2007-11-19 16:56 id_rsa.pub
#some older servers will require you to use authorized_keys2 for ssh2 clients!

Now download the private file (the one without .pub on the end) to your client. You will want to configure your client to load this keyfile automatically. This is easy enough with putty, for other clients, check out pageant (which can intercept password requests and supply the key).
[img]putty_keyfile.jpg:Loading ssh key into putty…[img]

1. First decide if you will be using SSH1 or SSH2 (or both). Most likely you’ll want to stick with SSH1 (until OpenSSH is installed at PPPL, or until SSH2 is installed, etc).
2. Generate public/private keypair for SSH1: [b]ssh-keygen[/b]. This will generate [b]~/.ssh/identity[/b] and [b]~/.ssh/identity.pub[/b].
3. Do this on each machine you want to access (to/from) using ssh (only need to do this once on the PPPL unix cluster)
4. Take all of the identity.pub files (which contain a public key on one line) and create an [b]~/.ssh/authorized_keys[/b] file by placing the contents of each separate identity.pub file on a single line of the [b]~/.ssh/authorized_keys[/b] file (then place on all sshable hosts).
5. For SSH2, use [b]ssh-keygen -t {rsa,dsa}[/b] (you choose between rsa keys or dsa keys, currently I use DSA), which will generate [b]~/.ssh/id_{dsa,rsa}[/b] and [b]~/.ssh/id_{dsa,rsa}.pub[/b].
6. Follow instructions for SSH1 keys, but instead generate a [b]~/.ssh/authorized_keys2[/b] file using the id_{dsa,rsa}.pub files.

Specify who can log in with ssh
From the cli, type:

groupadd sshaccess

Then add your login account:

usermod -a -G sshaccess kato

Configure SSH
On Ubuntu and Gentoo, open [b]/etc/ssh/sshd_config[/b]. Now we will tweak several properties:

1. Changing the Port will shut off 98% of the attacks on your ssh server. As long as you have the skills to get through the firewall, this is your best defense. To pick a port number which won’t conflict with any other apps, check out this comprehensive list of ports. I used port 27.
2. Turn off PermitRootLogin
3. Enable PubKeyAuthentication
4. Do not PermitEmptyPassword
5. Restrict users who can log in with AllowGroups
6. Enable logging with SysLogFacility and LogLevel

Here is what my finished script looks like:

# What ports, IPs and protocols we listen for
@@Port 27
 
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
 
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
 
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
 
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
 
# Logging
SyslogFacility AUTH
LogLevel INFO
 
# Authentication:
LoginGraceTime 120
@@PermitRootLogin no
StrictModes yes
 
#RSAAuthentication yes
@@PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys
 
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
@@RhostsRSAAuthentication no
# similar for protocol version 2
@@HostbasedAuthentication no
 
# To enable empty passwords, change to yes (NOT RECOMMENDED)
@@PermitEmptyPasswords no
 
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
 
# Change to no to disable tunnelled clear text passwords
@@PasswordAuthentication no
 
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
 
# Allow client to pass locale environment variables
AcceptEnv LANG LC_
@@AllowGroups termgroup
 
Subsystem sftp /usr/lib/openssh/sftp-server
 
UsePAM yes

References
Creating RSA and DSA keys for SSH
SSH User dentities
Creating SSH Key Pairs

Edit /etc/network/interfaces

Adjust as needed… here is a sample config for a linksys/d-link home network:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
 
# The loopback network interface
auto lo
iface lo inet loopback
 
# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
mapping hotplug
script grep
map eth0
 
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1