Telstar

babylon9 hvala za pojasnila. Ja sej bi jaz tudi postavil Apacheja sam zdej rabim takole mal za testirati oz. pregledovati asp z MS SQL in ne bi rad imu 100 programov na kup, ker jih mam že tko preveč. Mi je jasno da je boljše perspektiva PHP in MY SQL (ker je zastonj pa še dobro dela) sam s kolegom imava ene "hude projekte", ki jih je treba čimprej narest in on pravi, da rabi ene pol leta, da bi nekak približn naštudiral PHP in MY SQL.
Zato bova zdej to nardila pač v asp in MSSQL tako da bo dobro laufalo potem se bova pa preusmerila oz. bolj on, ker jaz se nimam cajta še s temu dajat (men je važn da sam mal zastopim zakaj se gre).
@Pingvin a si tako dober pa mu rečeš, če mi pošlje to kar je namontiral (PHP in MY SQL) pa če ma kaka navodila, da se ne bom preveč matral

_________________
Hekerju hvala, ker mi je samo podpis spremenil

janton: Za lavfanje php-ja na racunalniku rabis samo en program, ki se mu reče BadBlue. Je pa res, da moras potem vse php fajle preko njega odpirat.

Php Windows NT/2000/XP and IIS 4 or newer

To install PHP on an NT/2000/XP Server running IIS 4 or newer, follow these instructions. You have two options to set up PHP, using the CGI binary (php.exe in PHP 4, or php-cgi.exe in PHP 5) or with the ISAPI module.

In either case, you need to start the Microsoft Management Console (may appear as 'Internet Services Manager', either in your Windows NT 4.0 Option Pack branch or the Control Panel=>Administrative Tools under Windows 2000/XP). Then right click on your Web server node (this will most probably appear as 'Default Web Server'), and select 'Properties'.

If you want to use the CGI binary, do the following:

*

Under 'Home Directory', 'Virtual Directory', or 'Directory', click on the 'Configuration' button, and then enter the App Mappings tab.
*

Click Add, and in the Executable box, type: C:\php\php.exe for PHP 4 or C:\php\php-cgi.exe for PHP 5 (assuming that you have unziped PHP in c:\php\).
*

In the Extension box, type the file name extension you want associated with PHP scripts. Leave 'Method exclusions' blank, and check the 'Script engine' checkbox. You may also like to check the 'check that file exists' box - for a small performance penalty, IIS (or PWS) will check that the script file exists and sort out authentication before firing up PHP. This means that you will get sensible 404 style error messages instead of CGI errors complaining that PHP did not output any data.

You must start over from the previous step for each extension you want associated with PHP scripts. .php and .phtml are common, although .php3 may be required for legacy applications.
*

Set up the appropriate security. (This is done in Internet Service Manager), and if your NT Server uses NTFS file system, add execute rights for I_USR_ to the directory that contains php.exe / php-cgi.exe.

To use the ISAPI module, do the following:

*

If you don't want to perform HTTP Authentication using PHP, you can (and should) skip this step. Under ISAPI Filters, add a new ISAPI filter. Use PHP as the filter name, and supply a path to the php4isapi.dll / php5isapi.dll.
*

Under 'Home Directory', click on the 'Configuration' button. Add a new entry to the Application Mappings. Use the path to the php4isapi.dll / php5isapi.dll as the Executable, supply .php as the extension, leave 'Method exclusions' blank, and check the 'Script engine' checkbox.
*

Stop IIS completely (NET STOP iisadmin)
*

Start IIS again (NET START w3svc)

If you experience 100% CPU usage after some time, turn off the IIS setting Cache ISAPI Application.

Mogoče kdo ve kako je najlažje spraviti update je na apača preko interneta. Kolega pravi, da tam kjer imajo oni apača menda ni dostopa preko ftp-ja, je pa neki SSH protokol. Bi ko vedel kako se dela s tem?

@janton, tole so linki;
za bazo izberi en mirror download http://dev.mysql.com/get/Downloads/MySQ ... ck#mirrors
za PHP imaš http://www.php.net/get/php-5.0.3-Win32. ... m/a/mirror
in
http://www.php.net/get/php-5.0.3-instal ... m/a/mirror

in GUI za upravljanje z MySQL bazo izberi en link iz mirrorja
http://www.mysqlfront.de/download.html

----------------

Za delovanje povezave na MySQL bazo skopiraj iz datoteke php-5.0.3-Win32.zip v direktorij Winnt/System32/ knjižnici LIBMYSQL.DLL in PHP_MYSQL.DLL ter editiraj PHP.INI v Winnt direktoriju in odkomentiraj EXTENSION-e za MYSQL (extension=php_mysql.dll)

ssh protokol se uporablja za secure remote login oz. secure shell.

Kako se uporablja zgeneriras kljucke jih preneses prek usb kljucka na drug rac in se povezes.
Lahko takoj direktno, sam ti lahko kdo prisluskuje in desifrira tvoj kljuc.

Potem vsa komunikacija poteka sifrirano, kako mocno je odvisno od kljuca, ki ga hoces zgenerirat.
Najboljs je to, ko X11 forwardiras iz remote machine k sebi.

na dolgo:

One of the most popular file transfer and remote login Linux applications is OpenSSH which provides a number of ways to creating encrypted remote terminal and file transfer connections between clients and servers. The OpenSSH Secure Copy (SCP) and secure FTP (SFTP) programs are secure replacements for FTP, while Secure Shell (SSH) is often used as a stealthy alternative to Telnet. OpenSSH isn't limited to Linux, SSH and SCP clients are available for most operating systems including Windows.

An Quick Introduction To SSH Encryption

Data encryption is accomplished by using special mathematical equations to scramble the bits in a data stream in order to make it unreadable to anyone who does not have access to the corresponding decryption equation. The process is usually made even harder through the use of an encryption key that is used to modify the way the equations do the scrambling. Only persons with access to this key and the corresponding programs are able to recover the original data. Data encryption helps to prevent unauthorized persons from having access to the data.

SSH uses the concept of randomly generated private and public keys to do its encryption. The keys are usually created only once, but you have the option of regenerating them should they become compromised.

A successful exchange of encrypted data requires the receiver to have a copy of the sender's public key beforehand. Here's how it's done with SSH.

When you log into an SSH server, you are prompted as to whether you want to accept the download of the server's public key before you can proceed. The SSH client's key is uploaded to the server at the same time. This creates a situation in which the computers at each end of the SSH connection have each other's keys and is able to decrypt the data sent to it from the other end of the encrypted link or "tunnel".

All the public keys that an SSH client's Linux user has encountered are stored in a file named ~/.ssh/known_hosts along with the IP address that provided it. If the match changes, then SSH knows that something is wrong. In many cases this is due to upgrades in the SSH application which may regenerate the keys, or a complete reinstallation of the operating system. You should also be aware that the keys could change due to someone trying some soft of cyber attack. Always investigate changes to be safe. Your server's own public and private SSH keys are stored in the /etc/ssh/ directory.

Note: The .ssh directory is a hidden directory, as are all files and directories whose names begin with a period ".". The "ls -a" command will list all normal and hidden files in a directory. The "~/" notation is a universally accepted way of referring to your home directory and is recognized by all Linux commands.

There are other key files that Linux uses to provide the capability of password-less logins and file copying to remote servers using SSH and SCP. In this case, the SSH connection is established then the client automatically sends its public key which the server uses to match against a predefined list in the user's directory. If there is a match then the login is authorized. The files for this purpose are also stored in your ~/.ssh directory and need to be specially generated. The files named id_dsa, id_dsa.pub are your private and public keys respectively, and the file named authorized_keys stores all the authorized public keys from remote hosts that may log into your account without the need for passwords. This process will be discussed in more detail later.

Starting OpenSSH

OpenSSH is installed by default during Linux installations, and as they are part of the same application, both SSH and SCP share the same configuration file and are governed by the same /etc/init.d/sshd startup script.

You can get SSH configured to start at boot by using the chkconfig command.

[root@bigboy tmp]# chkconfig sshd on

You can also start/stop/restart SSH after booting by running the sshd initialization script.

[root@bigboy tmp]# service sshd start

[root@bigboy tmp]# service sshd stop

[root@bigboy tmp]# service sshd restart

Remember to restart the SSH process every time you make a change to the configuration files for the changes to take effect on the running process.

Testing To See If SSH Is Running

You can test whether the SSH process is running with the following command. You should get a response of plain old process ID numbers:

[root@bigboy tmp]# pgrep sshd

The /etc/ssh/sshd_config File

The SSH configuration file is called /etc/ssh/sshd_config. By default SSH listens on all your NICs and uses TCP port 22. See the configuration snippet below which we'll also refer to later:

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1

#ListenAddress 0.0.0.0
#ListenAddress ::

SSH Versions 1 and 2

The original encryption scheme of SSH was adequate for its time but was eventually found to have a number of limitations that led to the development of version 2. You should always force your systems to operate exclusively with version 2 by setting the protocol statement in the /etc/ssh/sshd_config file to "2". Remember to restart SSH to make this take effect.

#

# File: /etc/ssh/sshd_config

#


Protocol 2

How To Change The TCP Port On Which SSH Listens

If you are afraid of people trying to hack in on a well known TCP port, then you can change port 22 to something else that won't interfere with other applications on your system, such as port 435. This is only a rudimentary precaution as good network scanning programs can detect SSH running on alternative ports.

Here is how it can be done:

1. First make sure your system isn't listening on port 435, using the "netstat" command and using "grep" to filter out everything that doesn't have the string "435".

[root@bigboy root]# netstat -an | grep 435
[root@bigboy root]#

2.No response, OK. Change the Port line in /etc/ssh/sshd_config to mention 435 and remove the "#" at the beginning of the line. If port 435 is being used, pick another port and try again.

Port 435

3.Restart SSH

[root@bigboy tmp]# service sshd restart

4. Check to ensure SSH is running on the new port


[root@bigboy root]# netstat -an | grep 435
tcp 192.168.1.100:435 0.0.0.0:* LISTEN
[root@bigboy root]#

Next we'll discover how to actually login to systems using SSH.

Using SSH To Login To A Remote Machine

Using SSH is similar to Telnet. To login from another Linux box use the "ssh" command with a "-l" to specify the username you wish to login as. If you leave out the "-l", your username will not change. Here are some examples for a server named "smallfry" in your /etc/hosts file.

User "root" Logs In To smallfry As User "root"

[root@bigboy tmp]# ssh smallfry

User "root" Logs In To smallfry As User "peter"

The examples below assume that you have created a user called "peter" on smallfry.

Using default port 22

[root@bigboy tmp]# ssh -l peter smallfry

Using port 435

[root@bigboy tmp]# ssh -l peter -p 435 smallfry

What To Expect With Your First Login

The first time you log in, you will get a warning message saying that the remote host doesn't know about your machine and will prompt you to store a copy of the remote host's SSH identification keys on your local machine. It will look something like this:

[root@bigboy tmp]# ssh smallfry
The authenticity of host 'smallfry (smallfry)' can't be established.

RSA key fingerprint is 5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'smallfry' (RSA) to the list of known hosts. root@smallfry's password:
Last login: Thu Nov 14 10:18:45 2002 from 192.168.1.98
No mail.

[root@smallfry tmp]#

The key is stored in your ~/.ssh/known_hosts file and you should never be prompted for this again.

SSH Failures Due To Linux Reinstallations

If Linux or SSH is reinstalled on the remote server then the keys are regenerated and your SSH client will detect that this new key doesn't match the saved value in the known_hosts file. The SSH client will fail giving an error like this, erring on the side of caution to alert you to the possibility of  a form of hacking attack.

[root@bigboy tmp]# ssh 192.168.1.102

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@Ă‚ Ă‚ Ă‚ Ă‚ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that the RSA host key has just been changed.

The fingerprint for the RSA key sent by the remote host is

5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.

Please contact your system administrator.

Add correct host key in /root/.ssh/known_hosts to get rid of this message.

Offending key in /root/.ssh/known_hosts:2

RSA host key for 192.168.1.102 has changed and you have requested strict checking.

Host key verification failed.

[root@bigboy tmp]#

If you are confident that this is due to a reinstallation, then you need to edit your ~/.ssh/known_hosts text file and remove the entry for the offending remote server. Once this is done, try connecting via SSH again, you'll be prompted to ad the new key to your ~/.ssh/known_hosts file and the login session should proceed as normal after that.

Deactivating Telnet once SSH is installed

You should always consider the use of SSH more favorably than that of Telnet because of the inherent data encryption features of SSH and the current widespread availability of SSH clients for both Linux and Windows.

By default, the Telnet server isn't installed with Fedora Linux. If you do decide to deactivate an active Telnet server on Fedora, then use the chkconfig command as detailed in Chapter 16.

[root@bigboy tmp]# chkconfig telnet off

Using SSH To Execute Remote Commands On Demand

A nice feature of SSH is that it is capable of logging in and executing single commands on a remote system. You just have to place the remote command, enclosed in quotes, at the end of the ssh command of the local server. In the example below, a user on server "smallfry" who needs to know the version of the kernel running on server "bigboy" (192.168.1.100) remotely runs the "uname -a". The command returns the version of 2.6.8-1.521 and the server's name, "bigboy".

[root@smallfry tmp]# ssh 192.168.1.100 "uname -a"

root@192.168.1.100's password:

Linux bigboy 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386 GNU/Linux

[root@smallfry tmp]#

This feature can be very useful. You can combine it with password-less login, explained later in this chapter, to get the status of a remote server whenever you need it. More comprehensive monitoring may best be left to purpose built programs like MRTG covered in Chapter 22.

Using SCP as a more secure replacement for FTP

From a networking perspective, FTP isn't very secure as usernames, passwords and data are sent across the network unencrypted. More secure forms such as SFTP (Secure FTP) and SCP (Secure Copy) are available as a part of the OpenSSH package that is normally installed by default on RedHat and Fedora Core. Remember, unlike FTP, SCP doesn't support anonymous downloads like FTP.

The Linux scp command for copying files has a format similar to that of the regular Linux cp command. The first argument is the source file and the second is the destination file. When copying to/from a remote server, SCP logs in to the server to transfer the data and this therefore requires you to supply a remote server name, username and password to successfully execute the command. The remote filename is therefore preceded by a prefix of the remote username and server name separated by an "@" symbol. The remote filename or directory then follows separated by a colon. The format therefore looks like this:

username@servername:filename

username@servername:directoryname

For example file /etc/syslog.conf on a server with IP address 192.168.1.100 that needs to be retrieved as user "peter" would have the format peter@192.168.1.000:/etc/syslog.conf, the entire /etc directory would be peter@192.168.1.000:/etc/.

Note: There is an easy to use Windows SCP client called WinSCP which can be downloaded at http://winscp.vse.cz/eng/

Copying Files To The Local Linux Box

With an understanding of the representation of remote filenames by scp it becomes fairly easy to start copying files. Here are some examples:

Copy file /tmp/software.rpm on the remote machine to the local directory /usr/rpm

[root@bigboy tmp]# scp root@smallfry:/tmp/software.rpm /usr/rpm

root@smallfry's password:

software.rpm 100% 1011 27.6KB/s 00:00

[root@bigboy tmp]#

Copy file /tmp/software.rpm on the remote machine to the local directory /usr/rpm using TCP port 435

[root@bigboy tmp]# scp -P 435 root@smallfry:/tmp/software.rpm /usr/rpm

root@smallfry's password:

software.rpm 100% 1011 27.6KB/s 00:00

[root@bigboy tmp]#

Copying Files To The Remote Linux Box

Copying files to the local Linux server now becomes intuitive. Here are some examples:

Copy file /etc/hosts on the local machine to directory /tmp on the remote server.

[root@bigboy tmp]# scp /etc/hosts root@192.168.1.103:/tmp

root@192.168.1.103's password:

hosts 100% 1011 27.6KB/s 00:00

[root@bigboy tmp]#

Copy file /etc/hosts on the local machine to directory /tmp on the remote server using TCP port 435

[root@bigboy tmp]# scp -P 435 /etc/hosts root@192.168.1.103:/tmp

hosts 100% 1011 27.6KB/s 00:00

[root@bigboy tmp]#

Using SFTP as a more secure replacement for FTP

OpenSSH also has the SFTP program which runs over an encrypted SSH session but whose commands mimic those of FTP. SFTP can be more convenient to use than SCP when you are uncertain of the locations of the files you want to copy as it has the directory browsing abilities of FTP. Unlike FTP, SFTP doesn't support anonymous logins.

Here is a sample login sequence that logs in, gets help on the available commands and downloads a file to the local server.

[root@bigboy tmp]# sftp 192.168.1.200

Connecting to 192.168.1.200...

root@192.168.1.200's password:

sftp> help

Available commands:

cd path                       Change remote directory to 'path'

lcd path                      Change local directory to 'path'

chgrp grp path                Change group of file 'path' to 'grp'

chmod mode path               Change permissions of file 'path' to 'mode'

...

...

sftp> ls

..

..

anaconda-ks.cfg

install.log

install.log.syslog

..

..

sftp> get install.log

install.log                        100%   17KB  39.4KB/s  00:00

sftp> exit

[root@bigboy tmp]#

Ă‚

Using SSH and SCP without a password

From time to time you may want to write scripts that will allow you to copy files to a server, or login, without being prompted for passwords. This can make them simpler to write and also prevents you from having to embed the password in your code.

SCP has a feature which allows you to do this. You no longer have to worry about prying eyes seeing your passwords nor worrying about your script breaking when someone changes the password. You can configure SSH to do this by generating and installing encryption keys for the data transfer that are tied to the IP addresses of the two servers. The servers then use these pre-installed keys to authenticate one another for each file transfer. As you may expect, this feature doesn't work well with computers with IP addresses that periodically change such as those obtained via DHCP.

There are some security risks though. The feature is automatically applied to SSH as well. There is the possibility of someone using your account to login to the target server by entering the username alone. It is therefore best to implement this using unprivileged accounts on both the source and target servers.

In the case below, we'll be enabling this feature in one direction (from server "bigboy" to server "smallfry") and only using the unprivileged account called "filecopy".

Configuration - Client Side

Here are the steps you need to do on the computer which will be acting as the SSH client:

Ă‚

1.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Generate your SSH encryption keypair for the "filecopy" account. Hit the enter key each time you are prompted for a password to be associated with the keys. (ie. Do NOT enter a password.)

Ă‚

[filecopy@bigboy filecopy]# ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key

(/filecopy/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in

/filecopy/.ssh/id_dsa.

Your public key has been saved in

/filecopy/.ssh/id_dsa.pub.

The key fingerprint is:

1e:73:59:96:25:93:3f:8b:50:39:81:9e:e3:4a:a8:aa

filecopy@bigboy

[filecopy@bigboy filecopy]#

Ă‚

2.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ These keyfiles are stored in the .ssh subdirectory of your home directory. View the contents of that directory. The file named "id_dsa" is your private key, and "id_dsa.pub" is the public key which you will be sharing with your target server. Non RedHat / Fedora versions may use different filenames, use the SSH man pages to verify this.

Ă‚

[filecopy@bigboy filecopy]# cd ~/.ssh

[filecopy@bigboy filecopy]# ls

id_dsa  id_dsa.pub  known_hosts

[filecopy@bigboy .ssh]#

Ă‚

3.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Copy the ONLY public key to the home directory of the account to which you will be sending the file.

Ă‚

[filecopy@bigboy .ssh]# scp id_dsa.pub filecopy@smallfry:public-key.tmp

Ă‚

Configuration - Server Side

Here are the steps you need to do on the computer that will act as the SSH server.

Ă‚

4.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Now log into smallfry as user "filecopy". Create a ".ssh" sub directory in your home directory and then "cd" into it.

Ă‚

[filecopy@smallfry filecopy]# ls

public-key.tmp

[filecopy@smallfry filecopy]# mkdir .ssh

[filecopy@smallfry filecopy]# chmod 700 .ssh

[filecopy@smallfry filecopy]# cd .ssh

Ă‚

5.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Append the public-key.tmp file to the end of the authorized_keys file using the ">>" append redirector with the cat command. The authorized_keys file contains a listing of all the public keys from machines that are allowed to connect to your smallfry account without a password. Non RedHat / Fedora versions may use different filenames, use the SSH man pages to verify this.

Ă‚

[filecopy@smallfry .ssh]# cat ~/public-key.tmp >>

authorized_keys

[filecopy@smallfry .ssh]# rm ~/public-key.tmp

Ă‚

From now on you can ssh and scp as user "filecopy" from server bigboy to smallfry without being prompted for a password.

na kratko:

As you know, the main feature of OpenSSH is to establish secure connections to remote machines, so you get interactive sessions against them. However, OpenSSH also allows you to execute commands on remote machines. You can execute commands and have the output returned to the screen without logging in to the remote machine. Further more you can use tar over ssh.

Editing remote files with OpenSSH

To execute a command remotely simply type (rhost = remote_host):

ssh user@rhost 'ls -al /etc'


However, some commands require a terminal to run properly. For example, if you want to edit a remote file using vi you probably will try something like this:

ssh user@rhost 'vi /etc/passwd'


And you'll get warnings like this:

Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal

To avoid such warnings and cleanly edit your remote files type the following:

ssh -t user@rhost 'vi /etc/passwd'


The -t option will... (from OpenSSH man pages)

Force pseudo-tty allocation. This can be used
to execute arbitrary screen-based programs on a
remote machine, which can be very useful, e.g.,
when implementing menu services.
Multiple -t options force tty allocation, even
if ssh has no local tty.

Backing Up with tar over ssh

Shuffling files between servers is simple with scp:

scp some-archive.tgz rhost:/usr/local

Or even copying many files at once:

scp rhost:/usr/local/etc/* .

But scp isn't designed to traverse subdirectories and preserve ownership and permissions. Fortunately, tar is one of the very early (and IMHO, most brilliant) design decisions in ssh to make it behave exactly as any other standard Unix command. When it is used to execute commands without an interactive login session, ssh simply accepts data on STDIN and prints the results to STDOUT. Think of any pipeline involving ssh as an easy portal to the machine you're connecting to. For example, suppose you want to backup all of the home directories on one server to an archive on another:

tar zcvf - /home | ssh rhost "cat > homes.tgz"

Or even write a compressed archive directly to a tape drive on the remote machine:

tar zcvf - /home | ssh rhost "cat > /dev/tape"

Suppose you wanted to just make a copy of a directory structure from one machine directly into the filesystem of another. In this example, we have a working Apache on the local machine but a broken copy on the remote side. Let's get the two in sync:

cd /usr/local
tar zcf - apache/ \
| ssh rhost \
"cd /usr/local; mv apache apache.bak; tar zpxvf -"

This moves /usr/local/apache/ on rhost to /usr/local/apache.bak/, then creates an exact copy of /usr/local/apache/ from my localhost, preserving permissions and the entire directory structure. You can experiment with using compression on both ends or not (with the z flag to tar), as performance will depend on the processing speed of both machines, the speed (and utilization) of the network, and whether you're already using compression in ssh.

Finally, let's assume that you have a large archive on the local machine and want to restore it to the remote side without having to copy it there first (suppose it's really huge, and you have enough space for the extracted copy, but not enough for a copy of the archive as well):

ssh rhost "cd /usr/local; tar zpvxf -" \
< really-big-archive.tgz

Or alternately, from the other direction:

ssh rhost "cat really-big-archive.tgz" | tar zpvxf -

f you encounter problems with archives created or extracted on the remote end, check to make sure that nothing is written to the terminal in your ~/.bashrc on the remote machine. If you like to run /usr/games/fortune or some other program that writes to your terminal, it's a better idea to keep it in ~/.bash_profile or ~/.bash_login than in ~/.bashrc, because you're only interested in seeing what fortune has to say when there is an actual human being logging in and definitely not when remote commands are executed as part of a pipeline. You can still set environment variables or run any other command you like in ~/.bashrc, as long as those commands are guaranteed never to print anything to STDOUT or STDERR.

Using ssh keys to eliminate the need for passwords makes slinging around arbitrary chunks of the filesystem even easier (and easily scriptable in cron, if you're so inclined).

Upam da bo kdo tole prebral.