Author: Michael Lucas

Writer. Sysadmin. Owns this site.
Posted on

Replicating Routerboards

I needed to mass-configure MikroTik Routerboards. Each needed a very similar but not identical configuration: they would have a unique management IP, and a unique username and password for their VPN connection back to my employer’s headquarters. I don’t have time or desire to do this routine configuration myself, so I needed a method that would let a less technical person do the work.

You can back up and restore RouterOS configurations, but then I’d need to have the user do all sorts of pointy-clicky things to configure the device. Pointy-clicky is difficult to reliably reproduce. RouterOS also supports exporting the configuration as a script, but they warn that this script is not suitable for duplicating a system. I wound up using the export function, but modifying the resulting script to create a new configuration that could be loaded onto the new device.

All of this was tested with Routerboard 750s, running RouterOS 5.6. I used one device as a master, and a second to test loading the new configuration. I also created a list of hostnames, IP addresses, and VPN usernames and passwords. (My team will manage these devices remotely, so the user will never see the username and password. If I deployed more than a couple dozen boxes, I’d need a different auth scheme.)

First, make sure your Routerboard is in the default configuration. Reset to the factory defaults if necessary. Load the same version of RouterOS onto the new device as exists on your master device.

Log onto your master device. Configure it the way you want, and export the configuration.

admin@master> export file=cleanconfig
admin@master> file print
...
0 cleanconfig.rsc script 16 507 jan/02/1970 19:26:39
...

This file is the seed of my configuration script. copy it to your desktop. (The detail-oriented among you will note that my configuration should include “Set the system clock.” Feel free to stay after class and clean the blackboards as a reward.)

Unlike Cisco and its imitators, RouterOS isn’t modal. You don’t need to enter a configure mode to change the router. Instead, it has a hierarchical configuration method from the command line. For example, there’s an interface command, with an Ethernet subcommand. To work on the Ethernet interfaces, you would enter interface Ethernet. Starting a command with a leading slash tells RouterOS to go back to the root. Most of the actual commands within this level are fairly self-explanatory to anyone experienced with routers.

/interface ethernet
set 0 arp=enabled auto-negotiation=yes disabled=no full-duplex=yes l2mtu=1526 \
mac-address=00:0C:42:5A:D9:50 mtu=1500 name=ether1-gateway speed=100Mbps

The set command tells RouterOS to change a setting for an existing item. The Ethernet interface already exists, you just need to give it a configuration. Alternately, the add command tells RouterOS to add something new to a configuration, such as an IP address.

/ip address
add address=192.168.88.1/24 comment="default configuration" disabled=no \
interface=ether2-master-local network=192.168.88.0

The system has no IP address, so you must add one.

If your script tries to add something that already exists, it will fail. For example, if your configuration already has a DHCP client setting, adding a new, identical one will terminate your script early. For my application, I had to remove the following from my master configuration.

/interface ethernet switch
/interface wireless security-profiles
/ip hotspot profile
/ip hotspot user profile
/ip ipsec proposal
/queue type
/routing bgp instance
/routing ospf instance
/routing ospf area
/system routerboard settings
/user group
/interface ethernet switch port
/interface l2tp-server server
/interface ovpn-server server
/interface sstp-server server
/interface wireless align
/interface wireless sniffer
/interface wireless snooper
/ip accounting
/ip accounting web-access
/ip dhcp-client
/ip dhcp-server config
/ip firewall connection-tracking
/ip firewall nat
/ip firewall service
/ip hotspot service-port
/ip neighbor discovery
/ip proxy
/ip socks
/ip ssh
/ip traffic-flow
/ip upnp
/mpls
/mpls interface
/mpls ldp
/port firmware
/ppp aaa
/queue interface
/radius incoming
/routing bfd interface
/routing mme
/routing ospf network
/routing rip
/store
/system console
/system health
/system resource irq
/system upgrade mirror
/system watchdog
/tool bandwidth-server
/tool email
/tool graphing
/tool mac-server
/tool mac-server ping
/tool sms

I then had some items that were different in my desired configuration and the default configuration. For example, the default 750 configuration has a firewall. I needed a firewall configuration that had no overlap with the default configuration. I added entries at the beginning of my script to remove that configuration. Similarly, I didn’t want the default IP address on this device.

/ip pool remove 0
/ip dhcp-server network remove 0
/ip dns static remove 0
/ip firewall filter remove 3
/ip firewall filter remove 2
/ip firewall filter remove 1
/ip firewall filter remove 0
/system logging remove 3
/system logging remove 2
/system logging remove 1
/system logging remove 0
/ip address remove 0

Other parts were more tricky. I wanted to configure the Ethernet interfaces, but I didn’t want to change the MAC address of the interfaces. I removed the mac-addr statements from the Ethernet interface configuration.

Now that I have a clean master script, I copy it to a separate file for the slave configuration script. In the copy, I change the IP address, hostname, username, and passwords as necessary.

I could then copy the script to my target machine and run

admin@target> import configscript.rsc
admin@target>

If the script doesn’t exit silently, it failed. Compare the target platform’s new configuration to your script to see where it failed, or run your script piecemeal to see where it crashes.

This was a good day’s work to learn how to do, but now I can hand my script to a junior tech and tell him to set up a couple dozen of these without bothering me. It’ll save me days of my time in the long run.

Posted on

Book updates, August 2011

I completed a first draft of the OpenSSH book last night around 10:30PM EDT. It’s out for tech edit now. At this point, I’m going systematically through the tech edits and making sure I’ve corrected the earlier chapters. After that, the manuscript goes to copyediting. Once copyedit is complete, I’ll release the ebook and start contracting out the POD version.

I normally write both nonfiction and fiction simultaneously. When I get frustrated with one project, I switch to the other. The context switch clears my brain. When I return to the vexing project, I can approach the problem fresh and work through it quickly.

I decided to do two nonfiction projects simultaneously this summer. In retrospect, this was a mistake. When I got frustrated with one project, I switched to the other… and found myself still frustrated. Perhaps I can do two nonfiction projects simultaneously, but OpenSSH and OpenBSD have a lot in common. One is just a subset of the other. My frustrations would probably be reduced if I knew what I was doing, but if I knew what I was doing, I wouldn’t write the book.

Lesson learned. If I want to write two nonfiction books simultaneously, they must be wildly diverse.

The OpenBSD book has therefore moved slowly. It’s further complicated by moving over the next couple weeks. I’ll be full-out cranking on the OpenBSD book this fall, however.

I predicted that the OpenSSH book would be 30,000 words. The first draft came in at 29,977 words. I am amazed; usually my books come in at 25-50% over the predicted word count. Perhaps I’m learning. But I’m probably just lucky.

Posted on

Colin Harvey, RIP

This is off my usual track, but it’s my blog, so I’m free to do so.

Science fiction writer Colin Harvey died Monday, 15 August 2011, of an unexpected stroke, at age 50. He’d published several hard SF novels and edited a variety of anthologies.

I was lucky enough to have Colin in my writing critique group.

One of the ways to improve your writing is to exchange manuscripts with other people. By critiquing others’ work, and getting critiques on your own, you see what works and what doesn’t. (Strictly speaking, I should mention that the purpose of the critiques is not to improve the manuscript you just submitted, but to improve what you write in the future. You can’t do a huge amount to fix what you’ve already written.)

A good critique group is a weird thing. You want your critiquers to like what you’ve written. But you want them to assault your work with everything they have, point out every deficiency, and push you to make you better. The closest comparison I can make is to a martial arts school, where you help your partners improve even as you smack the crap out of them, being friendly and kind and forceful simultaneously. In a successful writing group, you develop unique friendships, even with people you don’t know. Colin was one of those friends.

I joined my current writing group at the beginning of 2007. Colin was a member. In the years since, Colin simultaneously beat the living crap out of my work and supported me as a writer. My work dramatically improved, thanks in large part to his efforts. (Not to discount the other crit group members; they’ve all been invaluable. Even Rob.)

I still have a copy of every message that has passed through the writing group since I joined. Rather than just say what a tragedy his loss is, I thought it might be more meaningful to extract some of what he said about writing and offer it here. It’s gauche to repost semi-private conversations, of course. I don’t believe Colin would mind these particular clips. He had a fantastic sense of humor, openly documented his life on his blog, and said all of this about my work on a mailing list archived on Yahoo Groups.

  • (On his well-deserved critiques of the first piece I submitted): “I’m aware that this mail reads like a thorough kicking, and I’m trying hard to find some positives”
  • (On receiving harsh critiques): “I’ll take this opportunity to thank you and all the others for the comments…”
  • (On theme in writing): I believe that the themes that a writer writes about come from within. So duplicity and betrayal feature largely in mine for reasons that even I don’t understand. I believe that if someone has enough belief and talent to write, then themes can’t be imposed. Topics or subjects can, but not theme.
  • (On any crit group member making a sale): “Congratulations”
  • (On synopsis): I think the whole point of the synopsis discussion is that various elements of the group have recognized that their work –as it stands– is already of publishable quality, but that there are barriers to that work being published. One of the barriers is the synopsis, or –as in most submissions generally– an inadequate synopsis. Yes, an agent / publisher will look at your first one, two or three chapters and it may be that the extract is sufficiently good to off-set an inferior synopsis. But many agents just don’t have or want to spend the time if they don’t have to. It’s all about shortening the odds.
  • (On scenes): Scenes should -for me- serve one of three purposes
    i ) To move the plot along
    ii) To set a scene or to
    iii) Illuminate the character(s) in it
  • (On advice from non-writers): Why are you letting a failed writer tell you what to write? And before you argue that — how many best-sellers has xxxxxx WRITTEN? How many awards has he won for his fiction? (Those are all rhetorical questions, btw. I know about lack of confidence – honest!)
  • (On research): I read as I go along. I never know what I need to read up on.
  • (On critiques): The whole point of crits is not to tell you what you do know, but to smack you in the side of the head from a completely unexpected direction.
  • (Whenever anybody said anything nice about his successes): Thank you,
  • (On vocabulary): recuperance? What sort of word is that? Did you just make it up?
  • (On getting published): Persistence, persistence, persistence.
  • (On future technology): I don’t see shaving disappearing anytime soon….
  • (On the Star Trek reboot): You went expecting a storyline? You’re clearly an optimist.
  • (on someone on the critique group mailing list whinging about the publishing industry): Rant on as much as you need to, as far as I’m concerned.
  • (after two years of discussing outlining novels versus winging the story, during which he converted me from a hard-core winger to a hard-core outliner, and I espouse the benefits of outlines to other group members): Oh, I am *so* enjoying the poacher-turned-gamekeeper aspect of this e-mail….
  • (On writing rules): The only ‘rule’ is if it works, do it.
  • (On the last piece of mine he critiqued): This is a very, very good story.

    • I could go on, and on, and on, but I’ve spent hours on this. And Colin would tell me to get back to writing my own work.

    Colin never stopped improving his work. And he never stopped improving mine, either. He recently wrote novels that he hadn’t had time to finish marketing. I want to see both Black Death and Ultramassive in print. The latter is cool SF, and the former scared the crap out of me.

    Colin left the writing group earlier this year, but he and I agreed to continue exchanging manuscripts in a less public forum. By sheer chance, we agreed to take a hiatus in August — we both had big family projects underway. If he’d spent the last month of his life reviewing my sewage work instead of spending time with his family, I’d feel pretty bad. If I’d still owed him a crit when he passed, I’d feel ghastly.

    Colin spent his last days with people more important to him than myself. And that’s how it should have been.

    Posted on

    ISC dhcpd and MAC prefixes

    We have a network at the office without a firewall. Several of our technical folks run a whole mess of oddball network protocols, and maintaining a network firewall would take more manpower than it’s worth. We hand these techs a network cable and tell them to not let their gear get broken into, and then heckle them mercilessly when their server becomes a haven for Eastern European porn.

    But the boss just got back from ClueCon, where he learned about a whole bunch of nasty exploits for older Cisco phones. These techs have VoIP phones on their desks. The decision was made to give the VoIP phones private addresses, overlaid on the public addresses. Yes, a firewall would be much better, but the maintenance overhead was too high in this situation.

    Our VoIP phones have have MAC addresses in particular ranges. For example, a certain model of phone has MAC addresses beginning with 00:03:e3, others begin with 00:03:6b, and the third begin with 00:07:eb. If a device’s MAC address begins with one of these, it should get an address in 172.19.22.0/24. Otherwise, it should get an address in the public pool of 192.0.2.0/24. I’m using ISC dhcpd 3.1.

    Start by breaking the devices into classes. Each class will have its own IP configuration. dhcpd has a pattern-matching feature that lets you match MAC addresses like this dhcpd.conf snippet.

    class "sip-phone" {
    match if (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:e3")
    or (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:6b")
    or (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:7:eb");
    log (info, (binary-to-ascii (16,8,":",substring(hardware, 0, 4))));
    }

    class "other" {
    match if not (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:e3")
    and not (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:3:6b")
    and not (binary-to-ascii (16,8,":",substring(hardware, 0, 4)) = "1:0:7:eb");
    log (info, (binary-to-ascii (16,8,":",substring(hardware, 0, 4))));
    }

    So, if a host has a hardware (MAC) address matching one of the patterns in the “sip-phone” class, it’ll be classified as a sip phone. If the hardware address doesn’t match anything in the sip-phone class, it’ll be classified as other.

    What does that horrible string mean? Read dhcp-eval for details, but here’s the short and nasty version. Inside dhcpd, hardware addresses are binary. The binary-to-ascii function transforms a binary field into characters. The 16,8,: tells binary-to-ascii how to parse the binary data and where to separate the characters. The substring function takes a small portion of the ASCII string, specifically places 0 through 4. The characters are a hardware label (a 1 means Ethernet) followed by a colon, followed by the MAC address. So, to match all Ethernet MAC addresses starting with 00:03:e3, we must search for 01:00:03:e3, shown without the leading zeroes as 1:0:3:e3.

    The Boolean logic around these comparisons groups the MAC addresses into classes by MAC.

    The interesting bit here is the “log” statement. I wanted to see how the binary-to-string and the substring functions mauled the original MAC address. This LAN has a sufficiently small DHCP request rate that I was able to log the first sixteen bytes of each hardware identifier (including the leading 01: for Ethernet). This helped me figure out what the heck I was finding as I struggled through dhcp-eval(5). These logs were written to the DHCP server log. Remove them when you’re done testing.

    In this dhcpd.conf snippet we assign the two classes separate address ranges.

    shared-network techs {
    subnet 172.19.22.0 netmask 255.255.255.0 {
    option routers 172.19.22.1;
    pool {
    allow members of "sip-phone";
    range 172.19.22.10 172.19.22.100;
    next-server 192.0.2.130;
    }
    }

    subnet 192.0.2.0 netmask 255.255.255.0 {
    option routers 192.0.2.1;
    pool {
    allow members of "other";
    range 192.0.2.100 192.0.2.200;
    }
    }
    }

    The DHCP server has an interface on this subnet. I added a private IP to the interface, so that it has both 192.0.2.0/24 and a 172.19.22.0/24 addresses. The shared-network statement tells the DHCP server to not be shocked when it sees both subnets on the local interface.

    So far, this works.

    UPDATE: To all the folks who say that this network could certainly be VLAN’d and firewalled. There is no technical reason this couldn’t happen. The problems are political. Political problems are just as real as technical problems.

    Posted on

    How to Lose your Job with SSH, part 2

    Like last week’s How to Lose your Job with SSH, Part 1, a less dramatic title for this would be Dynamic Port Forwarding with SSH, but that’s dreadfully dull.

    Many corporations try to tightly secure their network. Connections to the outside world are strictly limited. If you have a single open TCP/IP port to the outside world, however, you can leverage this into blanket Internet access by using your SSH client as a SOCKS proxy. This is called dynamic forwarding.

    SOCKS is a generic TCP/IP proxy. SOCKS tunnels arbitrary protocols, as long as the client program supports SOCKS. Many clients, including the major Web browsers, do.

    To do this, you would SSH from your client on the protected network to a server on the public Internet. The client opens a SOCKS proxy on a TCP port on the local machine. When a client connects to this proxy, the traffic is forwarded across the Internet to the SSH server. The SSH server processes the request and feeds the data back to you. It’s not a terribly fast proxy, but it is encrypted and it will bypass the corporate firewall and Web proxies.

    Use the -D flag to tell the OpenSSH client to use dynamic port forwarding. (You can do the same thing with PuTTY, but that’s a separate walk-through.)

    $ ssh -D localaddress:localport hostname

    If you don’t specify a local IP, the client automatically binds to 127.0.0.1.

    Here, I open a dynamic proxy on port 9999 to the server pride.blackhelicopters.org

    $ ssh -D 9999 pride.blackhelicopters.org

    Leaving the SSH session up, now go to the Web browser on the local machine. Somewhere in the browser preferences you’ll find a place for proxy servers. Tell your browser it has a proxy at 127.0.0.1 on port 9999. Save the settings and start browsing the Internet. Your Web browsing will be slow, but it’ll get you on the Internet.

    If I list a network-facing IP on my client, anyone who can connect to that port on the client can use my proxy.

    $ ssh -D 10.10.10.105:9999 pride.blackhelicopters.org

    This is, of course, a violation of the security policy at these security-sensitive companies. Doing it will get you fired.

    As a network administrator responsible for such an environment, what can you do about this?

  • If you run an external SSH server that your users need to log into, disable SSH forwarding with the AllowTcpForwarding option in sshd_config.
  • Watch your traffic. See how much traffic various protocols use on your network. This will not only help you catch SSH tunnels, it will help you catch any other sort of tunnel. You must know what is normal before you can catch strangeness, however.
  • You could forbid external SSH, and only permit protocols that can be proxies, such as Telnet.
  • You can set up a legitimate SOCKS server, with logging, and require all traffic pass through it. Anyone tunneling large amounts of traffic through the server will stand out in the logs.

    • Most of these solutions require the network administrator to know what happens on his network. You must have basic network awareness, in advance, or you’ll never find these people.

    And if you’re an end-user who creates his own SOCKS proxy in such an environment, gets caught, and gets fired for it, do let me know. I can always use a good laugh at someone else’s expense.

    Posted on

    Practical Packet Analysis, 2nd Edition

    The second edition of Chris Sanders‘ Practical Packet Analysis is about twice as large as the first edition and twice as useful.

    I learned Wireshark in the traditional manner: got annoyed with tcpdump, installed Wireshark, and started poking menus and buttons until I got a result. Chapters 1-5 of PPA takes you through the important menus and buttons. There’s not much you can do to make descriptions of software options interesting, but Sanders demonstrates real-world uses as he goes along. Demonstrating how to use round-trip-time graphing with real data, for example, gives the buttons and menus relevance to our work. Chapters 6 and 7 cover a few basic network protocols, from ICMP to HTTP to social media logins and DHCP and so on, to ground you in what traffic should look like.

    The really interesting part of the book is the second half. Starting in Chapter 8, Sanders dives into real-world problems and shows how to investigate them with Wireshark. He covers topics from difficult developers to network latency to security. What does a worm look like on the network? How about wireless?

    The book organization invites me to keep it at hand for troubleshooting. The next time I investigate a slow network, I’ll turn to PPA2e chapter 9. And that’s perhaps the best praise I can offer on any technical book.

    Practical Packet Analysis invites comparison with my own Network Flow Analysis. As you might guess, I consider network awareness skills absolutely vital for any network engineer. Where my work is about broad-scale network flows, however, Sanders’ work lets you dig deep into individual packets. Jitter, latency, loss, and all the details of protocol transactions are resistant to flow analysis, whereas packet analysis will lay them bare. I know my readers have already bought and devoured my book, but you really need to master both tools.

    Plus, the author proceeds from Practical Packet Analysis are all being donated to the Rural Technology Fund. The narrator of NFA recommends using flow analysis to blackmail your coworker into washing and waxing your car. I am forced to conclude that Sanders is probably a better human being than I am.

    Buy this book.

    Disclaimer: No Starch Press also publishes books by yours truly. I have no problem calling them out if I disagree with them. Watch, I’ll demonstrate:

    “Hey, guys, I really liked the color text boxes we did in PGP & GPG. I know they were more expensive than plain black and white pages, and I know that book sold fewer copies than anything else I’ve written, but it looked really cool. Why don’t we do that everywhere?”

    OK, maybe that’s me being an entitled prima donna rather than disagreeing with them, but still, I wouldn’t write a positive review on a book I didn’t like.

    Posted on

    How to Lose your Job with SSH, part 1

    A less sensational title for this post would have been “SSH Remote Forwarding,” but that’s not nearly as fun.

    I used to be responsible for one of the few entry points into a global network. The company had actual manufacturing secrets — their products included various machines of war. We had internal firewalls to protect sites from each other, even when the site didn’t have Internet access. All Internet connections had to go through proxies. We did not allow external DNS to reach the desktop. If you typed ping google.com on your desktop, you’d get a “host unknown” error. The company had invested in VPN technology that blocked all but approved clients, and only permitted clients on the approved list if they were running the approved anti-virus scanners and other security software.

    I was frequently asked to open direct Internal access for random applications. Most of these requests were rejected unless the user could explain what they wanted and why it was business-critical. Some of the people who asked were technically literate, and became indignant when I rejected their request for outbound SSH to external servers or equipment. After all, SSH is “Secure Shell.” It says secure RIGHT IN THE NAME. They just want to check their personal email. How could I possibly reject this eminently sensible request?

    I’ve since had left this job, but I’ve had the same discussion more than once afterwards.

    Most SSH users have no idea of SSH’s flexibility. Arbitrary SSH connections are a nightmare for maintaining any sort of secure information perimeter. Remote port forwarding is one reason why.

    When most people mention SSH port forwarding, they’re thinking of local port forwarding. You forward a TCP port on your client to a TCP port on the SSH server. This lets you, say, tunnel SMTP inside SSH, so your client can relay mail through your server without any complicated Sendmail rules.

    Remote forwarding lets you do the reverse: forward a TCP port on the SSH server to a TCP port on the SSH client.

    Suppose I permit a user to SSH to an external server. The desktop is behind a NAT. There are no port mappings from the NAT to the desktop; it has the same connectivity you might give a secretary, except for the outbound SSH access to a single host. That user sets up remote port forwarding from a TCP port attached to the server’s public IP to the client’s SSH daemon. I’m using an OpenBSD desktop, but you can get SSH clients for most other operating systems, including Windows. I’m using OpenSSH, of course, but most clients (including PuTTY) does remote port forwarding.

    To do remote port forwarding in OpenSSH, run:

    $ ssh -R remoteIP:remoteport:localIP:localport hostname

    If you don’t specify an IP address to attach to the SSH server, the server attaches to 127.0.0.1. (You can also skip the first colon in this case.)

    My desktop runs sshd. I want to attach port 2222 on the SSH server pride.blackhelicopters.org to port 22 on my SSH client using remote port forwarding.

    client$ ssh -R 2222:localhost:22 pride

    I leave this connection up and go home. Perhaps I run top in the command window, to prevent the SSH session from timing out at the corporate firewall. Now at home, I log into the SSH server and run:

    pride$ ssh -p 2222 localhost

    My SSH request to the local machine will get tunneled inside the existing SSH connection out of the network. I will get a logon prompt for my client inside the secure network. When I can access one supposedly secure machine, I can start ripping data out of the local file servers and maybe even access other internal sites. All of the trouble the company expended to prevent unauthorized access is now moot.

    If you attach the remote port forwarding to the server’s public IP, then anyone on the Internet can attack your desktop’s SSH daemon. People are attacking SSH servers, even on odd ports.

    Of course, remote port forwarding in this environment would violate company policy. If caught, you’d lose your job. But to catch this abuse, the network administrator would need to realize that large data transfers were taking place in off hours over these limited-use channels. You could, say, use flow analysis to write automated reports that notice and alarm when large amounts of traffic pass over these “rarely-used” channels. You’d have to be a real bastard to think of that. But the reports are easy to write, and the look on the abuser’s face when you confront them with graphs and numbers is priceless.

    The point is, the next time your employer’s network administrator rejects your sensible request for SSH access to your home server, don’t be too hard on the poor slob.

    Want more SSH fun? Check out the book recommended by the OpenSSH project, SSH Mastery.

    Posted on

    creating FreeNAS 8 iSCSI target

    I didn’t find an up-to-date tutorial on how to set up a FreeNAS 8 iSCSI target, so I took notes as I set one up. Figuring this out by brute force is fairly straightforward: just keep adding iSCSI stuff until you can actually discover iSCSI targets. But for those of you who value your time, here’s how you do it.

    1) Go to services, enable iscsi. Under iSCSI, choose Target Global Configuration. In Discovery Auth Method choose CHAP. Leave all other settings unchanged

    2) It seems that FreeNAS doesn’t yet let you export a whole drive via iSCSI; you must create an extent. Under iSCSI, select Extents, then Add Extent. Name your extent, give it a path, and set a size.

    3) On the Target Global Configuration, on the “authentication” tab, create an iSCSI user and assign it a secret

    4) You need an iSCSI Portal. Click the Portals tab. This is where you define the iSCSI target. The default is to listen for iSCSI connections on all IP addresses, on port 3260. If you have multiple IP addresses, and want separate portals for each, be more specific.

    5) You must authorize initiators. Choose “Authorized Initiator,” then “Add Authorized Initiator.” List the IP subnet of your initiators under Authorized Network.

    6) Go to the Targets tab. Add a target.

  • Give the target a name and and an alias.
  • The type will be “disk.”
  • flags read-write
  • portal group ID is the number of the portal (probably 1)
  • initiator group ID is the number of the authorized initiators you created (probably 1)
  • Set auth method to CHAP
  • authentication group number from the user you created (also probably 1)

    • 7) Under “Associated Targets,” attach the extent to the target.

    Now go to your iSCSI initiator and log in.

    To create new iSCSI targets, create a device extent, add a target for that extent, and attach the extent to the target.

    Posted on

    SSH Book Title

    I’m at a publishing workshop, learning how to write pitches, blurbs, and promotions. That drove home that my SSH book title might not be the best choice.

    I’ve been planning to use the title “OpenSSH: Your Next Steps.” The book will take you to SSH competence, making sure that you use basic security precautions, master using keys for authentication, SSH tunneling, and so on. That title’s fine. As far as it goes.

    But I think I can do better. I’m pondering calling it “SSH with OpenSSH and PuTTY” instead. The first title, I’d have to rely on keyword search to bring up SSH. This title brings all the key words into plain sight.

    I learned with PGP and GPG that a title is important. If I had called that book “Email Encryption for Everyone,” I would have sold a lot more copies.

    So, what do you lot think?