Should entrepreneurs get an MBA? By Mario Luis Tavares Ferreira

CMN 432, MBA, Management, Personal, Security No Comments »

ORIGINAL SOURCE HERE

26th March 2009

mba_letters-300x290 Should entrepreneurs get an MBA?I was reading a polemic if entrepreneurs should, or not, get an MBA and I would like to put forth my idea about the matter.

We are always learning and will continue until dead. There is always something that could be improved and, to figure out, knowledge will facilitate the process.

I agree that many entrepreneurs develop their business skills with blood, sweat and tears, as I did. I co-founded two high tech start-ups and, after 25 years of “bloody times” and two companies, I decided to get my MBA.

In theory, having a couple decades of experience in running a business, I should already know almost everything about business management and development. But, actually, getting the MBA, I learned, rooted and improved a lot of processes and knowledge that I was already using, and also, I learned a lot of new things (state-of-the-art techniques, theories, new writers, new strategies, new “gurus”, and so on). I learned all that, even being a compulsive reader of everything about management, strategy, globalization and entrepreneurship, and had read hundreds of books about the matter, before deciding to return to school. Read the rest of this entry »

Tags: , , , , , , ,

LAMP setup: Beginning

IT, Security No Comments »

Original Document Here

How to install and configure Linux as a Web server? What are the main steps to go? This article should cover the main configuration steps for LAMP – Linux Apache MySQL PHP server.

  1. Which Linux distribution to install?
  2. Before installation
  3. Partitioning
  4. Package selection
  5. Set runlevel to 3
  6. Turn off needless services
  7. Firewall
  8. Forbid ssh access for root

1. Which Linux distribution to install?
List of Linux distributions are huge, please see Linux distribution list (after page load, click on Go button). Among that list, there exists several main Linux distributions (streams): RedHat, Debian, Suse, Ubuntu … Choose the one that looks most familiar to you. In my case for Web server, I choose CentOS (current version CentOS 5) from RedHat family. CentOS is an Enterprise-class Linux Distribution derived from freely provided sources. It should be stable distribution with minimum bugs and large community. The most important thing is – I have experience with RedHat tools and the way of RedHat system configuration.

2. Before installation
Check if server has redundant components: power supply, RAID, Ethernet adapters … It is good to have at least RAID arrays. Linux will see hardware RAID as one disk that should be partitioned. Depending on number of disks in RAID array, you can create RAID1 (mirroring) or RAID5 (striped disks with parity). In case of 4 disk, it will be wise to take 3 disks and create RAID5 array, and define last disk as a spare disk. In such RAID5 configuration, if one disk in array fail, RAID controller should automatically reuse spare disk and start content reconstruction. If your server doesn’t have hardware RAID, you have software RAID/LVM option during Linux installation process – but this is more advanced task.

3. Partitioning
Linux installation is easy. Nice graphical interface with built in help and wizards. This could proceed everyone with windowsland installation experience. Step in which care should be taken is the disk partitioning. If you click on next at partitioning step, installer will create default disk partitions which will be generally OK – swap, /boot and / (slash) partition, but in any serious LAMP installation, choose Manually partitioning and create seven partitions. In case of 140Gb disk size, partition arrangement can be:

  1. 1Gb  swap # mark as primary
  2. 1Gb  /     # mark as primary
  3. 1Gb  /tmp  # mark as primary
  4. 1Gb  /home
  5. 8Gb  /usr
  6. 70Gb /var
  7. 58Gb /backup
1Gb  swap  # mark as primary
1Gb  /     # mark as primary
1Gb  /tmp  # mark as primary
1Gb  /home
8Gb  /usr
70Gb /var
58Gb /backup

Size of swap depends on amount of memory and as I was monitoring server with 4Gb of RAM, 1Gb of swap is good enough. Web server should not dive deep to swap. If it does, increase RAM memory or reduce running services. In old Linux school, good practise was to create big enough / (slash) partition because of kernel upgrade. /boot was only directory beneath / (slash) partition. As you know, every new kernel doesn’t overwrite the old one because backup reboot option. So, good administrator have to manually delete old kernel after some time of new kernel production and there should be enough disk space to contain more than one kernel on the system. Frequently used partitions are marked as primary to minimize access time. I usually give 1Gb for /tmp which is maybe oversized, but in case of database export or unpacking tars it is very handy. /home partition size depends on the purpose of web server. If users will exist on the Web server, you will have to dimension size of /home partition with more care. 8Gb for /usr partition is enough for LAMP server and it will not be in use more than 50%. After sizing swap, / (slash), /tmp, /home and /usr all remaining free space share between /var and /backup partition. /var partition contains MySQL files, log files, spool mail and web document root, so in case of 140Gb disk space, I give 70Gb to /var and 58Gb to /backup (because of arrangement to hold 3 days of database export – one database export is 15Gb). Good practise is also to save daily backup of configuration files (whole /etc directory), document root, MySQL dump (export), cron files and /root directory. I call it first backup level. Real backup plan should not stop here. All tars from /backup partition should be placed on dedicated backup server or simply copied with scp to another (physically distant) server.

4. Package selection
After disk partitioning, there come few easy tasks: root password (set strong password), user creation, IP address, DNS … and then package selection. Don’t forget to check Web server and database MySQL or PostgreSQL. Web server package contains Apache with PHP module. If needed, FTP server can be also included in installation and that will be all for package LAMP setup. Installer will include all dependencies, so relax and enjoy in Linux installation. :)

5. Set runlevel to 3
After installation and first restart, server will probably boot to runlevel 5 – if you install GNOME or KDE. Nice graphic interface gdm will awaiting users to login. Open /etc/inittab and find line with initdefault. Simply replace number 5 with 3 and save file. After reboot, system will boot to runlevel 3 (without X server). Inside inittab you will also find definition of spawn 6 gettys in standard runlevels. You can comment bottom four because server configuration and monitoring will mostly go through ssh.

  1. # Default runlevel. The runlevels used by RHS are:
  2. #   0 - halt (Do NOT set initdefault to this)
  3. #   1 - Single user mode
  4. #   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
  5. #   3 - Full multiuser mode
  6. #   4 - unused
  7. #   5 - X11
  8. #   6 - reboot (Do NOT set initdefault to this)
  9. id:3:initdefault:
  10. # Run gettys in standard runlevels
  11. 1:2345:respawn:/sbin/mingetty tty1
  12. 2:2345:respawn:/sbin/mingetty tty2
  13. #3:2345:respawn:/sbin/mingetty tty3
  14. #4:2345:respawn:/sbin/mingetty tty4
  15. #5:2345:respawn:/sbin/mingetty tty5
  16. #6:2345:respawn:/sbin/mingetty tty6
# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
id:3:initdefault:
...
...
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

In FC9 configuration of gettys are handled by /etc/event.d/tty[1-6] so I suppose that change will propagate in forthcoming CentOS 6.

6. Turn off needless services
It is good to see which services will be started during booting to runlevel 3. In RedHat family, there is utility chkconfig and in combination with grep, list runlevel 3 services. You will see long list of services and many of them are needless for LAMP setup.

  1. chkconfig –list | grep 3:on
chkconfig --list | grep 3:on

Minimum and sufficient list of running services for LAMP setup should look like:

  1. > chkconfig –list | grep 3:on
  2. crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
  3. httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
  4. iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
  5. irqbalance      0:off   1:off   2:on    3:on    4:on    5:on    6:off
  6. microcode_ctl   0:off   1:off   2:on    3:on    4:on    5:on    6:off
  7. mysqld          0:off   1:off   2:on    3:on    4:on    5:on    6:off
  8. network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
  9. sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
  10. syslog          0:off   1:off   2:on    3:on    4:on    5:on    6:off
> chkconfig --list | grep 3:on
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
irqbalance      0:off   1:off   2:on    3:on    4:on    5:on    6:off
microcode_ctl   0:off   1:off   2:on    3:on    4:on    5:on    6:off
mysqld          0:off   1:off   2:on    3:on    4:on    5:on    6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
syslog          0:off   1:off   2:on    3:on    4:on    5:on    6:off

All other services can be turned off by executing “chkconfig <service> off” command:

  1. chkconfig cups off
  2. chkconfig gpm off
chkconfig cups off
chkconfig gpm off
...

After turning off needless services and before production launch, reboot server to see if everything works as expected.

7. Firewall
Web server will be probably placed behind DMZ’s firewall, but it is good to protected LAMP server with his own firewall. This firewall should accept HTTP requests from any source and SSH request from intranet side only (in example from one IP address). All other types of connections will be forbidden. You can use system-config-securitylevel utility to create file /etc/sysconfig/iptables and it’s content should look like:

  1. *filter
  2. :INPUT ACCEPT [0:0]
  3. :FORWARD ACCEPT [0:0]
  4. :OUTPUT ACCEPT [0:0]
  5. -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
  6. -A INPUT -p icmp -j ACCEPT
  7. -A INPUT -i lo -j ACCEPT
  8. -A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
  9. -A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -s 123.123.123.123 -j ACCEPT
  10. -A INPUT -j REJECT –reject-with icmp-host-prohibited
  11. -A FORWARD -j REJECT –reject-with icmp-host-prohibited
  12. COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -s 123.123.123.123 -j ACCEPT
-A INPUT -j REJECT –reject-with icmp-host-prohibited
-A FORWARD -j REJECT –reject-with icmp-host-prohibited
COMMIT

… or you can open file /etc/sysconfig/iptables copy/paste this configuration and restart iptables.

8. Forbid ssh access for root
Before production, create at least one user more without any administration rights – normal user with strong password (if you didn’t in step 4.).

  1. useradd <username>
useradd <username>

In /etc/ssh/sshd_config find option PermitRootLogin and write it to:

  1. PermitRootLogin no
PermitRootLogin no

Restart sshd and root will no longer be able to access LAMP server through ssh – that’s why additional user exists. To obtain administrator rights, execute “su -” (substitute user) command.

After finishing all this steps, LAMP server should be secured with minimum running services, firewall and disabled root ssh access. Now it’s time for Apache and PHP configuration …

Tags: , , , ,

How should I set up my Linux Web Server? by Neo Notenboom

IT, Security No Comments »

Original Document Here

WHM

Step one was to login to Web Host Manager (the server management front-end for cPanel), and run their configuration wizard. The only things that required non-default action were:

  • setting the hostname
  • added a resolver (DNS) server ip

After the wizard was complete, these additional settings were performed manually:

  • Server Contact E-Mail
  • Turned on awstats web stats reporting tool
  • Changed hostname. (Even though the wizard set it, this was an additional, different place.)
  • Changed system mail preferences to send root email to an admin alias.
  • Changed root password.
  • Set Nameservers

Also ran Update Server Software and Update System Software within WHM to update as many components as reasonable.

Linux Kernel

The original configuration as delivered by the server farm:

WHM 10.1.0 cPanel 10.2.0-R82
RedHat Enterprise 3 i686 – WHM X v3.1.0
Linux kernel version: 2.4.21-27.ELsmp

Since that’s not the latest kernel at the time of delivery, and cPanel will not update the kernel automatically, I was advised to update. I upgraded the kernel to 2.4.21-32.0.1.ELsmp, which went smoothly.

Remote Access

One of the areas for almost immediate security tweaking is remote access. If you’ve ever examined a server’s logs, you know that they’re regularly probed with various types of attacks. There are several modifications to render those attacks pointless, as well as secure remote access in general.

SSH

SSH, or secure shell, is the remote command-line access mechanism of choice. It’s single biggest claim to fame is simply that everything is encrypted, though it includes many more features as well.

I first created a couple of non-root login accounts, and installed RSA public keys for eventual RSA/public key-only logins. (Also created end-user instructions for creating, and using, SSH key pairs.)

I then made the following changes to /etc/ssh/sshd_config:

  • Protocol 2 – this disables protocol version 1, which is known to have security issues.
  • PermitRootLogin without-password – this disables root login, unless a public key is used.
  • PasswordAuthentication set to no – this disables the ability to login with just a username and password. A username and public key are required.

Telnet

I disabled telnet, as it allows passwords to be transmitted in the clear, and is a known security risk.

FTP

Normally at this point I would also disable the FTP service for the same reasons as Telnet – it’s a known security risk. For reasons I didn’t bother to investigate further, cPanel either complained repeatedly via email if the service was stopped, or it would restart it, depending on the technique I was attempting to use. I gave up on this and left the FTP service running, but blocked at the firewall, discussed below.

TMP

The /tmp directory is an interesting and apparently common place for hackers to exploit to breech a system. One approach to securing it without breaking its functionality is to create it as a new partition that disallows program execution. Where in the past a hacker could use an exploit to place a file in /tmp and then execute it, the ability to execute is now removed by creating a secure /tmp partition.

Firewall

Installed APF which is, essentially, an intelligent front end to the built in Linux firewall, iptables. I found a good how-to, though I did not yet configure the antidos (denial of service) component. The one change that I did make to the default configuration is that I disabled or blocked all ports that we know are not explicitly used for something specific. For example, this is where I blocked all FTP access. I also whitelisted my own static IP address, and that of the client.

Logging

Logwatch is a server log summary tool that emails a report to the server admins nightly. An older version was installed. I updated to latest, and increased the reporting level to “medium”.

Rootkit Checks

Installed nightly backup script, which includes nightly reporting of both rkhunter and chkrootkit runs.

Apache

Installed mod_security, which guards against exploits via the Apache web server, using a basic ruleset. This how to was helpful in setting that up.

General

A few additional tweaks and settings …

  • Installed LES – “LES is intended as a facility to quickly & easily secure Redhat/RPM based environments (i.e: turbo Linux, open Linux). It does such by enforcing root-only permissions on system binaries (binaries that have no place being executed by normal users), enforcing root-only path traversal on system paths, enforcing immutable bit on essential rpm package contents (i.e: coreutils), and enforcing immutable bit on shell profile scripts.”
  • Added a mail line to /etc/rc.d/rc.local, to automatically notify on reboots.
  • Removed the cpbackup cron job, since we don’t use cPanel’s backup approach.
  • Modified reverse-DNS to be correct.

Ongoing Maintenance

Even with all the tools and updates in place, there’s still on-going work and vigilance required.

  • Monitor the nightly logs and reports generated for anomalies.
  • Manually install updates as reported available by up2date.
  • Monitor Redhat for kernel updates, and install as appropriate.
  • Monitor chkrootkit for updates, and install as appropriate.

Still More Options

I haven’t implemented these, but they’ve been recommended, and they’re on the list to evaluate at some point.

  • mod_doevasive. “mod_dosevasive is an evasive maneuvers module for Apache to provide evasive action in the event of an HTTP DoS or DDoS attack or brute force attack. It is also designed to be a detection and network management tool, and can be easily configured to talk to ipchains, firewalls, routers, and etcetera. mod_dosevasive presently reports abuses via email and syslog facilities.” How To
  • Evaluate BFD. “BFD is a modular shell script for parsing applicable logs and checking for authentication failures.”
Tags: , , , , , , , , , , ,

How to set up SSH keys: Frustration with “Server refused our key” by Andre Molnar

IT, Security No Comments »

This saved me a couple of hours trying to figure out it myself.

Original Document Here

So you’re trying to set up ssh keys on your windows box with putty and you keep getting “Server refused our key”. Read on, I’ve got your solution… but first lets take a look at what you’ve done so far.

Chances are you have done some/none/all of the following:

  • opened up puttygen.exe
  • generated a key after wiggling your mouse
  • entered a strong passphrase
  • saved the public key to something like
    pubkey
  • saved the private key to something like
    privatekey.ppk
  • moved your public key up to the server
  • (maybe even) converted the format of the key from putty to openssh with something like
    ssh-keygen -if pubkey > pubkey_openssh_format
  • changed some permissions like
    chmod 700 .ssh
  • added your pubkey to the authorized_keys file with something like
    cat pubkey >> .ssh/authorized_keys
  • changed some more permissions like
    chmod 600 authorized_keys
  • changed your putty settings under “connection > SSH > auth” to use
    privatekey.ppk
  • tried to connect and…

“Server refused our key”

Well – from what I have read that’s supposed to work… but it didn’t work for you did it?

Your problem has nothing to do with how well you followed these well documented procedures for getting ssh keys to work.
The solution to the problem is…
(brace yourself, its really simple) to try generating the keys on the server (unix, linix, bsd etc.) instead of the client (i.e. in windows).

Try the following:

  • ssh to your server using good old user name and password
  • do check permissions on your ~/.ssh folder and make sure to
    chmod 700 .ssh

    if they are wrong

  • do check permissions on your ~/.ssh/authorized_keys file and make sure to
    chmod 600 authorized_keys

    if they are wrong

  • generate the keys on the server with something like
    ssh-keygen -t dsa

    (or rsa – read the man pages if your don’t know how to use ssh-keygen

  • accept the file names it wants to use
  • enter a strong passphrase
  • add the pub key to the authorized_keys file with something like
    cat id_dsa.pub >> .ssh/authorized_keys
  • copy the private key (id_dsa) to your local windows machine (use winscp or sftp or some such tool)
  • NOW open puttygen.exe
  • under actions select “load” and load the id_dsa file
  • enter the passphrase you set when you generated the key on the server. Puttygen will now convert the key to something that putty will understand
  • save that file to something like
    pivatekey.ppk
  • NOW change your putty settings under “connection > SSH > auth” to use
    privatekey.ppk
  • NOW try and connect
  • enter the passphrase when prompted
  • pat yourself on the back. You’re connected to the server (I hope)

Now all you have to do is figure out a way to not have to always enter that passphrase. Well that will require setting up puttyagent. But, I’ll let you figure that out for yourself.

I really hope this helped you out. I wasted too much of my life figuring this out this evening and I hope I saved you hours of aggravation.

Tags: , , , , ,

How do I create and use Public Keys with SSH? by Neo Notenboom

IT, Security No Comments »

Original Document Here

SSH (Secure Shell) and SFTP (Secure FTP) support a very strong security model that can be used instead of the normal username and password authentication scheme we’ve all come to know and love. It uses public key cryptography to create a different, and more secure approach to authenticating your identity and rights to access a server or resource.

In a nutshell, you will generate a public and private key pair. The public key will be placed on the server by your system administrator, giving you access. You will keep the file containing the private key in a safe place. You’ll login by simply by providing that private key file to your SSH or SFTP supporting client.

It really is that simple.

The private key is just that – private. You may put a password on it, but you don’t have to. Without a password, all you need is the file in order to login. Or, to put it more clearly, all anyone needs is that file to login as you. Obviously if you password protect the file, then you’ll need both the file, and the password to unlock it. In that case, logging in is very similar to what you do today: specify a user name, and a password to unlock your key file.

Instructions are included here for the following tools, which are known to work with this technique:

SSH Clients SFTP Clients
PuTTY
SecureCRT
PSFTP
Webdrive
WS_FTP

Instructions for these tools are not provided here, but they either claim or have been confirmed to have the appropriate support:

SSH Clients SFTP Clients
Tera Term Pro CuteFTP Professional (not Home)
WinSCP

Other tools may also work. The key terminology to look for is “SSH” or “SFTP” and “Public Key Authentication”.

Generating Your Keys

In general it’s best to create your own key. That way you control what happens to your private key, and no one else ever has to see it.

PuTTYgen

PuTTY is a free SSH client that includes a tool for generating keys, called PuTTYgen. The tool can also be downloaded separately, but why bother … get the whole thing. PuTTY is my recommended SSH client.

When you run PuTTYgen, you’ll get a dialog with a “Generate” button on it.

PuTTYgen Window

Push da button.

It will ask you to move the mouse around to generate randomness. (Randomness is a key component of public key cryptography). Once that’s happened enough, you should do the following:

  • Specify a passphrase. Technically this is optional, but if you omit the passphrase, then anyone who happens to get ahold of your private key file can login as you. You may have enough security in place where this is not an issue. If you do specify a passphrase, you’ll need to enter it when you login, pretty much as a normal login.
  • Press the Save Public Key button to save the public key. I recommend saving as your name “.pub”. For example I would save “leo.pub”.
  • Press the Save Private Key button to save your private key. This saves the private key in PuTTY’s own format, a “.ppk” file. So, “name.ppk” might be appropriate.
  • I also recommend hitting the Conversions menu, and then Export Openssh key, and saving that to “name.key”. This format will allow you to use your private key with other applications besides PuTTY.

SecureCRT

SecureCRT is a stand-alone SSH client.

To create a public key with SecureCRT, hit the Tools menu, Create Public Key… option to begin the wizard.

Select RSA as the key type. Enter (or not) an appropriate passphrase to protect your private key. A default key length of 1024 is sufficient. Allow SecureCRT to save the key, noting the location thereof. It may ask if you want to use this as your global Public Key, and you can safely say “yes”.

WS_FTP

As far as I can tell, WS_FTP cannot import key pairs for use, or will it export its private key. This means that even if you use one of the other SSH clients and generate key pairs for their use, you’ll still need generate a separate key pair for use within WS_FTP. That’s not a problem from the servers perspective – you can authenticate with as many different keys as you like.

In WS_FTP, hit Tools, Options, and then click on SSH, Client Keys:

WS_FTP Options Dialog

Press Create, and step through the wizard. The key type should be RSA, and the default size of 1024 is sufficient.

Once the key has been created and shows up in the list, click on it, and then click on Export, to export your public key. Send the resulting .pub file to your system administrator.

Once you have your keys…

Send your public key to your system administrator. (Either the “.pub” file as an attachment, or the text within it, in email.) It will be put in “all the right places” to allow you to log in to all the account(s) you might need to.

Keep your private key in a safe place. You’ll need it each time you want to login. If they are lost, you will lose access until the key generation and installation process can be repeated. If they or the computer they’re on are stolen, tell your system admin immediately.

Using Your Keys – SSH

Once your keys are generated, and the public key installed on the server, you’ll need to specify the private key to your SSH client in order to log in.

PuTTY

There are (at least) two approaches to using Public/Private keys with PuTTY. When you fire up PuTTY without any arguments, you get its standard configuration dialog, into which you can enter the name of the server you want to connect to:

Putty main window

On the left hand side is a tree view of various options. Underneath Connection, SSH, click on Auth and the dialog will include a field “Private key file for authentication“:

Putty SSH connection options window

Specify the location of the “.ppk” file that you generated with PuTTYgen. When you connect, if your private key is passphrase protected, you’ll be asked for the passphrase.

The other approach, and the one that I use, is to simply create shortcuts for the various servers I connect to regularly, and specify the location of the private key on the command line. For example:

C:\path\PUTTY.EXE -i c:\otherpath\leo.ppk leo@server.com

That, as a desktop shortcut, or item on a Windows menu, connects to the named server using the specified account name “leo”, and uses the private key found in “c:\otherpath\leo.ppk” to authenticate.

SecureCRT

SecureCRT has several paths to a connection dialog, but we’ll use “Quick Connect” for our example. Press the Quick Connect Icon, and you should get something like this:

SecureCRT Quick Connect Dialog

Make sure that protocol is set to SSH2, and enter your host and username. In Authentication, UNcheck everything except PublicKey. Then click on that, and click Properties. You should see this:

SecureCRT Public Key Properties Dialog

Typically you need do nothing, but this dialog specifies the location of your identity file (aka Private Key).

Assuming that your public key has been placed on the server for your account, you should now be able to connect.

Using Your Keys – SFTP

Secure FTP, or FTP, is really just using SSH technology to provide FTP-like functionality. Since it’s using SSH, the keys you’ve generated and are using for your SSH authentication work with many SFTP applications as well.

WebDrive

Webdrive is an FTP/SFTP service for Windows that allows you to treat an FTP or SFTP connection like another drive mounted on your system. Uploading and downloading then become simple Windows file copy operations.

In Webdrive, you’ll need to load your private key, and then specify it in the configuration for a specific SFTP connection.

The Certificates tab of Webdrive’s Settings dialog, has a Hostkey Managemet button:

Webdrive Settings dialog

Push that, and you’ll get the host key management dialog, and on that you’ll find an Import button. Press that to import your public and private keys:

Webdrive Hostkey Import dialog

Specify the “.pub” key for the public key you generated earlier. The private key should also be specified, and would be the “.key” file. If you passphrase protected your key file, you can specify that here as well. Give it a recognizable name.

The second step, then, takes us back to the Webdrive main window:

Webdrive dialog

Click on a connection (or create a new one). In the Properties for that connection, on the SFTP tab will be a setting Enable client hostkey support for this site:

Webdrive dialog

Here you’ll find a dropdown list of the keys you imported above, and a place to enter the password, if any, to access that key.

Once completed, Webdrive should now be able to connect to your public key authenticated site.

WS_FTP

Having created a key pair already in WS_FTP, using it is simply a matter of defining your connection to use it.

When you create a site, specify its connection type as SFTP/SSH. Specify a user name, but leave your password blank. At the end of the wizard, click on the Advanced button, this will allow you to edit the connection, and is the equivalent to editing an existing connection.

Click on the SSH item on the left, and the dropdown list that results should allow you to select the key pair that you created earlier.

Assuming that the public key you exported and sent to your system administrator has been installed on the server, you should now be able to connect.

psftp

PSFTP is command line FTP program that is distributed with PuTTY. More importantly, it supports public key SFTP by using the “.ppk” file that you created for PuTTY above. Connecting using a public key is simply a different set of comment line options:

psftp -l username -2 -i keys.ppk remotehost

-l username specifies your username on the remote host; -2 indicates that PSFTP should use SSH protocol version 2; -i keys.ppk specifies the location of your private key as created with PuTTYgen; remotehost is the name of the remote host you’re connecting to.

Tags: , , , , , , ,