 | Open Secure Shell OpenSSHSecure Shell is a package that provides a secure, encrypted replacement for telnet, rsh, rcp, and other insecure clear text programs. It consists of a server daemon (sshd) and client programs (ssh and scp) that encrypt all communications between computers. When you use ssh to connect to an sshd server, you get a secure remote shell on the computer running sshd and can issue commands as if connected with telnet. The original author of SSH released the early versions as open source, then formed a commercial company that now sells proprietary SSH software for unix, linux, and windows platforms. The open source community took the original release and continues to enhance it as the OpenSSH project. This text focuses on Open SSH even though it is referred to as SSH. ImportantSSH communicates over TCP/IP port 22 by default. The global server configuration file is/etc/ssh/sshd_config To deny root logins, use this setting in the server configuration file
PermitRootLogin no
The reason you would want to block remote root logins is to make it twice as hard to break for a cracker to break into your system. If someone guessed, found out, or brute forced the root password, all they have to do is ssh into your server and they have control. However, if you don't allow root logins, they would have to first break into it as an ordinary user, then get the root password. To disable X forwarding, use this setting in the /etc/ssh/sshd_config file:
X11Forwarding no
By default, if you have an X11 session running on your server, sshd will forward the session to you when you connect. Sometimes, this might be what you want, but usually it isn't. When sshd runs for the first time, it generates three cryptographic key pairs and stores the keys in:
Note
The global client configuration file is /etc/ssh/ssh_config If you want to override the global client configuration, create and edit ~/.ssh/config To set the preferred protocols, use these options in the client configuration file
Cipher blowfish
Ciphers blowfish-cbc,cast128-cbc,3des-cbc
The Cipher line is for v1 connections, the Ciphers line is for v2 connections. The default is for ssh to try to connect using v2, then fall back to v1 if the server only supports v1. I prefer to use blowfish first because it is probably the fastest protocol available, easy to implement and verify. I generally trust blowfish because I am very familiar with it. TipTo force ssh to use a specific protocol version when connecting
To connect using a different user ID than your current ID
ssh <user-name>@<server-name-or-IP>
For example, ssh root@192.168.1.15 attempts to login as root on 192.168.1.15 . NoteIf you are using a Windows™ machine, putty is a nice freeware ssh client. Secure copy (scp) is a small program that can be used to securely transfer files between machines. It is a replacement for the rcp program. To upload a local file to a remote machine:
scp local-file user-name@server-name-or-IP:remote-file
This will prompt you for the password, then copy the local-file to the remote-file. If no path is given for remote-file, it is copied to remote user's home directory. (for root, it is copied to /root) To download a remote file from a remote machine
scpuser-name@server-name-or-IP:remote-filelocal-file
NoteYou do NOT have to establish an ssh session before using scp, it is set up and torn down as needed for the file transfer. The default way to authenticate using ssh connections is by entering a password for the remote user when prompted. Another way to authenticate is by using cryptographic key pairs, with the public key stored on the sshd server machine. The ssh-agent program automates using these keys by running in the background and providing the private key to ssh when it is required for authentication. This is tricky to set up, but makes it very easy to connect to multiple servers quickly if you need to manage them daily. The idea is that ssh-agent is started in the beginning of a login session, where it exports environment variables, then runs in the background waiting to negotiate any ssh connections attempted in the future. You add identities (private keys) to the agent with ssh-add. Now, all child processes can use the agent when connecting to remote hosts so you don't have to type your passphrases for your keys (more than once when ssh-agent loads the key). To generate ssh client authentication keys, use
ssh-keygen -t rsa | -t dsa
With no parameters, it generates v1 keys. Using -t rsa or -t dsa generates v2 keys. When you run ssh-keygen, it will prompt you for a passphrase. The passphrase is used to encrypt your key files so someone else can't use them if they get a copy of them. When you use your keys, it will prompt you for the passphrase to decrypt them. Each set of keys can have a different passphrase. If it did not encrypt the key files, anyone who got a copy of them could log into any server set up with your public keys. Here are the key files:
Procedure 1. Using keys To use your keys on a remote server,
Sshd will use the key to encrypt a session key and send it to the remote client. If the client can decrypt it, it is allowed to connect as that user, otherwise, no go. Normally, you would have to enter your passphrase each time you used your keys this way. But that's not much better than just entering a password each time. The answer is ssh-agent, which runs in the background and negotiates logins on your behalf using your secret key. You have to decrypt your key once for ssh-agent to use, then you are set. Now, open an X term and run
ssh-add ~/.ssh/id_dsa other-files
to add your private keys to the ssh-agent process. It will prompt for the passphrase of each one. Now, when you ssh into a remote server that has your public key, you don't have to type a password, you are logged in securely using public key cryptography. If you want to work in X and have the ssh-agent in the background all the time, you need to load it in the console prior to starting X. A logical choice would be to run it in your login script so it will be available in all your processes. Using the ssh-agent may not be worth the set up if you only need to access one or two servers. If you regularly need to access a dozen, it can be a real time saver. NoteThe home directory of the user where the authorized_keys[2] are stored must NOT be writable by anyone but the user. Also, the authorized_key files themselves can't be readable by anyone but the user (mode 600 or 700). Otherwise, ssh will refuse to authenticate you using the keys and prompt for a password. The creator of the Gentoo Linux distribution wrote a bash script that makes using ssh-agent even easier. You can download the latest version at: http://www.gentoo.org/keychain This is a script you can put in one of your login scripts (I use .bash_login) and it loads your keys and starts the agent, prompting for the passphrases if necessary. It won't start multiple copies of the agent and it does several other nice management things as well. If you plan to use ssh-agent daily, this is a worthy download. Forwarding of arbitrary TCP/IP connections over the secure channel can be specified either on command line or in a configuration file. forward port < 1024, you have to connect to the remote machine as root, and may be disabled for security reasons. The general syntax for port forwarding is
-L port:host:hostport -- redirect a local port to a remote host:hostport
-R port:host:hostport -- redirect a remote port to a local host:hostport
This forwards local connections to port 8080 to port 80 of a web server possibly on the other side of the remote sshd server:
ssh -L 8080:remote-web-server-or-IP:80 root@sshd-server-or-IP
|
|
