17 Awesome OpenSSH Hacks You Must Try!

17 Awesome OpenSSH Hacks You Must Try!

Learn some new tricks to enhance your knowledge about OpenSSH which will hep you a lot.    Thursday, August 21, 2014:  Are you pretty much confident about your knowledge of OpenSSH? Then, the following 17 expert tips as well as tricks, will test your knowledge. Here your challenge begins: #1 Detecting MITM attacks If you log into a remote computer for the first time then you are asked whether you want to accept the remote host's public key or not. Well this needs your prior knowledge if you want to do that or not. Chances are there that your session gets hacked through a monkey-in-the-middle attack and all your secrets get stolen. But there is a way to know these prospects. When new key pairs are created they create a unique fingerprint and reandomart image too. #2: Retrieve the fingerprint and randomart image of an SSH key If you copy this while creating new encryption keys, then you can also fetch a key's fingerprint and randomart image anytime which helps in comparing and ensuring that they have not changed: $ ssh-keygen -lvf keyname #3: View all fingerprints and randomart images in known_hosts Try to see all of them in your ~/.ssh/known_hosts file: $ ssh-keygen -lvf ~/.ssh/known_hosts #4: Verify server keys The fingerprint and randomart can be seen from any computer by configuring/etc/ssh/ssh_config. Uncomment the VisualHostKey option and set it to yes: VisualHostKey yes Then login to any remote computer to test it: Now you need a secure method to get verified copies of the fingerprint and randomart images. The risk of a successful MITM attack becomes smaller now. #5: Attach to a remote GNU screen session A GNU screen session can be attached remotely over SSH and you should open a GNU screen session on host1, and connect to it from host2. First open and then detach a screen session on host1, named testscreen: host1 ~ $ screen -S testscreen Then detach from your screen session with the keyboard combination Ctrl+a+d: [detached from 3829.testscreen] Then it can be verified if it's still there with this command: host1 ~ $ screen -ls There is a screen on: 3941.testscreen (03/18/2012 12:43:42 PM) (Detached) 1 Socket in /var/run/screen/S-host1. Then re-attach to your screen session from host2: host1 ~ $ ssh -t terry@uberpc screen -r testscreen If there is only one screen session then you don't need to name the same. #6: Launch a remote screen session You don't have a running screen session? Don't worry, you can launch one remotely: host1 ~ $ ssh -t user@host2 /usr/bin/screen -xRR #7: SSHFS is better than NFS NFS lacks the capability of sshfs in case of a single user who is working on multiple machines. At any rate opening files one at a time over an SSH session for editing is a slow process, so with sshfs you can mount entire directories from remote computers. First create a directory to mount yoursshfs share in: $ mkdir remote2 Then mount whatever remote directory you want: $ sshfs user@remote2:/home/user/documents remote2/ Now the remote directory can be browsed just as a local one, and you can read, copy, move, and edit files, whatever you want. The best thing about sshfs is sshd should be running on your remote machines, and the sshfs command is installed on your client PCs too. #8: Log in and run a command in one step You are able to log in and establish your SSH session and then run commands. But what happens if you have a single command to run? The you must think why not eliminate a step and do it with a single command. Assume you just want to power off a remote computer; you can log in and run the command in one step: carla@local:~$ ssh user@remotehost sudo poweroff This formula works for any command or script. If you want to run a long complex command, and don't want to type it out every time then one way is to put it in a Bash alias and use that. Another way is to put your long complex command in a text file and run it according to the next tip. #9: Putting long commands in text files Put your long command in a plain text file on your local PC, and then use it to log in and run it on the remote PC like: carla@local:~$ ssh user@remotehost "`cat filename.txt`" You should remember that you use straight quotations marks only. #10: Copy public keys the easy way The ssh-copy-id command is not very popular, though it's a great time-saver. This command copies your public key to a remote host in the correct format, and to the correct directory too. It alos allows a safety check to prevent you copy a private key by mistake. Specify which key you want to copy, like this: $ ssh-copy-id -i .ssh/id_rsa.pub user@remote #11: Give SSH keys unique names If we are to talk about key names, you can name them as you want. This helps when you're administering a number of remote computers, which creates private key web-admin and public key web-admin.pub by: $ ssh-keygen -t rsa -f .ssh/web-admin #12: Give SSH keys informative comments Another useful way to label keys is with a comment: $ ssh-keygen -t rsa -C "downtown lan webserver" -f .ssh/web-admin Then you can read your comment which is appended to the end of the public key. #13: Read public key comments $ less .ssh/web-admin.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1 [snip] KCLAqwTv8rhp downtown lan webserver #14: Logging in with server-specific keys Then when you log in, specify which key to use with the -i switch: $ ssh -i .ssh/web-admin.pub user@webserver #15: Fast easy known_hosts key management It's a nice time-saver, and it keeps your ~/.ssh/known_hosts files tidy: using ssh-keygen to remove host keys from the ~/.ssh/known_hosts file. When the remote machine gets new SSH keys you'll get a warning in the time of logging in, that the key has changed. You will find it much faster than manually editing the file and counting down to the correct line to delete: $ ssh-keygen -R remote-hostname #16: SSH tunnel for road warriors If you are using Internet at any hotel or cyber cafe then a nice secure SSH tunnel makes your online adventures safer. You just need a server to control as a central node for escaping from hotspot follies. This is useful for a lot of different tasks. You can use your normal email client to send email, instead of hassling with Web mail or changing SMTP server configuration, and you can also encrypt all traffic between your laptop and home server. First create the tunnel to your personal server: carla@hotel:~$ ssh -f carla@homeserver.com -L 9999:homeserver.com:25 -N This binds port 9999 on your mobile machine to port 25 on your remote server. The remote port should listen to whatever you've configured in your server. Then configure your mail client to use localhost:9999 as the SMTP server and get ready. You can adapt this for any kind of service that you normally use from your home base, and need frequent access to when you're outside home or office. #17: Favorite SSH tip: Evading silly web restrictions It's largely assumed that any public Internet is untrustworthy, so you can tunnel your Web surfing too. Now this tip gets you past untrustworthy networks that might have snoopers, and past any barriers to unfettered Web-surfing. In this case also you just need a server that you control to act as a secure relay; first setup an SSH tunnel to this server: carla@hotel:~$ ssh -D 9999 -C carla@homeserver.com Then configure your Web browser to use port 9999 as a SOCKS 5 proxy. You can test this on your home or business network. Set up the tunnel to a neighboring PC and surf some external Web sites. Then change the SOCKS port number to the wrong number. This prevents your Web browser from connecting to any site. Port numbers above 1024 do not require root privileges, so use these on your laptop or whatever you're using in your travels. Always check /etc/services first to find unassigned ports.