A very fine feature of UNIX operating systems is native support for services like SSHd. SSH provides shell access on remote computers - encrypted, so no one can snoop your passwords. SSH comes with various utilities including scp, which allows you to copy files and folders to the remote server (and all this traffic and data is encrypted). You can also use ssh as rsync's transport mechanism for synchronizing directories across computers. If you want to automate tasks like this (scheduling unattended backups with cron, for example), you'll need the computer that's initiating the connection to be able to log into the remote computer without being prompted for a user to input a password.
This is where ssh 'keys" come in. You create a private/public key pair on your computer ("the client"), and put the "public" key up on the remote computer ("the server"). After that, when you log into the remote computer, you are no longer prompted to enter a password (so long as you made the key correctly).
To generate a pair of keys with no passwords, using the standard RSA type of keys, run the following command on the computer you are connecting from:
ssh-keygen -t rsa -N ""
This will create two files: ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
Copy - with scp - the public file ~/.ssh/id_rsa.pub up to the remote computer you will be connecting to (or sending data to). Then log into the remote server and put the contents of that public key into the ~/.ssh/authorized_keys file. An easy way to do that is like this:
cat >> id_rsa.pub ~/.ssh/authorized_keys
Using the double "greater than" brackets ensures that if ~/.ssh/authorized_keys already exists, the new key will be added to the file, and not overwrite any existing keys that might already be in place.
After that, you should be able to connect from the client with the key pair to the remote server without being prompted for a password.
Tuesday, May 8, 2007
Wednesday, May 2, 2007
Mac OS X Keyboard Shortcuts
Apple provides a nice list of keyboard shortcuts for OS X:
http://docs.info.apple.com/article.html?artnum=75459
My favorite: "Shift-Command-Delete": Empty Trash
http://docs.info.apple.com/article.html?artnum=75459
My favorite: "Shift-Command-Delete": Empty Trash
Reporting ebay scam email
I don't know if it does any real good or not, but I've taken to forwarding all ebay spoof/scam/phishing email to spoof@ebay.com (which gives me a nice little automated reply stating "This message did not originate from eBay . . .") At least that way eBay will have more recorded instances of such emails in case they ever file legal proceedings against these scammers.
Tuesday, May 1, 2007
Passing environment variables to sudo
A user on the Fink mailing list wrote to tell me that instead of editing /etc/sudoers to maintain the PERL5LIB variable, you can optionally pass it through on the command line, like this:
sudo env PERL5LIB=$PERL5LIB cpan
sudo env PERL5LIB=$PERL5LIB cpan
Wednesday, April 25, 2007
Controlling KDE applications from the shell
I came across this the other day on accident:
kfmclient --commands
You can do a rather fascinating number of things to KDE in the shell through kfmclient, including opening a new Konqueror window, opening a new tab in an existing Konqueror window, starting an application from its ".desktop" file, rearrange/refresh your desktop, copy and move files (I presume this would include copying to/from the various IOSlave protocols like fish://).
Try these, for example:
kfmclient newTab 'url'
kfmclient exec .
Since quotes work as well as ticks ( ' ), you could wrap this into a shell script like this:
kfmclient newTab "$somedest"
I haven't come up with any terrific uses for this yet, but it's promising.
kfmclient --commands
You can do a rather fascinating number of things to KDE in the shell through kfmclient, including opening a new Konqueror window, opening a new tab in an existing Konqueror window, starting an application from its ".desktop" file, rearrange/refresh your desktop, copy and move files (I presume this would include copying to/from the various IOSlave protocols like fish://).
Try these, for example:
kfmclient newTab 'url'
kfmclient exec .
Since quotes work as well as ticks ( ' ), you could wrap this into a shell script like this:
kfmclient newTab "$somedest"
I haven't come up with any terrific uses for this yet, but it's promising.
Thursday, April 19, 2007
Revisiting the CPAN initial configuration screen
Recently I made a fresh install of Debian Etch from a NetBoot disk and started installing CPAN modules before I realized the compiler tools - make, gcc, automake, autoconf and friends - are not part of the default NetBoot minimal install (Ok, so I wasn't thinking. That's why it's called minimal, after all.)
Most of the CPAN packages would not compile, returning various make errors. I was stumped when they still would not make after installing make and the other tools, until I realized that CPAN was not able to find make in the PATH during it's initial configuration.
The may be a faster way to do this, but I decided to run the initial configuration again to CPAN would pickup make.
The way I found to do this is open CPAN:
perl -MCPAN -e shell
and then type:
o conf init
to reconfigure.
Most of the CPAN packages would not compile, returning various make errors. I was stumped when they still would not make after installing make and the other tools, until I realized that CPAN was not able to find make in the PATH during it's initial configuration.
The may be a faster way to do this, but I decided to run the initial configuration again to CPAN would pickup make.
The way I found to do this is open CPAN:
perl -MCPAN -e shell
and then type:
o conf init
to reconfigure.
Tuesday, April 10, 2007
When a short sudo timeout drives you crazy . . .
I've recently discovered an easy configuration option for sudo to make the timeout a little longer.
Just add the following line to your /etc/sudoers config file:
Defaults:your_username_here timestamp_timeout=900
(using your actual system username instead of "your_username_here")
The number at the end is how many seconds you want sudo to wait before prompting for a password again.
Just add the following line to your /etc/sudoers config file:
Defaults:your_username_here timestamp_timeout=900
(using your actual system username instead of "your_username_here")
The number at the end is how many seconds you want sudo to wait before prompting for a password again.
Subscribe to:
Posts (Atom)