If you are a UNIX sysadmin for any number of servers, you need to build yourself a Linux secure shell (SSH) jumpbox. Do it now! Having a centralized location that you can use to quickly “jump” to any box saves a whole bunch of time. Not only that, it opens opportunities for speeding up repetitive chores, and even automating tasks.
Here I’ll describe some of the things that I have built into my SSH Jumpbox, including some scripts you can put to work for yourself right away.
SSH Keys
It all starts with SSH Keys.SSH can use a set of private/public keys to authenticate your session. Your private key will reside on your Jumpbox, and your public key will be copied out to each of the target servers you are going to manage.
Instead of using your UNIX password on those servers (which may not all be the same), you will use a single passphrase that goes with your private key to do the authentication. You can even leverage the SSH Authentication Agent so that you only have to type that passphrase a couple of times through the course of your day.
To generate the key, you simply need to use the “ssh-keygen” command.
[me@jumpbox ~]$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/me/.ssh/id_rsa): {ACCEPT DEFAULT} Created directory '/home/me/.ssh'. Enter passphrase (empty for no passphrase): {YOUR PASSPHRASE} Enter same passphrase again: {YOUR PASSPHRASE} Your identification has been saved in /home/me/.ssh/id_rsa. Your public key has been saved in /home/me/.ssh/id_rsa.pub. The key fingerprint is: 3d:84:37:43:59:05:ca:e6:2d:59:de:90:36:06:17:24 me@jumpbox
[me@jumpbox ~]$ ls -l ${HOME}/.ssh total 8 -rw-------. 1 me me 1743 Jun 26 14:14 id_rsa -rw-r--r--. 1 me me 390 Jun 26 14:14 id_rsa.pub
It is now time to upload the private key to your target server. The easiest way to do that is using “sftp”.
[me@jumpbox ~]$ sftp me@target Connecting to target... The authenticity of host target (x.x.x.x)' can't be established. RSA key fingerprint is 40:4b:f7:f3:a1:da:dc:59:9c:19:d5:e3:21:f8:a9:ea. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added target,x.x.x.x (RSA) to the list of known hosts. me@target's password: {YOUR PASSWORD} sftp> mkdir .ssh sftp> chmod 700 .ssh Changing mode on /home/me/.ssh sftp> put .ssh/id_rsa.pub .ssh/authorized_keys Uploading .ssh/id_rsa.pub to /home/me/.ssh/authorized_keys sftp> chmod 600 .ssh/authorized_keys Changing mode on /home/me/.ssh/authorized_keys sftp> quit
If this is the first time you are connecting to this host, SFTP will ask you if you trust this host.
Next, you will be required to provide your UNIX password to get authenticated. Hopefully, this is the last time you will need to type that password.
You will now create the .ssh directory (mkdir .ssh) and lock down the permissions (chmod 700 .ssh) on that directory so that only this user can see files in that directory.
You will then upload the public key discussed before, and store it as an authorized_keys file (put .ssh/id_rsa.pub .ssh/authorized_keys). You will lock it down so that only this user can see and alter this file (chmod 600 .ssh/authorized_keys).
WARNING:
If you already have an authorized_keys file, then append your new key to the existing authorized_keys file rather than overwriting it. SFTP the file up to your server with a different name. Then log in to a shell to add the contents of your new file to the original file.That should be all you need to do. Now, test your setup.
[me@jumpbox ~]$ ssh me@target Enter passphrase for key '/home/me/.ssh/id_rsa': {YOUR PASSPHRASE} [me@target ~]$ exit [me@jumpbox ~]$
SSH Configuration Options
There are a few common SSH client options that you may want to consider.EscapeChar @
SSH provides an “escape” mechanism to allow you to interact with the SSH client from an active session. The most common use of this would be to kill the current session if for some reason your shell is hung.The default escape character is a tilde (~). One problem: that’s the default escape character for “tip” on Solaris, and for some Lights Out Management Tools. If you’re running multiple tools, you won’t know which tool is going to catch the escape character first.
The solution is to change your SSH escape character to something unique. I like to use “@”. No other tool that I am aware of uses that. Now, if your session is hung, simply press “@.” and, you will drop your connection. You can also press “@?” to see what other options are available to you.
ForwardX11 yes
You will need to forward X11 traffic to be able to open graphic windows from the target server. There will be more on this topic later.StrictHostKeyChecking no
The SSH client maintains a cache of host public keys. When you connect to new hosts, you will be regularly prompted to add entries to the known_hosts file. Disable this option and SSH will automatically cache these entries without asking you first.All these options are available from the command line using the -o option.
Because you will be using them over and over again, store them in the SSH client config file.
You will want to store them in ${HOME}/.ssh/config.
You will also need to change the permission on the file so only you can access it:chmod 600 ${HOME}/.ssh/config.
SSH Authentication Agent (ssh-agent)
The next useful feature is the SSH Authentication Agent. The idea here is to load up your SSH Key (i.e. enter your passphrase just once), and then use that key to establish new sessions.Here is a sample session:
[me@jumpbox ~]$ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-jVTDW14623/agent.14623; export SSH_AUTH_SOCK; SSH_AGENT_PID=14624; export SSH_AGENT_PID; echo Agent pid 14624; [me@jumpbox ~] SSH_AUTH_SOCK=/tmp/ssh-jVTDW14623/agent.14623 [me@jumpbox ~] export SSH_AUTH_SOCK [me@jumpbox ~] SSH_AGENT_PID=14624 [me@jumpbox ~] export SSH_AGENT_PID [me@jumpbox ~]$ ssh-add –t 14400 Enter passphrase for /home/me/.ssh/id_rsa: {YOUR PASSPHRASE} Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa) Lifetime set to 14400 seconds [me@jumpbox ~]$ ssh me@target Last login: Thu Jun 27 12:58:16 2013 from jumpbox [me@target ~]$ exit [me@jumpbox ~]
Let’s step through the transaction.
The “ssh-agent” command starts up the agent. It reports to the user where it’s running by giving us some environment variables to load into the shell. Set those variables as detailed by the agent output.Next, load up our current private key and its passphrase. It will be stored in the agent. The -t option sets the “time-to-live” for the key. My preference is a four-hour time-to-live (4 hours * 60 Mins/Hour * 60 Secs/Min = 14,440 Secs). This means you are prompted for a key when you start your day, and again when you come back from lunch.
Start up a session that uses that key. Notice it did not prompt for a passphrase. It retrieved that information from the agent.
The ssh2host Script
Here is a script that ties all of this together. On the first run, it starts up the SSH Authentication Agent, loads your private key into memory, and then starts an SSH session to the client. On subsequent runs, it connects to the existing agent and the keys it has loaded, so you won’t be prompted for your password again.But here’s the really neat thing. It creates hard links to this script with names that match your target hosts (and makes sure those files are in your system path). You can now SSH to these systems by simply typing their name.
#!/bin/bash ############################################## # This script should be hard-linked with the name # of the target server. It will try to ssh to # a client with that name. (ln ssh2host target) ############################################## # Where to store and read information about current agent. SSH_AGENT_INFO=${HOME}/.ssh_agent_info [ -f ${SSH_AGENT_INFO} ] && . ${SSH_AGENT_INFO} > /dev/null # The SSH_AGENT_PID should have the PID for the current agent. # And there should be only one ssh-agent running with that PID. ALL_GOOD=YES # Assume all is good to start. if [ ! -n "${SSH_AGENT_PID}" ] # The variable is not set. then ALL_GOOD=NO else # The ssh-agent isn't running. if [ `ps -ef | grep "ssh-agent" | grep "${SSH_AGENT_PID}" |\ grep -v grep | wc -l` -ne 1 ] then ALL_GOOD=NO fi fi # If we had problems - start the ssh-agent up. [ "${ALL_GOOD}" = "NO" ] && /usr/bin/ssh-agent > ${SSH_AGENT_INFO} && \ . ${SSH_AGENT_INFO} > /dev/null # Is the key loaded? If not, load it now. /usr/bin/ssh-add -l > /dev/null [ $? -ne 0 ] && /usr/bin/ssh-add -t 14400 # Time to start the SSH session to the host.. /usr/bin/ssh -X -e @ -o StrictHostKeyChecking=no `basename $0`
[me@jumpbox ~]$ target Enter passphrase for /home/me/.ssh/id_rsa: {ENTER PASSPHRASE} Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa) Lifetime set to 14400 seconds Last login: Thu Jun 27 16:36:13 2013 from target [me@target ~]$ exit logout Connection to target closed. [me@jumpbox ~]$ target Last login: Thu Jun 27 16:36:44 2013 from target [me@target ~]$ exit logout Connection to target closed.
Troubleshooting:
Stale Host Keys
Take a look at the files in your .ssh directory. You’ll notice that you now have a known_hosts file. This is where the target host keys are stored.[me@jumpbox ~]$ ls -l ${HOME}/.ssh total 12 -rw-------. 1 me me 1743 Jun 26 15:17 id_rsa -rw-r--r--. 1 me me 390 Jun 26 15:17 id_rsa.pub -rw-r--r--. 1 me me 790 Jun 26 15:27 known_hosts
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 40:4b:f7:f3:a1:da:dc:59:9c:19:d5:e3:21:f8:a9:ea. Please contact your system administrator. Add correct host key in /home/me/.ssh/known_hosts to get rid of this message. Offending key in /home/me/.ssh/known_hosts:2 Password authentication is disabled to avoid man-in-the-middle attacks. Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks. X11 forwarding is disabled to avoid man-in-the-middle attacks.
DNS Issues
If after executing the SSH command, the connection is established, but it takes a minute or so to actually get anywhere, look for DNS issues.Ensure both your Jumpbox and your target servers are properly set up (both forward and reverse) on your DNS server. If this is not possible, then fake out DNS by putting IP’s into /etc/hosts on both the Jumpbox and the target server.
You can also look at disabling DNS on the SSH Daemon on the target server. (Look for the “UseDNS” entry in /etc/ssh/sshd_config file on your target server).
Host Side Firewalls
IP Tables are enabled on most Linux systems. You’ll need to open up the SSH port on the target server to ensure that SSH traffic can get into your target server./sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPTAnother common method to restrict access to your target servers is TCP Wrappers. If that is enabled on your target host, you should add an entry to your hosts.allow file for the SSH protocol.
echo “sshd: ALL” >> /etc/hosts.allowFile Permissions
SSH likes its settings files locked down. File and directory modes should all be set so that no “group” or “other” permissions are granted.chmod –R go= ${HOME}/.sshYou may also want to look at the SSH Daemon on your target server and disable the “StrictModes” directive in /etc/ssh/sshd_config file.
Root Logins
Direct root logins are discouraged as a general practice for security reasons. However, that’s one practice that I usually ignore so that I can do other interesting things.If you’re looking to log in as root directly, look for the “PermitRoot” directive in the /etc/ssh/sshd_config file on your target server. I recommend the “without-password” setting. This will allow you to log in using a private/public key pair, and still prevent direct root access with username/password.
0 comments:
Post a Comment