Happy IPv6 test day, part 2

In my first post in this small series, I closed without addressing matters of securing an IPv6 connection, and in matters of debugging where a connection failure is occurring. Thinking about it, the diagnostic post needs to come first, because tightening down a conneciton can cause hard to diagnose symptoms. So, on to diagnosis ...

We examined the interface results last time. Looking at just the routing related to ipv6 is straightfowrard as well:

Some familiar tools:

/sbin/ifconfig eth0
/sbin/ifconfig sit1
/sbin/route -A inet6

So using those tools:

[herrold@hostname ~]$ /sbin/ifconfig sit1
sit1      Link encap:IPv6-in-IPv4
          inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
          inet6 addr: fe80::4cf2:1c/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:1691 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1693 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:177195 (173.0 KiB)  TX bytes:210468 (205.5 KiB)

[herrold@hostname ~]$ /sbin/route -n -A inet6 | grep 2604
2604:aa:bb:cc::/64      ::          U     256    1658       0 sit1
2604:aa:bb:cc::/128     ::          U       0       0       2 lo
2604:aa:bb:cc::2/128    ::          U       0    1691       1 lo
[herrold@mailhub ~]$   

That is a pretty ordinary routing table for a non-gateway endpoint. Off-box traffic (to the '/64' netmask) is handed to the sit interface, and local traffic (to the '/128') retained on the local lo interface

We use a unfamiliar tool: ping6 -- The common '127.0.0.1' localhost has a new form under ipv6:

ping6 ::1 -c 2

and testing

[root@hostname ~]# ping6 ::1 -c 2
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=0 ttl=64 time=0.157 ms
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.132 ms

--- ::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.132/0.144/0.157/0.017 ms, pipe 2
[root@ostname ~]# 

And we can ping by IP on the 'Global' link, both on the local end, and remotely with differing transit times for the packets:

Looking at the network connections, we examine the tunelling interface:

[root@hostname ~]# /sbin/ifconfig sit1
sit1      Link encap:IPv6-in-IPv4
          inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
          inet6 addr: fe80::4cf2:1c/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:1714 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1731 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:179587 (175.3 KiB)  TX bytes:215180 (210.1 KiB)

[root@hostname ~]# ping6 2604:aa:bb:cc::2 -c 2
PING 2604:aa:bb:cc::2(2604:aa:bb:cc::2) 56 data bytes
64 bytes from 2604:aa:bb:cc::2: icmp_seq=0 ttl=64 time=0.135 ms
64 bytes from 2604:aa:bb:cc::2: icmp_seq=1 ttl=64 time=0.137 ms

--- 2604:aa:bb:cc::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.135/0.136/0.137/0.001 ms, pipe 2
[root@hostname ~]# ping6 2604:aa:bb:cc::1 -c 2
PING 2604:aa:bb:cc::1(2604:aa:bb:cc::1) 56 data bytes
64 bytes from 2604:aa:bb:cc::1: icmp_seq=0 ttl=64 time=55.1 ms
64 bytes from 2604:aa:bb:cc::1: icmp_seq=1 ttl=64 time=53.7 ms

--- 2604:8800:100:bb::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 53.781/54.473/55.165/0.692 ms, pipe 2
[root@hostname ~]# 

Turning to DNS and name resoluton, it is quite familiar. One does not need an IPv6 link to query nameservers and receive back results, as they will answer questions _about_ ipv6 hostnames ('AAAA' records) to any authorized inquirant. Try these:

dig +trace www.ipv6.sixxs.net
dig www.kame.net aaaa 

I get answers like this:

[herrold@centos-5 ~]$ dig www.kame.net aaaa

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> www.kame.net aaaa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45595
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;www.kame.net.                  IN      AAAA

;; ANSWER SECTION:
www.kame.net.           85164   IN      CNAME   orange.kame.net.
orange.kame.net.        85164   IN      AAAA    2001:200:dff:fff1:216:3eff:feb1:44d7

;; AUTHORITY SECTION:
kame.net.               85164   IN      NS      mango.itojun.org.
kame.net.               85164   IN      NS      orange.kame.net.

;; ADDITIONAL SECTION:
mango.itojun.org.       2364    IN      A       210.155.141.200
mango.itojun.org.       2364    IN      AAAA    2001:2f0:0:8800:206:5bff:fe8d:940
mango.itojun.org.       2364    IN      AAAA    2001:2f0:0:8800::1:1

;; Query time: 1 msec
;; SERVER: 10.16.1.112#53(10.16.1.112)
;; WHEN: Thu Jun  9 17:17:20 2011
;; MSG SIZE  rcvd: 195

[herrold@centos-5 ~]$

which is certainbly a mess to read -- let's trim out the interesting parts:

[herrold@centos-5 ~]$ dig www.kame.net aaaa
;; ANSWER SECTION:
www.kame.net.           85164   IN      CNAME   orange.kame.net.
orange.kame.net.        85164   IN      AAAA    2001:200:dff:fff1:216:3eff:feb1:44d7 

Which is the familiar information: a CNAME record is pointed in fact at a AAAA record at a ipv6 -type IP. We can ping (ping6) it by IP:

[root@hostname ~]# ping6 2001:200:dff:fff1:216:3eff:feb1:44d7 -c 2
PING 2001:200:dff:fff1:216:3eff:feb1:44d7(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=0 ttl=52 time=246 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=52 time=256 ms

--- 2001:200:dff:fff1:216:3eff:feb1:44d7 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 246.833/251.705/256.577/4.872 ms, pipe 2
[root@hostname ~]#

or ping it by name, as DNS is working:

<[root@hostname ~]# ping6 www.kame.net -c 2
PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=0 ttl=52 time=227 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=52 time=244 ms

--- www.kame.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1008ms
rtt min/avg/max/mdev = 227.291/235.678/244.066/8.401 ms, pipe 2
[root@hostname ~]# 

Some other examples to try as 'beacons' might include:

ping6 2604:8800:100:9a::1 -c 2
ping6 2001:200:0:8002:203:47ff:fea5:3085 -c 2
ping6 ftp.ipv6.uni-muenster.de -c 2
ping6 -I eth0 ipv6.google.com -c 2 

So the familiar diagnostic methods of examining interfaces, checking routing, testing connectivity by IP, and connectvity after resolution by name are all present

Happy IPv6 test day

There is a 'ipv6 readiness testing day' today, April June 8, 2011, and so it seems appropriate to post my personal checklist for putting a CentOS box up on that network fabric

• Apply for an account with SixXs. Their reply takes a couple of days, as it is a volunteer run organization
• Have a deployed, updated, and hardened unit at a routable static IPv4 address
• Amend /etc/sysconfig/iptables to include a line passing the tunnelling protocol. I place the entry after the IPSEC protocol entries in a stock setup. Restart iptables
  

  ... 
  -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
  -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
  # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  -A RH-Firewall-1-INPUT -p ipv6 -j ACCEPT
  # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ... 

• Strip out any previous efforts at disabling the ipv6 / net-pf-10 kernel modules from loading in /etc/modules.conf, and in the files sourced in /etc/modprobe.d/ . Then rebuild the modules dependency table: /sbin/depmod -a
• Amend /etc/sysconfig/network to carry the following lines:
  

  #
  NETWORKING_IPV6=yes
  IPV6INIT=yes
  IPV6FORWARDING=yes
  IPV6_DEFAULTDEV=sit1
  #

  Which anticipates that the configuration details for the ipv6 tunnel will live in a file: /etc/sysconfig/network-scripts/ifcfg-sit1
• and add that mentioned file: /etc/sysconfig/network-scripts/ifcfg-sit1 -- I have elided site-specific details as to IP addresses with: aa.bb.cc and aa:bb:cc placeholders
  

  #
  DEVICE=sit1
  BOOTPROTO=none
  ONBOOT=yes
  IPV6INIT=yes
  IPV6_TUNNELNAME="SixXS"
  #
  IPV6_AUTOTUNNEL=yes
  PHYSDEV=eth0
  IPV6_ROUTER=yes
  #
  IPV6TUNNELIPV4="38.229.76.3"
  #    38.229.76.3 is the remote end of the tunnel at the tunnel broker
  IPV6TUNNELIPV4LOCAL="198.aa.bb.cc"
  #    198.aa.bb.cc is the local ipv4 static IP
  IPV6ADDR="2604:aa:bb:cc::2/64"
  #    2604:aa:bb:cc::2/64 shows both the local gateway IP, and netmask
  #    the remote end gateway IP is by convention, the :1 
  IPV6_MTU="1280"
  TYPE=sit
  # 

At this point, simply restarting networking should bring up the ipv6 link, and properly route it -- so: /sbin/service network restart

The interfaces will look something like this:

[herrold@nostname ~]$ /sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:01:02:aa:bb:cc
          inet addr:76.aa.bb.cc  Bcast:76.aa.bb.dd  Mask:255.255.255.248
          inet6 addr: fe80::201:aaff:bb05:cc16/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11088057 errors:0 dropped:0 overruns:1 frame:0
          TX packets:10668738 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1726307345 (1.6 GiB)  TX bytes:3178496052 (2.9 GiB)
          Interrupt:3 Base address:0x6f80

[herrold@hostname ~]$ /sbin/ifconfig sit1
sit1      Link encap:IPv6-in-IPv4
          inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
          inet6 addr: fe80::bbf2:cc1c/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:500 errors:0 dropped:0 overruns:0 frame:0
          TX packets:502 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:53331 (52.0 KiB)  TX bytes:62784 (61.3 KiB)

[herrold@hostname ~]$ 

To wrap this up, ipv6 hardening, and connection debugging are worthy topics, and it may well be that a cautious sysadmin wants to lock down /etc/sysconfig/ip6tables and examine how one has hardened /etc/hosts.deny ... But rather than rush out content (I have a couple of mailing list posts I need to re-work), I'll leave these for later posts, while you, gentle reader, go apply for an account at a tunnel broker

What not to buy: Dynex 1.3MP Webcam

I've spent the time across the weekend, tinkering with a USB webcam -- particularly a Dynex 1.3MP Webcam (USB ID: 0x19ff:0x0102 ). As I recall, Dynex is a BestBuy house brand. The Linux USB device driver support table indicates that the device is supported under _some_ Linux variant

The need was occasioned because some small animal, probably a groundsquirrel, has been digging in the garden of missus, and she wanted confirmation on what to go after. The local cat, Malaki, heard it and darted to the door, but I was too late letting him out to track down the intruder ... this time

My laptop at home has been my primary compute platform there, since I crushed my ankle late last December. I still need to post a page with all the gory x-ray details, to go along with the twitter pictures I sent along the way with recovery. The medical bill cost was staggering as well, and I'll sanitize and post details of that as well. Back to the laptop -- it runs a reasonably stock CentOS 5 most of the time, except when I've been trialling rebuilds of part of Red Hat's '6' series SRPM rebuilds

The seemingly needed 'uvcvideo' video driver was present, and I forced it to load, at the cost of the machine locking up in short order thereafter. I had to power cycle the unit to recover use of it. Hmmm ...

So I went looking for an application to pull content off of the newly present /dev/video0, and turned to the native 'ekiga' that CentOS 5 carries. It refused to acknowledge anything useful at that device, and so ... I had to power cycle the unit to recover use of it. Hmmm ...

Perhaps it was 'ekiga'. So I set out to solve the needed packaging to attain a current 'zoneminder' ... a bit more complex chain:

06:42:44 PM libgcrypt-devel-1.4.4-5.el5
06:42:44 PM libgpg-error-devel-1.4-2
06:42:46 PM gnutls-devel-1.4.1-3.el5_4.8
06:42:47 PM pcre-devel-6.6-6.el5_6.1
06:44:49 PM perl-MIME-Types-1.19-2orc
06:46:55 PM perl-TimeDate-1.16-5.el5
06:47:02 PM perl-MailTools-1.74-1orc
06:47:38 PM perl-DateManip-5.44-1.2.1
06:47:59 PM perl-DBD-MySQL-3.0007-2.el5
07:19:55 PM perl-PHP-Serialization-0.27-4orc
07:20:50 PM perl-MIME-Lite-3.01-5orc
07:23:33 PM perl-IO-Stringy-2.108-3.orc
07:23:54 PM perl-MIME-tools-5.411a-12orc
07:34:34 PM perl-IO-Zlib-1.10-1orc
07:43:10 PM perl-Compress-Raw-Zlib-2.027-1orc
07:47:54 PM perl-Archive-Zip-1.16-1.2.1
07:48:05 PM perl-Archive-Tar-1.39.1-1.el5_5.2
07:49:54 PM php-pdo-5.1.6-27.el5_5.3
07:49:55 PM php-mysql-5.1.6-27.el5_5.3
07:50:28 PM perl-Module-Load-0.10-3orc
07:51:38 PM perl-Device-SerialPort-1.002-3orc
07:51:49 PM zoneminder-1.23.3-2orc

and went through the very nicely done configuration. Oops -- it wants a mysql database server running to save state:

07:59:18 PM mysql-server-5.0.77-4.el5_6.6
08:03:20 PM mysql-test-5.0.77-4.el5_6.6

Zoneminder was willing to admit it could read /dev/video0 but all it returned was a black image. Grrr. ... and then after a few minutes, the laptop locked up again, and I had to power cycle the unit to recover use of it. Hmmm ..

So I spent a few minutes with Google doing some research, and found what looks like a ratehr nice little application for USB frame grabbing called: gideo -- see: A GTK video grabber designed with spca5xx components. Building it dragged in the Gnome / GTK development environment of thirty or so packages, and I only had to fix up a dependency's .spec file to handle Red Hat's multilib conventions

05:27:56 PM libtiff-devel-3.8.2-7.el5_6.7
05:29:52 PM gideo-0.1-1orc
05:43:18 PM SDL_image-1.2.10-2orc
05:43:18 PM SDL_image-devel-1.2.10-2orc

But now, 'gideo' is unwilling to admit, or loading the module is unwilling to produce a live /dev/video0, and ... you guessed it: The laptop locked up again, and I had to power cycle the unit to recover use of it

I think perhaps I'll try a different video camera

hitting the ground running

I've mentioned creating and injecting a root ssh key into a new instance. The images we run are deployed with ssh enabled and not TCP wrappered; we COULD wrapper them and use the 'add an exception for ssh from a single IP' tool which the PMman web control interface has, but we have found the support load fallout from people just getting started is too high. Once they have deployed and hardened a couple of boxes, they 'get it and can use the 'lock from all' web tool, and then add a single IP if their taste runs to web tools

The very next step I take as to each machine I administer, is to run a hardening script. While I have published an outline here, I use a script rather than reading and scrape and pasting from that outline. This step is done through a script, not because I think I WILL forget something, but because I know the script will NOT forget anything, and is written to perform the hardening process in an idempotent fashion -- that is, when done, finishing the same end result, time after time. One path to get to better host security is to have good processes, consciously designed, systematically applied, and continuously improved

herrold@centos-5 admin]$ ./hardening.sh hostname.pmman.net
The authenticity of host 'hostname.pmman.net (198.178.231.xyz)' can't be established.
RSA key fingerprint is 86:6e:84:e0:27:57:dd:4d:1f:88:82:fc:42:1d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'hostname.pmman.net,198.178.231.xyz' (RSA) to the list of known hosts.
hosts.allow                                   100%  488     0.5KB/s   00:00
hosts.deny                                    100%  390     0.4KB/s   00:00
iptables                                      100% 1337     1.3KB/s   00:00
sshd_config                                   100% 3325     3.3KB/s   00:00
README                                        100%  897     0.9KB/s   00:00
rollup.pem                                    100%    0     0.0KB/s   00:00
openssl.cnf                                   100% 9682     9.5KB/s   00:00
arm-pmman.sh                                  100%  363     0.4KB/s   00:00
sa-update-local-NOTES                         100%  877     0.9KB/s   00:00
sa-update-local                               100%  117     0.1KB/s   00:00
logwatch.conf                                 100%   80     0.1KB/s   00:00
rollup.pem                                    100%    0     0.0KB/s   00:00
Package sendmail-8.13.8-8.el5.x86_64 already installed and latest version
Package 1:make-3.81-3.el5.x86_64 already installed and latest version
Package m4-1.4.15-2orc.x86_64 already installed and latest version
Package iputils-20020927-46.el5.x86_64 already installed and latest version
logwatch.conf                                 100%   80     0.1KB/s   00:00
Stopping crond: cannot stop crond: crond is not running.[FAILED]
Starting crond: [  OK  ]
Shutting down sendmail: [FAILED]
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
Flushing firewall rules: [  OK  ]
Setting chains to policy ACCEPT: filter [  OK  ]
Unloading iptables modules: [  OK  ]
Applying iptables firewall rules: [  OK  ]
Loading additional iptables modules: ip_conntrack_netbios_ns [  OK  ]
Stopping auditd: [FAILED]
Starting auditd: [  OK  ]
/etc/aliases: 76 aliases, longest 10 bytes, 765 bytes total

info: inspecting /etc/aliases  for a root email forwarder off the box
# Person who should get root's mail
#root:          marc

info: 1. do you want fail2ban -- if so, run: ./fix-fail2ban.sh hostname.pmman.net

info: 2. updates are not run by this script: consider running:
   ssh -l root hostname.pmman.net yum -y -q upgrade --enablerepo=pmman-mail

info: 3. verify that root's email is properly handled

info: 4. now:           ssh -l root hostname.pmman.net
                cd /root/hardening/

   and do some patching and service restarting ...
[herrold@centos-5 admin]$ 

Note: the IP is obscured, and the host name and ssh host key altered. The edit to add an opff-box alias entry for root's email is to centralize all the miscellaneous cron and asynchronous notifications off the box, to centrally monitored point

Then as noted before, this is a stock CentOS 5 image, and so needs some further tightening done and updates run. I have long since scripted that process:

[herrold@centos-5 admin]$ ./fix-fail2ban.sh hostname.pmman.net
local-fb-fix.sh                               100%  256     0.3KB/s   00:00
Stopping fail2ban: [FAILED]
Starting fail2ban: [  OK  ]
[herrold@centos-5 admin]$ ssh -l root hostname.pmman.net yum -y -q upgrade --enablerepo=pmman-mail
[herrold@centos-5 admin]$ 

Then, as suggested, the edits on the remote machine

[root@vm175551137 hardening]# netstat -pant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      3641/sshd
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      2627/sendmail: acce
tcp        0    240 198.178.231.xyz:22          76.242.0.abc:41936           ESTABLISHED 3593/0
[root@vm175551137 hardening]# history
    1  cd /etc/
    2  joe aliases
    3  yum install ipsec-tools
    4  rm *~
    5  newaliases
    6  cd /root/hardening/
    7  ls
    8  joe /etc/ssh/sshd_config
    9  /sbin/service sshd restart
   10  ls
   11  cp hosts.allow hosts.deny /etc
   12  joe iptables /etc/sysconfig/iptables
   13  /sbin/service iptables restart
   14  netstat -pant
   15  history
[root@vm175551137 hardening]# reboot 

Broadcast message from root (pts/0) (Wed Dec 22 14:47:10 2010):

The system is going down for reboot NOW!
[root@vm175551137 hardening]# Connection to hostname.pmman.net closed by remote host.
Connection to hostname.pmman.net closed.
[herrold@centos-5 admin]$ 

I added the ipsec-tools in support of an application this particular unit will be performing. The reboot at the end is for good measure to apply any new kernel and libraries through a clean boot. The 'true' hostname will be picked up from DNS PTR records, once that has been done already, after a reboot, as well

two minutes on keyed ssh access

In a Linux box, in BSD or derived such as under OS/X, or under Windows in Putty, a person can generate a LOCAL keypair which is used for keyed SSH access to such Virtual Machine instances. I have completely moved away from password based external access for all new instances, as keys carefully managed are demonstrably safer

So you know: There is some heat, but not a lot of thoughtful light about permitting and using root ssh access. Some not well though out security policies have a phobic avoidance of such. I'll address the matter in a later post, discussing hardening generally, sshd config file hardening, remote syslogs, TCP wrappers, iptables, and dynamic dictionary attack response

For the time being, let's put to one side and get past that security design choice rant, and accept that at least initially, a PMman instance has already made a short term choice for setting up access and for management of such units which are running CentOS or others following the Red Hat approach for management of instances [i.e., not SuSE/SLES, Debian family, nor the BSDs]

Under such Linux, this looks like this:

$ # create a high strength passphrase
$ # I have written of gen-pw.sh before 
$ gen-pw.sh  -a
a2Wa4aSaLWkRac
$ cd ~
$ cd .ssh
$ ssh-keygen -t dsa -f pippin.pmman.net.dsa

$ # there is a passphrase prompt here and 
$ # we use that: a2Wa4aSaLWkRac   
$ # -- also make a record of it in a safe place
$ # -- if one maintains multiple keys per box, it can be a 
$ # chore to manage this -- but see: man ssh-agent

$ #       this generated ~userid/.ssh/hostname.pmman.net.dsa    
$ #       [the private part] ... and 
$ #               ~userid/.ssh/hostname.pmman.net.dsa.pub   
$ #       [the PUBLIC part

$ cat ~userid/.ssh/hostname.pmman.net.dsa.pub

and scrape and place it in your mouse pastebuffer, and proceed to the web interface. The -f file's name 'hostname.pmman.net.dsa' is arbitrary, but chosen to be mnemonic

Then add a new stanza to: ~userid/.ssh/config like this:

#
Host                    hostname32.pmman.net hostname64.pmman.net
#  optionally one can make a note of the passphrase here, but 
#  at the risk of exposing such if a local dire read compromise
#  is experienced, or a backup of such falls into untrusted hands
IdentityFile            /home/userid/.ssh/hostname.pmman.net.dsa
PasswordAuthentication  no
Protocol                2
PubkeyAuthentication    yes
#

Note here a key may be used on more than one host; that is, we can add the same public key into /root/.ssh/authorized_keys of more than one unit -- here, both a 32 bit and a 64 bit instance with similar hostnames. But I get ahead of myself ...

Using a secure means, we need to transfer taht public key to a remote instance, and to add it to the right file; Here, we use the SSL protected web interface under the PMman machine management interface for a given machine, in the [more] menu, first item. By placing the public part into the web form box, the management backend at the datacenter, will be validated as to form, and then place that public key into ROOT's /root/.ssh/authorized_keys file

At that point, one can then ssh to that remote box as root, accept the host key, and take steps for hardening, adding a working userid, and so forth

loop -de- loop

As I count it at the moment, I am building and using content from more than eight loop mounted ISOs on a principal NFS, TFTP and 'next', and FTP server in the internal network

Red Hat has updates for 4.9, and 5.6 in beta; CentOS is in QA on a initial '6' release; I am doing private builds for a Fortune 50 on some backports out of RawHide and from some local packaging; and I am working on a 'back of the envelope' design and test to try to get control of the huge bloat on Red Hat ISO space for installs, to see if I can get a trimmed minimal installer for i386, x86_64, ppc[64] and s390x down to a single piece of CD sized ISO media. Then there is my favorite of the minimal wire install image, again which I package up into an ISO

Going forward, we will see more of encrypted filsystems across loop devices, and that will also put load on here. It may be time for the kernel folks to consider bumping that limit to 16

As such I regularly crest over the stock eight provided loop devices. To address this without a reboot, one simply has to:

# shutdown all uses of loop devices, so we can remove the module
/sbin/rmmod loop
echo "options loop max_loop=255" > /etc/modprobe.d/loop.local.conf
/sbin/depmod -a
/sbin/modprobe loop 

Note: that 'depmod' may not be strictly required, but will in any event be harmless, so I do it -- heck, I still type sync ; sync before rebooting a box, and I KNOW that is not needed any more. The force of habit ...

I add the suffix .conf on that file, because I was scolded by a Debian box a couple weeks ago on the topic; it seems that they are deprecating sourcing files in /etc/modprobe.d/ lacking such. Since when did Linux starting use file name suffixes to determine a file's content? -- at least it is not required to be in 8.3 format

Another approach is doing it with hard-coded values at boot time, with sysctl.conf or such

---

Tip of the hat to Paul Howarth on the SELinux rant I went off on last week; The interaction of loop mounted ISOs, and mounts in the FTP space of a filesystem can also be addressed with options to the mount command, and in the /etc/fstab with context= choices. He writes and points out:

I use context mounts to avoid it, e.g. in fstab:

/path/to/CentOS-5.5-x86_64-bin-DVD-1of2.iso
   /path/to/dvd1 iso9660
   _netdev,ro,loop,fscontext=system_u:object_r:public_content_t:s0
   0 0

... sorry about the funky line wrapping, but there is just no good way to display really long /etc/fstab entries

later, bye

CentOS is not for some people -- I get it and there is no sense getting agitated about it

17:20 rictec> regret to informe that i will have to un-install Centos as soon as i find the un-installer
17:21 orc_emac> rictec: we do not publish one, but it is this:
   as root:
   dd if=/dev/zero of=/dev/sda bs=512 count=1
17:21 orc_emac> as it is so easy to remember, we don't bother publishing one

'later, bye'

---

10 Dec 2010: reformatted due to some rendering issue reports