25 Oct 07 SSH - tips and tricks
Many people tend to think of SSH as a secure substitution for insecure telnet remote administration. While basically that is it’s main purpose (SSH is short for secure shell) what you can do with this tool is definitely not limited by only one task…
What will be explained here is mostly about open source implementation of ssh - OpenSSH, so some things might be different if you’re using something else.
Let’s first see about SSH security - is it really so secure? While it’s hard to be exact on this issue one thing is certain - if you’re using SSH protocol use only it’s version 2. SSH protocol version 1 is known to have exploits for some time now and it is definitely not advisable to use it. Sure, it’s not as bad as connecting with telnet, but any reasonably well configured SSH server nowdays will offer you a SSHv2 connection and even might be limited to this option only.
Some specific issues with SSH - if you’re new to it some things might confuse you. For example - when logging in a system that you’ve never logged in before it will prompt you for a authenticity check and display you a key fingerprint.
The authenticity of host ’somerandomserver.com (0.0.0.0)’ can’t be established.
DSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Are you sure you want to continue connecting (yes/no)?
Huh? What happens here - to prevent man-in-the-middle attacks you must be sure that you are always communicating with the right system or you might be sending passwords and other confidential information to anyone who impersonates this system. IP addresses can be spoofed, DNS entries are easily changed ARP poisoning can redirect your traffic and so on… Once you’ve confirmed that this is exactly the system that you want to login to its key will be memorized for later use and you wont see it again …unless somebody tries to fool you - then you’ll get a nice big warning about not matching the hosts keys. Needless to say, if you are not absolutely sure that system you are logging to hasn’t changed it’s keys stay away from further login!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01.
Please contact your system administrator.
So, what exactly is it that is possible to achieve with this tool, or should I say toolbox?
Remote logins
Basic use of ssh client is
ssh hostname
Which will attempt login on host “hostname” on standard SSH port 22. After successful login you can work normally as with console or telnet.
Additional interesting basic options:
-p : port to which you are connecting to (default 22)
-l : login with different username then default (default is current users username; this can be also accomplished as with username@host syntax)
-q and -v : first is for no messages at all (quiet) and second is for verbose debugging messaging
-t and -T : disabling and enabling pseudo-tty generation at servers end (default enabled) - useful if you’re just making port forwarding
-C : request compression of the transmission data (useful for slow connections)
-o : define a option value so values from configuration file can be overridden
-1 or -2 : try only version 1 or 2 of the protocol
SFTP/SCP
Secure alternatives for commonly used (unsecure) protocols - FTP and rcp (remote copy)
scp and sftp accept most of the normal ssh client’s options (attention: port is here defined with -P unlike -p with ssh) but are used only for file transfers. scp for single file transfer and sftp for multiple file transfers.
scp use:
scp ~/somefile hostname:/tmp/somefile
This will copy “somefile” from your home directory to “/tmp/somefile” on remote ssh server. If you ommit path on remote server files will be copied to your home directory on server.
Retrieval of files from remote server isn’t much harder either:
scp hostname:/tmp/somefile ~/somefile_again
Passwordless logins
More appropriate for automated tasks but might help you if you tend to forget passwords. Basically have a private/public key with which you are authenticated on server. Of course, it’s more secure if you have password also setup on your private key - otherwise anyone who steels your private key can login into your servers. Yikes.
By default when connecting your private keys will be searched within ~/.ssh/ folder and are called id_dsa || id_rsa (depending on encryption used), but private key file location can easily be defined with -i option so you can use different keys for different servers:
ssh -i ~/secretfiles/mykey_at_hostname hostname
Of course the same applies for scp and sftp…
Remote command execution
Who says you even need a terminal?
ssh hostname df
If system command is added as parameter of the ssh connection command (in this example it’s df) after successful login it will be executed and logout happens as soon as it’s execution is finished. Useful for checking on some services; or in this case - file system capacity status.
Port forwarding (poor man’s VPN)
Forwarding a port thru remote system - weather you need it to secure traffic over not so secure link or connect to the service which is behind the firewall - this one is all time favorite ssh trick
So, presumably you need to check on some webpage which is available only inside LAN of your network from internet and you have only ssh access to server there. Imposible? Not with ssh:
ssh -L 8080:webserver:80 hostname
where 8080 is port on your client ssh computer, webserver is LAN address of the webserver in LAN and 80 is webservers http port
Now type in http://localhost:8080 in your browser and work like you’re there… As you can see -L is a very powerful option and it does forwards one port from some host (ports for localhost and remote hosts port can be set up as needed) to your local computer.
Additional use of this is anonymous surfing (or some other form of activity) - ports can be forwarded from whichever hosts your ssh server has connectivity to and port forwarding has a very interesting feature: all traffic made to that remote host seems like it originates only from ssh server and without any trace of your local computers address.
Reverse (remote) port forwarding
Forwarding a port on a local system to be available on remote system
Similar to port forwarding, but of reverse nature like it’s name says - expose your local network hosts to anybody who has access to remote servers forwarded port. Use with caution - you never know who’s listening on the other end…
ssh -R 8080:webserver:80 hostname
where 8080 is port on remote ssh server, webserver is LAN address of the webserver in LAN and 80 is webservers http port
Anyone who can access remote ssh servers 8080 port can now browse webserver in your LAN (do you really want this?). Also, with this your computer works as anonymous proxy for chosen webserver (or any other protocol depending on ports used).
SOCKS Proxy
Believe it or not, SSH can serve as SOCKS proxy
ssh -D 12345 hostname
where 12345 is port on your local computer
Huh? Is it this easy? Yep - dynamic port forwarding as it is usually called does just this - makes a SOCKS v4/5 out of your computer and all you need to do is point your SOCKS-aware applications to the chosen port…
Punching holes in HTTPS proxy
OK, now this isn’t exactly a ssh-only feature (proxytunnel does most of the work here) but might be the only way to make your way thru the corporate restrictive web policies
