SSH tricks
[ Monday, 3 July 2006, michuk ]
SSH (secure shell) is a program enabling secure access to remote filesystems. Not everyone is aware of other powerful SSH capabilities, such as passwordless login, automatic execution of commands on a remote system or even mounting a remote folder using SSH! In this article we’ll cover these features and much more.
Author: Borys Musielak
SSH works in a client-server mode. It means that there must be an SSH daemon running on the server we want to connect to from our workstation. The SSH server is usually installed by default in modern Linux distributions. The server is started with a command like /etc/init.d/ssh start. It uses the communication port 22 by default, so if we have an active firewall, the port needs to be opened. After installing and starting the SSH server, we should be able to access it remotely. A simple command to log in as user1 to the remote_server (identified by a domain name or an IP address) looks like this:
ssh user1@remote_serverAfter entering the password to access the remote machine, a changed command prompt should appear, looking similar to user1@remote_server:~$. If this is the case, it means that the login was successful and we’re working in a remote server environment now. Any command we run from this point on, will be executed on the remote server, with the rights of the user we logged in with.
SCP - secure file copying
SCP is an integral part of the OpenSSH package. It is a simple command allowing to copy any file or folder to or from a remote machine using the SSH protocol. The SSH+SCP duo is a great replacement of the non-secure FTP protocol which is widely used by the Internet users nowadays. Not everyone is aware of the fact though, that all the passwords sent while using the FTP protocol are transferred over the network in a plain text format (making it dead easy for crackers to take over) - SCP is a much more reliable alternative. The simplest usage of SCP looks like on the following example:
scp file.txt user1@remote_server:~/This will copy the local file.txt to the remote server and put it in the home folder of user1. Instead of ~/, a different path can be supplied, i.e. /tmp, /home/public, and any other path we have write access to.
In order to copy a file from a remote server to the local computer, we can use another SCP syntax:
scp user1@remote_server:~/file.txt .This will copy a file file.txt located in a home folder of user user1 of a remote system to the local folder (the one we are currently in).
Other interesting SCP options:
-r- to copy folders recursively (including subfolders),-P port- to use a non-standard port (the default is 22) - of course this option should be used if the server listens on a non-standard port. The option can be helpful when connecting from a firewall-protected network. Setting the SSH server to listen on 443 port (used for secure HTTP connections) is the best way to by-pass the administrator’s restrictions.
GUIs for SCP
If we do not like the console and we prefer GUI (graphical user interface), we can use a graphical (or pseudo-graphical) SCP client. Midnight Commander is one of the programs that provides an SCP client (option shell link). Nautilus and Konqueror are the SCP-capable file managers as well. Entering ssh://user1@remote_server:~/ in the URI field results in a secure shell connection to the remote system. The files can be then copied just as they were available locally.
In the MS Windows environment, we have a great app called WinSCP. The interface of this program looks very much like Total Commander. By the way, there is a plug-in allowing for SCP connections from TC as well.
SSH without passwords - generating keys
Entering passwords upon every SSH connection can be annoying. On the other hand, unprotected remote connection is a huge security risk. The solution to this problem is authorization using the private-public key-pair.
The pair of keys is usually generated using the ssh-keygen command. Below, there is a sample effect of such key generation. RSA or DSA keys can be used.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key
(/home/user1/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/home/user1/.ssh/id_rsa.
Your public key has been saved in
/home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
When the program asks for the key password, we should just press ENTER - this way, a passwordless key will be created. Remember that this is always a security hole to have a passwordless key (in simple words, doing that downgrades your remote system security to the security of your local system) so do it on your own risk. As the ssh-keygen finishes its work, you can see that two keys have been generated. The private key landed in /home/user1/.ssh/id_rsa and we should never make this public. The second public key appeared in /home/user1/.ssh/id_rsa.pub and this is the one we can show the entire world.
Now, if we want to access a remote system from our local computer without passwords (only using the keys), we have to add the information about our public key to the authorized_keys file located in ~/.ssh folder on the remote system. This can be done using the following commands:
Pic 1. Passwordless SSH login
$ scp /home/user1/.ssh/id_rsa.pub \\
user1@remote_server:~/
$ ssh user1@remote_server
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
The third command will be obviously executed on a remote server. After this operation, all actions performed on the remote server with SSH will not need any password whatsoever. This will certainly make our work easier.
Notice that if you need passwordless access from the remote server to the local one, the similar procedure has to be performed from the remote server. Authorization using keys is a one-way process. The private key can verify the public one, not vice-versa.
Executing commands on a remote system
Well, now when we can already log into remote OS without the password, why wouldn’t we want to execute some command remotely? There can be multiple useful appliances of this, especially when we have to execute some command on a daily basis, and it could not be automated before, because of the need to enter the password manually (or enter it as plain text which is not very secure).
One interesting case is a “remote alert”. Let’s say that we have some crucial process running on the remote system, i.e. a website running on Apache server. We want be be warned when the system gets out of resources (i.e. the disk space is getting short or the system load is too high). We could obviously send an e-mail in such cases. But additionally, we can execute a remote command which plays a warning sound on our local OS! The code for such event would look something like that:
ssh user1@local_server 'play \\
/usr/share/sounds/gaim/arrive.wav'This command, executed in a script from the remote server would cause a passwordless login of user1 to the local_server (the one we’re usually working on) and play a wave file with the play command (which is usually available in Linux). The actual case in which we execute this remote command should obviously be specified in a script, but we’re not going to provide a scripting course here, but a way to execute remote commands with passwordless SSH :).
X11 forwarding - running graphical apps remotely
One of the least known functions of SSH is X protocol forwarding. This enables us to run almost every X application remotely! It’s enough to connect to the remote server using the -X option:
ssh -X user1@remote_serwerand the display of every X application executed from now on will be forwarded to our local X server. We can configure the X11 Forwarding permanently by editing the /etc/ssh/ssh_config file (relevant option is ForwardX11 yes). Of course for the option to work, the remote SSH server needs to support X11 forwarding as well. The /etc/ssh/sshd_config file is responsible for that. This option is however configured by default in most of the Linux distros.
If we just need to execute one single command, we can use the syntax we learned before:
ssh -X user1@remote_serwer 'psi'- this will execute PSI instant messenger on the remote server, passing the display to the local screen.
Of course the speed of applications executed remotely depends mostly on the network connection speed. It works almost flawlessly in local networks (even things like forwarding Totem playing a DivX movie). In case of Internet connection, a DSL seems reasonable to get apps like Skype or Thunderbird work quite well with a remote call.
Notice that it’s also possible to connect to the remote server without the X11 forwarding enabled, export the DISPLAY variable to point to the local machine and then run the X application. This way, the application would be executed with a remote display, using the generic X server functionality. SSH security would not be applied in such case since this kind of configuration has nothing to do with SSH. Depending on the configuration of the local X server, it may be that the authorization of the remote X applications needs to be turned on in such case. This is usually done by the command xhost. For example, xhost + hostname accepts all the remote applications from the specified hostname for a while. If we plan to use this option regularly, a more secure X server configuration is recommended.
SSHFS - mounting a remote folder
Working on a file located on some remote server via SSH can be quite annoying especially when we need often copy different files in both directions. Using a the fish:// protocol in Midnight Commander or Konqueror is a partly solution - fish tends to be much slower than pure SSH and it often slows down even more while copying files. The ideal solution would be a possibility to mount a remote resource available through SSH only. The good news is that… this option exists for a while already, thanks to sshfs and the fuse project.
Fuse is a kernel module (recently it has been adopted in the official 2.6 series) allowing for mounting different filesystems by an unprivileged user. SSHFS is a program created by the author of fuse himself which enables to mount remote folders/filesystems using SSH. The idea is very simple - a remote SSH folder is mounted as a local folder in the filesystem. Since then, almost all operations on this folder work exactly as if this was a normal local folder. The difference is that the files are silently transferred though SSH in the background.
Installing fuse and sshfs in Ubuntu is as easy as entering (as root):
# apt-get install sshfsThe only remaining action is adding the user that we want to give the permission to mount SSH folders to the fuse group (using a command like usermod -G -a fuse user1 or manually editing the /etc/group file). Eventually, the fuse module needs to be loaded:
# modprobe fuseAnd then, after logging in, we can try to mount a remote folder using sshfs:
mkdir ~/remote_folder
sshfs user1@remote_server:/tmp ~/remote_folder
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SCP. Same concerns direct file editing, creating or removing.
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:
fusermount -u ~/remote_folderIf we work on this folder on a daily basis, it is wise to add it to the /etc/fstab table. This way is can be automatically mounted upon system boot or mounted manually (if noauto option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:
sshfs#user1@remote_server:/tmp \\
/home/user1/remote_folder/ fuse defaults,auto 0 0
If we want to use fuse and sshfs regularly, we need to edit the /etc/modules file adding the fuse entry. In other case we would have to load the module manually each time we want to use it.
Summary
As you can see, SSH is a powerful remote access tool. If we need to work with remote UNIX filesystems often, it’s really worth to learn a few powerful features of SSH and use them in practice. SSH can really make your daily work much more effective and pleasant at the same time. In the following article (to be published later this month) we’re going to cover another great feature of SSH: making different kinds of tunnels with port forwarding using transparent socks and a corkscrew
Propagate this post
Subscribe to RSS feed for this article! | Trackback URI
Hey, nice job & in plain english! only thing that might have been cool was some more on port forwarding.
You need ssh -Y not ssh -X for X forwarding.
-X just breaks things in obscure ways.
Well written and concise article. One thing though regarding the use of ‘xhost +’ - without any arguments this enables X access from anywhere. Better to use ‘xhost + hostname’ to only enable access to the X server from one client.
Another great way of using ssh is to use standard UNIX pipes to send content from one server to another. I once needed to tar some stuff on one server with very little disk space and then send the content to another server. This is how I did that
tar cvf - . | gzip -2 | ssh -l username server_name “cd /tmp; cat > temp.tar.gz”
Now I end up with a /tmp/temp.tar.gz on server_name
[…] read more | digg story […]
Small typo - most ssh daemons are named sshd :p
ckin2001: not in Debian/Ubuntu
Ungh. ssh-keygen with no password is asking for trouble. Never do this at work. A more secure way to use passwordless logins is through the ssh-agent. (use “eval `ssh-agent`; ssh-add” ) Keychain makes this somewhat painless and can be stashed in your .xinitrc. Also xhost + disables access control on your local X server, allowing anyone with inbound access to tcp/6000 to snoop your keystrokes. Also very bad form - never do this at work.
[…] read more | digg story […]
Very good article. I’m going only to suggest the use of a windows X server like Xmanager (eval) so you could remote execute apps on a windows system.
Then on the remote side (in a ssh session) you would do something like:
export DISPLAY=your.windows.ip.address:0.0
and just run (almost) any graphical application:
xterm
Other thing you haven’t mentioned is the port forwarding.
ssh -l username@some.remote.ip.address -L 10000:local.ip.remote.lan:3389
This would connect to some.remote.ip.address that would create a tunnel on Terminal services port (3389) between your localhost and a machine (local.ip.remote.lan) behind some.remote.ip.address.
Then you would just connect with a terminal services client to “localhost:10000″.
Cheers
To send the public key to the remote machine, you can use the ssh-copy-id command which is cleaner than scp + cat.
I don’t understand why one would need to use the xhost command as the X client appears to be on the local machine from the X server’s point of view (because the X client is tunneled through the ssh client).
Nice summary though.
[…] Excellent overview of SSH (secure shell) and SCP (secure copy) here — even if you’re a seasoned terminal jock, I suspect you’d pick up a tip or two here. The one thing I’d add to this article is that in addition to Midnight Commander and WinSCP, Cyberduck is quite an excellent SCP client as well. […]
[…] read more | digg story […]
you really missed out port forwarding, especially dynamic
need a socks proxy? ssh yourhost -D1080 and you have a socks5 on localhost:1080
you really missed out port forwarding
I missed it or maybe it’s you who missed something:
“In the following article (to be published later this month) we’re going to cover another great feature of SSH: making different kinds of tunnels with port forwarding using transparent socks and a corkscrew”
[…] SSH (secure shell) is a program enabling secure access to remote filesystems. Not everyone is aware of other powerful SSH capabilities, such as passwordless login, automatic execution of commands on a remote system or even mounting a remote folder using SSH! In this article we’ll cover these features and much more. LINK: jakilinux.org - english version » SSH tricks [link] […]
Another typo, the “ssh-keygen” program prompts for passphrase which you refer to as password in the text.
Nice summary though.
Very nice list of “tricks”. I don’t know if it’s considered a “trick” but SFTP is pretty nice too. Basically FTP but over an SSH connection. Windows has a great open source GUI SFTP client in FileZilla.
X11 over SSH is very useful. It makes it easy to get remote X11 apps working without dealing with trying to configure the firewalls on both ends correctly.
[…] read more | digg story Search […]
Thanks for these tips
Ah I love that secure file copying method. Keep up the great work
In one of the comments above, dissaffected said:
“Ungh. ssh-keygen with no password is asking for trouble. ever do this at work.”
That is simply not true. Passwordless private keys are just as secure as keys with passwords (and maybe more so).
The difference is that if someone gains access to your passwordless private key, they have access to anything that key can access. It’s just like a super-secure house key. Virtually impossible to ‘pick’, but easy to use if they have access to the key.
This means that your passwordless private key (id_rsa or id_dsa) should reside on your USB key, and stay with you at all times. It should never be left on a computer that has public access. It should be treated like a safety deposit box key.
Some security analysts are coming to the conclusion that passwordless private keys may be MORE secure than passworded keys. The primary method of gaining access to a system is by password guessing, password observing or social engineering. Most users are not particularly effective at creating passwords (easily guessed), or protecting password entry (password observing). But, most adults have learned to physically protect their car keys, house keys and office ID badges. It’s a concept that is intrinsic. By installing passwordless keys on a token, you allow the user to protect the security of that token, using means that they already understand well.
Now, for the record, if a proffessional gets access to your password protected private key, it’s a fairly simple matter of computational brute force to find a matching password. So, even password protected private keys should be protected on a token.
Uh. No. A passwordless RSA/DSA key is by design less secure than one with a password. You still protect the physical security of your private key, but you have an added factor involved.
Your comment about if a “proffessional” getting access to your private key is mistaken as well. A sufficiently long passphrase is statistically highly improbably to be broken until better processing power that can brute through more easily comes along. Even if they have the computational power (say, a distributed network of desktops amongst the entire planet) to do so, that’s not a ‘fairly simple matter’.
So to summarize, use a private key with a significant length, like 2048 bits, a password of at least 15 characters containing both cases of letters, numbers, and non-alphanumeric characters with a minimum of dictionary-searchable phrases, and protect the physical security of your private key using aforementioned methods, such as USB keys attached to your person. Go a few further and research those nifty RSA keychains.
Don’t just assume you know what security is and how to be secure. Actually read up on it instead of taking comments on blogs for granted.
“Now, for the record, if a proffessional gets access to your password protected private key, it’s a fairly simple matter of computational brute force to find a matching password. So, even password protected private keys should be protected on a token.”
That’s so not true. First of all it’s passphrase and not password (http://en.wikipedia.org/wiki/Passphrase). And private key protected by strong passphrase will always be better approach than just private key without passphrase.
[…] SSH Tricks […]
[…] jakilinux.org - english version » SSH tricks (tags: ssh linux tutorial tips security utilities networking) […]
[…] http://en.jakilinux.org/apps/ssh-tricks/ […]
thedave, what you say does not make sense!
If a person is stupid enough to have an easy to break passphrase, I agree it doesn’t help much, but I for sure take my ssh-keys very seriously and have long (at least 16 characters) difficult (doesn’t make sense for others, looks like random characters) passphrase. Together with ssh-agent I get the same benefits as everybody else. I only use passphrase-less keys in scripts, and then I make a separate key and puts restrictions on the public key on which commands I can execute with it and from where (ip) I can connect using it. I know this makes it more secure, and brute forcing my key will take *a long time*, and within then I hopefully have noticed that I’ve been hacked and remove the public keys from where they are. You say “Passwordless private keys are just as secure as keys with passwords (and maybe more so).”, but then you assume the user is a novice - which only makes me believe /you/ are a novice. If used correct, using passphrases makes it /a lot/ more secure than without. I frankly don’t trust all the administrators and other privileged users on the servers I use, and they have a lot easier task to retrieve my key-file than using it - which contains the amount of damage they can do.
To a different point; When using sftp I believe only the authentication is secure, and afterwards all the files are transferred unencrypted. Using scp (and ssh) all of the transaction is encrypted. What you choose to use should depend on the files you wish to transfer, time (scp may use longer time due to the encryption), and if you have the oportunity to use keys or not.
Nice Windows SSH/SFTP/SCP package is PuTTY:
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Nice article. People should get rid of telnet/ftp forever and use SSH/SFTP as a standart.
Nice article bud.
glommy: FTP will be around for a while yet, it’s still one of the more dominant protocols.
[…] The article describes in a human language some of the powerful, yet very useful (even for total newbies) capabilities of OpenSSH, such as passwordless login, automatic execution of commands on a remote system or even mounting a remote folder using SSH.read more | digg story […]
Good job!
Very informative and well written.
This is the first time a read about X forwarding using ssh.
Thanx
Nice article. If you are in charge of security for the SSH server I highly recommend to block brute force attacks with the DenyHosts script. Details at http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm
[…] SSH is a program enabling secure access to remote filesystems. Not everyone is aware of other powerful SSH capabilities, such as passwordless login, automatic execution of commands on a remote system or even mounting a remote folder using SSH! In this article we’ll cover these features and much more. […]
ssh -X doesn’t break things, it just FINDS BROKEN THINGS, such as the myriad of Linux X11 software that ignores the X11 Security extension controls.
When you use ssh -Y, you are essentially giving the remote computer unfettered access to your local display. Which, in the context of an article that recommends allowing remote machines to login to the user’s local station with passwordless keys, isn’t that big of a deal.
I know this makes it more secure, and brute forcing my key will take *a long time*, and within then I hopefully have noticed that I’ve been hacked and remove the public keys from where they are.
To claim passphrase-less public key authentication is _more_ secure than the same with a passphrase is a bit silly. But the point shouldn’t be lost on you: once the cracker has physical access to that key, brute forcing the passphrase could be trivial enough.
To a different point; When using sftp I believe only the authentication is secure, and afterwards all the files are transferred unencrypted.
Not true. You may be thinking of FTPS (FTP over SSL/TLS), which allows you to encrypt authentication but not file transfers if you choose. SFTP (SSH File Transfer Protocol) has nothing to do with FTP - it just behaves a bit like it. It’s really a subsystem of the OpenSSH software. File transfers under SFTP occur over an encrypted connection.
One of the only substantial advantages in using SFTP instead of SCP is that with SFTP you can list/traverse directories and delete remote files.
[…] read more | digg story […]
I always remember this trick to copy my public key…
localhost % cat ~/.ssh/id_rsa.pub | ssh remotehost " cat - >> ~/.ssh/authorized_keys; chmod go-wrx ~/.ssh/authorized_keys"The other thing to remember is that if you create an authorized_keys file, it must not be readable or writable by group or other (go-wrx). Ssh will not recognize a key from a world readable authorized_keys file by default. Also, the .ssh directory must only be readable by the user, but this is usually true by default on all Unix systems EXCEPT cygwin.
this site is awesome lots of info… kudos to the owner..
[…] jakilinux.org - english version » SSH tricks SSH (secure shell) is a program enabling secure access to remote filesystems. Not everyone is aware of other powerful SSH capabilities, such as passwordless login, automatic execution of commands on a remote system or even mounting a remote folder using S (tags: opensource tools reference) […]
another nice way to get an X session remotely is
to use NXclient and FreeNX.
uses SSH to do the work.
Hey michuk - great article - keep up the good work.
I must say that I think the people who knock the password-less login are a bit anal about security. I agree with michuk that’s it’s fine to have no passphrase - security is a balancing act between security and convenience, and that’s what we use on our office ssh server. You can login, but ONLY with a private key. We just get annoyed at the constant stream of brute force ssh login attempts from compromised hosts. If I was working for a government security agency I would want more security, but for us it’s just fine.
[…] The article describes in a human language some of the powerful, yet very useful (even for total newbies) capabilities of OpenSSH, such as passwordless login, automatic execution of commands on a remote system or even mounting a remote folder using SSH.read more | digg story […]
Port forwarding is great, I use it all the time…for TCP. Anyone ever come up with a step by step method for forcing UDP traffic over SSH???
I unsuccessfully followed this tutorial (though due to my own error I am sure):
http://zarb.org/~gc/html/udp-in-ssh-tunneling.html
Thanks!
[…] I found a nice page with some SSH Tips and Tricks Check it out. […]
I’m surprised no one’s mentioned this yet — using iptables, rate limit incoming connections to your port 22 to 3 attempts every 5 minutes:
# RATE LIMIT CONNECTION ATTEMPTS to 3 per 5 minutes per ip
iptables -A INPUT -p tcp –dport 22 -i eth1 -m state –state NEW -m recent –set
iptables -A INPUT -p tcp –dport 22 -i eth1 -m state –state NEW -m recent –update –seconds 300 –hitcount 3 -j DROP