|[ Team LiB ]|
Secure Shell Commands
Secure Shell commands enable users to securely access a remote host on an unsecured network. Passwords, public keys, or both provide authentication. All network traffic is encrypted to prevent others from reading an intercepted communication or spoofing the system.
The Solaris 9 release provides the Secure Shell commands described in Table 81 to communicate among systems.
Users can be authenticated with an account password or with a public/private key pair stored on the local host in the user's home directory in the .ssh subdirectory. The remote host is provided with the public key, which is required to complete the authentication. Table 82 lists the default names for the identity files that store the public and private keys.
Secure Shell supports two versions of the Secure Shell protocol: the original version 1 and the more secure version 2. Version 2 also amends some of the basic security design flaws of version 1. Version 1 use is discouraged, and the SSH server daemon's configuration file turns on only SSH v2 compatibility (see the Protocol line in /etc/ssh/sshd_config). Version 1 is provided only to assist users migrating to version 2.
Table 83 lists the authentication methods and local and remote host requirements.
.rhosts provides only weak security, and SSH in the Solaris 9 Operating Environment is, by default, configured to ignore .rhosts completely.
.rhosts with RSA (v1) and password-based authentication (v1 or v2) provide medium security. RSA public key (v1) and RSA/DSA public key (v2) provide strong security. Password-based authentication is the default.
Benefits of SSH
SSH provides a secure replacement for the rsh, rlogin, rcp, telnet, and ftp commands. It automatically tunnels X11 traffic and allows authentication with passwords, Kerberos 4 and 5, and public keypairs.
With Secure Shell, you can log in to another host securely over an unsecured network, copy files securely between two hosts, and run commands securely on the remote host.
At boot time, the /etc/init.d/sshd script normally starts the sshd Secure Shell daemon. The daemon listens for connections from clients. When the user runs the ssh, scp, or sftp command, a Secure Shell session begins. A new sshd daemon is forked for each incoming connection to handle key exchange, encryption, authentication, command execution, and data exchange with the client. The client-side configuration files and server-side configuration files determine the session characteristics. After the authentication succeeds, the user can execute commands remotely and copy data between hosts.
Configuring Secure Shell Clients
The client-side characteristics of a Secure Shell session are usually governed by the systemwide configuration file /etc/ssh/ssh_config, which the administrator sets up. Users can override settings in the systemwide configuration file with the configuration in the user's $HOME/.ssh_config file. In addition, the user can override both configuration files on the command line.
The default /etc/ssh/ssh_config file is shown below.
# Copyright (c) 2001 by Sun Microsystems, Inc. # All rights reserved. # # ident "@(#)ssh_config 1.2 01/10/08 SMI" # # This file provides defaults for ssh(1). # The values can be changed in per-user configuration files $HOME/.ssh/config # or on the command line of ssh(1). # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file /etc/ssh/ssh_config # # Any configuration value is only changed the first time it is set. # host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Example (matches compiled in defaults): # # Host * # ForwardAgent no # ForwardX11 no # PubkeyAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking ask # EscapeChar ~
Lines have the format keyword arguments and are case sensitive.
Table 84 lists valid keywords and their descriptions.
You determine the authentication method for a client by setting one of the following keywords to yes.
Configuring Secure Shell Servers
The server-side characteristics of a Secure Shell session are usually governed by the systemwide configuration file /etc/ssh/sshd_config, which the administrator sets up. Users can override settings in the system-wide configuration file with the configuration in the user's $HOME/.ssh_config file only if the user runs his own copy of the sshd daemon on a nonprivileged port. In addition, the user can override both configuration files on the command line.
The default /etc/ssh/sshd_config file is shown below.
# Copyright (c) 2001 by Sun Microsystems, Inc. # All rights reserved. # # ident "@(#)sshd_config 1.3 01/10/08 SMI" # # Configuration file for sshd(1m) # Protocol versions supported # # The sshd shipped in this release of Solaris has support for major versions # 1 and 2. It is recommended due to security weaknesses in the v1 protocol # that sites run only v2 if possible. Support for v1 is provided to help sites # with existing ssh v1 clients/servers to transition. # Support for v1 may not be available in a future release of Solaris. # # To enable support for v1 an RSA1 key must be created with ssh-keygen(1). # RSA and DSA keys for protocol v2 are created by /etc/init.d/sshd if they # do not already exist, RSA1 keys for protocol v1 are not automatically created. # Uncomment ONLY ONE of the following Protocol statements. # Only v2 (recommended) Protocol 2 # Both v1 and v2 (not recommended) #Protocol 2,1 # Only v1 (not recommended) #Protocol 1 # Listen port (the IANA registered port number for ssh is 22) Port 22 # The default listen address is all interfaces, this may need to be changed # if you wish to restrict the interfaces sshd listens on for a multi homed host. # Multiple ListenAddress entries are allowed. # IPv4 only #ListenAddress 0.0.0.0 # IPv4 & IPv6 ListenAddress :: # Port forwarding AllowTcpForwarding no # If port forwarding is enabled, specify if the server can bind to INADDR_ANY. # This allows the local port forwarding to work when connections are received # from any remote host. GatewayPorts no # X11 tunneling options X11Forwarding no X11DisplayOffset 10 # The maximum number of concurrent unauthenticated connections to sshd. # start:rate:full see sshd(1) for more information. # The default is 10 unauthenticated clients. #MaxStartups 10:30:60 # Banner to be printed before authentication starts. #Banner /etc/issue # Should sshd print the /etc/motd file and check for mail. # On Solaris it is assumed that the login shell will do these (eg /etc/profile). PrintMotd no CheckMail no # KeepAlive specifies whether keep alive messages are sent to the client. # See sshd(1) for detailed description of what this means. # Note that the client may also be sending keep alive messages to the server. KeepAlive yes # Syslog facility and level SyslogFacility auth LogLevel info # # Authentication configuration # # Host private key files # Must be on a local disk and readable only by the root user (root:sys 600). HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Default Encryption algorithms and Message Authentication codes Ciphers aes128-cbc,blowfish-cbc,3des-cbc MACS hmac-sha1,hmac-md5 # Length of the server key # Default 768, Minimum 512 ServerKeyBits 768 # sshd regenerates the key every KeyRegenerationInterval seconds. # The key is never stored anywhere except the memory of sshd. # The default is 1 hour (3600 seconds). KeyRegenerationInterval 3600 # Ensure secure permissions on users .ssh directory. StrictModes yes # Length of time in seconds before a client that hasn't completed # authentication is disconnected. # Default is 600 seconds. 0 means no time limit. LoginGraceTime 600 # Maximum number of retries for authentication # Default is 6. Default (if unset) for MaxAuthTriesLog is MaxAuthTries / 2 MaxAuthTries 6 MaxAuthTriesLog 3 # Are logins to accounts with empty passwords allowed. # If PermitEmptyPasswords is no, pass PAM_DISALLOW_NULL_AUTHTOK # to pam_authenticate(3PAM). PermitEmptyPasswords no # To disable tunneled clear text passwords, change PasswordAuthentication to no. PasswordAuthentication yes # Use PAM via keyboard interactive method for authentication. # Depending on the setup of pam.conf(4) this may allow tunneled clear text # passwords even when PasswordAuthentication is set to no. This is dependent # on what the individual modules request and is out of the control of sshd # or the protocol. PAMAuthenticationViaKBDInt yes # Are root logins permitted using sshd. # Note that sshd uses pam_authenticate(3PAM) so the root (or any other) user # maybe denied access by a PAM module regardless of this setting. # Valid options are yes, without-password, no. PermitRootLogin no # sftp subsystem Subsystem sftp /usr/lib/ssh/sftp-server # SSH protocol v1 specific options # # The following options only apply to the v1 protocol and provide # some form of backwards compatibility with the very weak security # of /usr/bin/rsh. Their use is not recommended and the functionality # will be removed when support for v1 protocol is removed. # Should sshd use .rhosts and .shosts for password less authentication. IgnoreRhosts yes RhostsAuthentication no # Rhosts RSA Authentication # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts. # If the user on the client side is not root then this won't work on # Solaris since /usr/bin/ssh is not installed setuid. RhostsRSAAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication. #IgnoreUserKnownHosts yes # Is pure RSA authentication allowed. # Default is yes RSAAuthentication yes
Lines have the format keyword arguments and are case sensitive.
Table 85 lists valid keywords and their descriptions.
You determine the authentication method for a server by setting one of the following keywords to yes.
The X Window system (also known as X11) lets you log in to a remote system, run X11 programs on that system, and, if the X11 server program running on your local system controls the monitor at which you are working, displays the X11 program output there. If you use the Solaris rsh, rlogin, or telnet commands without SSH to log in to that remote system, you need to perform the following manual steps for this process to work properly.
The Secure Shell automates the X11 forwarding process and secures it by encrypting the X11 datastreams as they pass over the network. Sun disables the X11 forwarding feature by default. You must enable it for both the client and server by making the following changes to both the local and remote systems.
In the /etc/ssh/ssh_config file, change
# ForwardX11 no
Be sure to remove the # comment character at the beginning of the line as well.
This change takes effect the next time you run ssh.
In the /etc/ssh/sshd_config file, change
To make this change take effect, restart the Secure Shell daemon on both systems by running
# /etc/init.d/sshd stop # /etc/init.d/sshd start
You can now use ssh to log in to the remote system. Run an X11 client such as xterm to verify that X11 Forwarding works properly. If the xterm window is displayed on your local X11 display, then everything is working.
Public Key Authentication with the Secure Shell
The examples in this section assume that you have a single home directory that is automounted on every system under your control at /home/ username. By convention, this directory is referenced with the environment variable $HOME. If you have a unique account and home directory on every system that you log in to, then a reference to the $HOME/.ssh/ directory implies that this directory exists on every system (that is, you need to copy the contents of that directory to each unique home directory you have before the procedures in this section work).
The Secure Shell uses regular password authentication by default; that is, when you use ssh to log in to a remote system, you are asked to enter a password to authenticate your account identity. Once you enter the correct password, you are allowed to log in. The Secure Shell also allows you to use public key authentication instead of password authentication. Public key authentication has the following benefits.
The first step in using public key authentication is to generate one or more public/private keypairs with the ssh-keygen(1) command. Refer to the ssh-keygen(1) manual page for detailed information on the different types of keypairs you can generate.
NOTE. You can have more than one keypair, and you can use each for a different purpose. For example, you can have one keypair for logging in as the root user on the Solaris systems on the manufacturing floor, and another for logging in as the backup administrator on the backup server, and so on. By default, the keypairs are stored in your $HOME/.ssh/ directory when you create them.
The following examples create several keypairs. In these examples, $HOME is /home/gmarler.
The following example creates a default 1024-bit RSA keypair. This keypair is treated as your default RSA keypair for use with the SSH v2 protocol. The public key is stored at $HOME/.ssh/id_rsa.pub, and the private key is stored at $HOME/.ssh/id_rsa.
[ns3:/home/gmarler] $ ssh-keygen Enter file in which to save the key(/home/gmarler/.ssh/id_rsa): Generating public/private rsa key pair. Enter passphrase(empty for no passphrase): Enter passphrase. Enter same passphrase again: Enter passphrase again. Your identification has been saved in /home/gmarler/.ssh/id_rsa. Your public key has been saved in /home/gmarler/.ssh/id_rsa.pub. The key fingerprint is: md5 1024 d1:88:b9:5c:f1:28:0f:dd:6e:f3:fc:ea:af:3c:21:ed gmarler@ns3
The following example creates a 768-bit DSA keypair. This keypair is treated as your default DSA keypair for use with the SSH v2 protocol. The public key is stored as $HOME/.ssh/id_dsa.pub, and the private key is stored as $HOME/.ssh/id_dsa.
[ns3:/home/gmarler] $ ssh-keygen -b 768 -t dsa Enter file in which to save the key(/home/gmarler/.ssh/id_dsa): Generating public/private dsa key pair. Enter passphrase(empty for no passphrase): Enter passphrase. Enter same passphrase again: Enter passphrase again. Your identification has been saved in /home/gmarler/.ssh/id_dsa. Your public key has been saved in /home/gmarler/.ssh/id_dsa.pub. The key fingerprint is: md5 768 1d:f0:f5:d5:bd:35:b1:ac:9a:2a:b9:7f:95:14:02:f0 gmarler@ns3
The following example creates a 512-bit RSA1 keypair (for use only with SSH protocol v1). This keypair is treated as your default RSA keypair for use with SSH v1 protocol—SSH v1 supported only the use of RSA keys. The public key is stored at $HOME/.ssh/identity.pub, and the private key is stored at $HOME/.ssh/identity.
[ns3:/home/gmarler] $ ssh-keygen -b 512 -t rsa1 Enter file in which to save the key(/home/gmarler/.ssh/identity): Generating public/private rsa1 key pair. Enter passphrase(empty for no passphrase): Enter passphrase. Enter same passphrase again: Enter passphrase again. Your identification has been saved in /home/gmarler/.ssh/identity. Your public key has been saved in /home/gmarler/.ssh/identity.pub. The key fingerprint is: md5 512 bb:e2:c5:25:4d:d1:89:23:83:9e:89:51:4f:d0:5b:86 gmarler@ns3
The following example creates a 2048-bit RSA keypair for use when you log in to remote systems as the root user.
[ns3:/home/gmarler] $ ssh-keygen -b 2048 -f $HOME/.ssh/rootkey -C "Root Admin Keypair" Generating public/private rsa key pair. Enter passphrase(empty for no passphrase): Enter passphrase. Enter same passphrase again: Enter passphrase again. Your identification has been saved in /home/gmarler/.ssh/rootkey. Your public key has been saved in /home/gmarler/.ssh/rootkey.pub. The key fingerprint is: md5 2048 44:e0:26:4d:6a:93:6c:5c:88:ac:0a:87:e1:d6:ad:8b Root Admin Keypair
The following example creates a 1024-bit RSA keypair, with no passphrase, for use in automated batch jobs to remote systems.
You would use this keypair in cron jobs or scripts that use ssh.
NOTE. Because the keypair is not protected by a passphrase, it is only as secure as the permissions on the files you store it in.
[ns3:/home/gmarler] $ ssh-keygen -b 1024 -f $HOME/.ssh/nopasskey -C "Batch Jobs (no passphrase)" Generating public/private rsa key pair. Enter passphrase(empty for no passphrase): Press Return. Enter same passphrase again: Press Return. Your identification has been saved in /home/gmarler/.ssh/nopasskey. Your public key has been saved in /home/gmarler/.ssh/nopasskey.pub. The key fingerprint is: md5 1024 21:56:cb:8e:fb:1f:d1:1c:14:50:f2:88:09:f7:39:93 Batch Jobs (no passphrase)
Changing the Passphrase of a Private Key
Once you create keypairs, you can manipulate them in various ways. One thing you may want to do fairly often is to change the passphrase on a keypair. The following example changes the passphrase on the 2048-bit RSA keypair created in one of the previous examples.
[ns3:/home/gmarler] $ ssh-keygen -p -f $HOME/.ssh/rootkey Enter old passphrase: Enter old passphrase. Key has comment 'rsa w/o comment' Enter new passphrase(empty for no passphrase): Enter new passphrase. Enter same passphrase again: Enter new assphrase again. Your identification has been saved with the new passphrase.
Using the Public Key in Each Keypair
The public key in each keypair is not used by the Secure Shell client. It is used by sshd on a remote host whenever you try to use ssh to log in to that remote host. But how does sshd on the remote host get access to your public key?
When you use ssh to log in to a remote host, ssh on your local host contacts sshd on the remote host and tells sshd which user you want to log in as. sshd then looks into the .ssh subdirectory of that user's home directory for the authorized_keys file. If any of the public keys stored in that file match the private key you told ssh to use when logging in to the remote host, the Secure Shell grants you access to that account.
The following example logs you in to a remote host as yourself with public key authentication.
In this case, you're logging in as yourself, so you need to append one of your public keys into your $HOME/.ssh/authorized_keys file. For this example, assume that you are the user gmarler and use the key generated in the first example above.
[ns3:/home/gmarler] $ cat $HOME/.ssh/id_rsa.pub >>$HOME/.ssh/authorized_keys
Now you can try to log in to another host (that has the same home directory automounted) with the private key (specifying it with the –i option to ssh) that matches the public key you appended to the authorized_keys file.
[ns3:/home/gmarler] $ ssh -i $HOME/.ssh/id_rsa ns1.gmarler.com Enter passphrase for key '/home/gmarler/.ssh/id_rsa': Enter key passphrase. Last login: Thu Oct 10 18:57:07 2002 from dhcp101.gmarler Sun Microsystems Inc. SunOS 5.8 Generic February 2000 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 Agent pid 17661 [ns1.gmarler.com:/home/gmarler] $
NOTE. The passphrase you are asked for is NOT your login password, but the passphrase entered for the private key when the keypair was created (or last changed).
The following example logs in to a remote host as the root user with public key authentication.
In this case, you're trying to log in to a remote host as the root user, so you need to find some way to first log in to that host as root, then append the specific public key you want to use to that root's authorized_keys file (located at /.ssh/authorized_keys on that host). This time, use the key generated specifically for this purpose in the fourth example above.
NOTE. At this point you're already logged in to the remote host as root.
[ns1.gmarler.com:/] # cat /home/gmarler/.ssh/rootkey.pub >>/.ssh/authorized_keys [ns1.gmarler.com:/] # exit
NOTE. Now you're back on your original system as the user gmarler.
[ns3:/home/gmarler] $ ssh -i $HOME/.ssh/rootkey ns1.gmarler.com -l root Enter passphrase for key '/home/gmarler/.ssh/rootkey': Enter key passphrase. Last login: Thu Oct 10 23:15:47 2002 from ns3 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 [ns1.gmarler.com:/] #
Private Keys and Passphrases
You've probably noticed that a passphrase is usually applied to the private key in each keypair. You apply the passphrase to the private key so that if someone happens to steal your private keys (you don't care if someone takes your public keys; in fact, you want everyone to have them), the thief can't use them. Why not? Because each private key is encrypted with the passphrase you put on it and is useless until it is decrypted.
But, you have to enter a passphrase before using each private key to log in to a remote host, right? That would be true if you used each private key manually, as has been done so far. But that's where the ssh-agent program comes in.
The ssh-agent command has a simple and elegant purpose: it stores one or more of your decrypted private keys in memory so that ssh can use them without prompting you for the passphrase every time you use them. And, if you load all of your private keys into ssh-agent, ssh tries them all in sequence until it finds one that works. You don't have to specify a particular private key on the command line.
How do you use ssh-agent? Each user must configure his login environment to properly start and stop this program for every shell he invokes. The following example shows the necessary changes to $HOME/.profile if you use the sh, ksh, or bash shells.
# Set up SSH-Agent if [ "$SSH_AUTH_SOCK" = "" -a -f /bin/ssh-agent ]; then eval `/bin/ssh-agent` fi # Kill the SSH-Agent when you log out... trap ' test -n "$SSH_AGENT_PID" && eval `/bin/ssh-agent -k` ' 0
The following example shows the changes needed to $HOME/.login and $HOME/.logout if you used the csh or tcsh shells.
$HOME/.login: # Start SSH-Agent eval `/bin/ssh-agent -c` $HOME/.logout: # Kill SSH-Agent if ( "$SSH_AGENT_PID" != "") then eval `/bin/ssh-agent -k` endif
Once you make these changes and log out and back in, each shell started inherits the environment variable settings that ssh-agent sets up (with the eval command) so that ssh knows how to communicate with ssh-agent. Also, the program is terminated whenever you log out, so you don't have hundreds of separate ssh-agent programs cluttering up the system.
Now that ssh-agent has been set up and automatically starts every time you log in, you need to know how to decrypt and load your private keys into it.
You use ssh-add to decrypt and load each private key into your ssh-agent. The following example loads all the private keys you generated earlier. You can load the first three default identity keys (RSA, DSA, RSA1) just by running the ssh-add command with no arguments, as shown in the following example.
[ns3:/home/gmarler] $ ssh-add Enter passphrase for gmarler@ns3: Enter passphrase. Identity added: /home/gmarler/.ssh/identity(gmarler@ns3) Identity added: /home/gmarler/.ssh/id_rsa(/home/gmarler/.ssh/id_rsa) Identity added: /home/gmarler/.ssh/id_dsa(/home/gmarler/.ssh/id_dsa)
NOTE. This example worked this way only because the private keys all had the same passphrase. If they did not, then you would have to enter each passphrase when prompted.
Now load rootkey and nopasskey, as shown in the following example.
[ns3:/home/gmarler] $ ssh-add $HOME/.ssh/rootkey Enter passphrase for /home/gmarler/.ssh/rootkey: Enter passphrase. Identity added: /home/gmarler/.ssh/rootkey(/home/gmarler/.ssh/rootkey) [ns3:/home/gmarler] $ ssh-add $HOME/.ssh/nopasskey Identity added: /home/gmarler/.ssh/nopasskey(/home/gmarler/.ssh/nopasskey)
Notice that nopasskey did not prompt for a passphrase because there is no passkey. It was simply loaded into the ssh-agent.
You can see which keys are loaded into this particular ssh-agent with the ssh-add -l command.
[ns3:/home/gmarler] $ ssh-add -l md5 512 bb:e2:c5:25:4d:d1:89:23:83:9e:89:51:4f:d0:5b:86 gmarler@ns3(RSA1) md5 1024 d1:88:b9:5c:f1:28:0f:dd:6e:f3:fc:ea:af:3c:21:ed /home/gmarler/.ssh/id_rsa(RSA) md5 768 1d:f0:f5:d5:bd:35:b1:ac:9a:2a:b9:7f:95:14:02:f0 /home/gmarler/.ssh/id_dsa(DSA) md5 2048 44:e0:26:4d:6a:93:6c:5c:88:ac:0a:87:e1:d6:ad:8b /home/gmarler/.ssh/rootkey(RSA) md5 1024 21:56:cb:8e:fb:1f:d1:1c:14:50:f2:88:09:f7:39:93 /home/gmarler/.ssh/nopasskey(RSA)
You have now resolved the problem of having to manually enter the passphrase each time you use ssh. Because you now have the rootkey loaded in the ssh-agent, try logging into the remote system as root again.
[ns3:/home/gmarler] $ ssh ns1.gmarler.com -l root Last login: Thu Oct 10 23:16:11 2002 from ns3 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 [ns1.gmarler.com:/] #
Presto! No need to enter a passphrase again (except when you first log in to your account).
The Secure Shell Commands
The following section discusses the ssh, scp, and sftp commands.
NOTE. The examples for these commands use public key authentication, discussed above, instead of password authentication. You won't see the commands prompting for passwords here. If you don't set up public key authentication, then you will be prompted for your account's password.
The ssh command is a secure replacement for rlogin, rsh, and telnet. It takes the same parameters as rlogin and rsh (and many more), so migration to this tool is easy.
The following example logs in to a remote host as the root user.
[ns3:/home/gmarler] $ ssh ns1.gmarler.com -l root Last login: Thu Oct 10 23:51:09 2002 from ns3 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 [ns1.gmarler.com:/] #
The following example creates a tar archive datastream of the ./src directory and transmits it to another host (by logging in to that host as the current user with ssh) to be extracted in the /tmp directory.
[ns3:/home/gmarler] $ tar cf - ./src | ssh ns1.gmarler.com "(cd /tmp; tar xf -)" [ns3:/home/gmarler] $
The scp command is a secure replacement for the rcp command. It takes parameters similar to those of rcp, but is more flexible. The following examples show some ways to use the scp command.
The following example copies the connect.sql file from the current directory to the /tmp directory on host ns1.gmarler.com, as the user gmarler.
[ns3:/home/gmarler] $ scp connect.sql email@example.com:/tmp connect.sql 100% |*****************************| 49 00:00
The following example logs in to host ns1.gmarler.com as user gmarler and copies the file /tmp/connect.sql to the /tmp directory on the local system.
[ns3:/home/gmarler] $ scp firstname.lastname@example.org:/tmp/connect.sql /tmp connect.sql 100% |*****************************| 49 00:00
The following example recursively copies the ./bin/ directory on the local system to the /tmp/bin directory on system ns1.gmarler.com, as user gmarler.
[ns3:/home/gmarler] $ scp -r bin/ email@example.com:/tmp/bin ksh 100% |****************************| 1609 KB 00:03 patch 100% |****************************| 349 KB 00:00
The following example logs in to host ns1.gmarler.com as the root user and copies the /etc/passwd file to the /tmp directory on the local system.
[ns3:/home/gmarler] $ scp firstname.lastname@example.org:/etc/passwd /tmp passwd 100% |****************************| 931 00:00
The sftp command is a secure replacement for the ftp command. It takes parameters similar to those of ftp, but is more flexible.
The following example uses sftp to connect to the host ns1.gmarler.com as the current user, changes to the /tmp directory on the local system, and downloads connect.sql from that system to /tmp on the local system.
[ns3:/home/gmarler] $ sftp ns1.gmarler.com Connecting to ns1.gmarler.com... sftp > lcd /tmp sftp > lpwd Local working directory: /tmp sftp > get /home/gmarler/connect.sql sftp > quit
The following example uses sftp to connect to the host ns1.gmarler.com as the root user, changes to the /tmp directory on the local system, changes to the /etc directory on the remote system, and downloads the passwd file.
[ns3:/home/gmarler] $ sftp email@example.com Connecting to ns1.gmarler.com... sftp > lcd /tmp sftp > lpwd Local working directory: /tmp sftp > cd /etc sftp > pwd Remote working directory: /etc sftp > get passwd sftp > quit
Common Administrative Uses for the Secure Shell
This section describes two common uses for SSH.
Transferring Files Between Systems Securely
Quite often, you need to move files between systems. You can do so securely by using ssh instead of rsh. The following example copies the home directory of the user gmarler from system ns3.gmarler.com to ns1.gmarler.com. This action is done as the root user on ns3.gmarler.com, using public key authentication.
[ns3:/home/gmarler] # cd /home [ns3:/home] # tar cf - gmarler | ssh ns1.gmarler.com -l root "(cd /home; tar xf -)"
Secure Root Login Without Allowing Passwords
You've already seen how to use public key authentication to allow authorized system administrators to log in to remote systems as the root user. This section describes how to make public key authentication the only way a user can log in to a system as the root user. To force such behavior, edit the /etc/ssh/sshd_config file on all systems and change the following line
Once you have made the changes, restart the sshd daemon on each system with the following commands.
# /etc/init.d/sshd stop # /etc/init.d/sshd start
Secure Shell on Pre-Solaris 9 Releases
The Secure Shell provided with Solaris 9 is a Sun-supported port of OpenSSH. If you want to use the Secure Shell on releases of Solaris before Solaris 9, go to the http://www.openssh.com/ Web site, download the source code, compile it, and install it on your pre-Solaris 9 systems.
For More Information
For more information, refer to SSH, The Secure Shell: The Definitive Guide, by Daniel J. Barrett and Richard E. Silverman, O'Reilly & Associates, Inc., 2001.
|[ Team LiB ]|