Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
SSHNotes
Edit
PageHistory
Diff
Info
LikePages
You are viewing an old revision of this page.
View the current version
.
See the [SSHErrors] page for resolving [SSH] related errors, and [SSHKeys] for information about setting up SSH key logins. !!!Config file aliases To ease your life, you can put all settings for a particular host in your __.ssh/config__. Say you would normally use the CommandLine ssh me@some.long.winded.fqdn.name.here.com to connect to somewhere. That's a lot to type. If you spell this out in configuration directives (see ssh_config(5)) it looks like this: Host foo Protocol 2 User me !HostName some.long.winded.fqdn.name.here.com From then on it's enough to simply say ssh foo Much better! You can also use wildcards for the hostname. A __Host *__ section defines directives that should be in effect for ''all'' [SSH] connections. !!!SSH Control Character ~ is the control character for ssh. Once you get into control mode there are a few things you can do - exit the current ssh session ( use ~. ) or background it ( ~^Z). ~? will give you a list of control sequences. This is discussed in ssh(1), of course. ~ is only special if it is pressed after a newline, otherwise a literal "~" character is sent (as it is if the following character is not one of the meaningful ssh commands). ~~ after a newline will also force a "~" char to be sent. If you are ssh'd from another ssh connection, you can do ~~^Z after a newline to make the remote ssh client get the background command, instead of your local client. !!!Virtual Terminal Ever tried to do ssh user@host screen -rx to reconnect to a screen? [Screen] will tell you it can't do that: ''Must be connected to a terminal''. Well, you can provide one easily: ssh -t user@host screen -rx Combined with [SSHKeys] it's excellent for reconnecting those [IRC] sessions with a single key/buttonpress. Unfortunately this option cannot be set from your ssh_config(5). !!!Connecting to two hosts behind one IP address You may connect directly to a number of machines NATted behind a single ip address using different ports. After the first host has been connected to, subsequent hosts will give a warning: Warning: the RSA host key for 'hostname' differs from the key for the IP address '1.1.1.1' Offending key for IP in /home/alastair/.ssh/known_hosts:2 Matching host key in /home/alastair/.ssh/known_hosts:7 Are you sure you want to continue connecting (yes/no)? Some ways to work around this: * Add ''!StrictHostKeyChecking no'' to each stanza in your ssh_config(5). This will still produce a warning, but will connect without any input needed * Add ''!UserKnownHostsFile ~/.ssh/known_hosts_foo'' to each ssh_config(5) stanza. !!!Port Forwarding [SSH] can forward ports across its encrypted tunnel. Using the following command, ssh -L 5000:very.remote:80 user@host.remote will have [SSH] listening on port 5000 on __localhost__. By connecting to this port you get a connection tunneled to __host.remote__, which will then establish a connection to port 80 on __very.remote__. This is very helpful if __very.remote__ lives behind a FireWall that blocks direct traffic, but will let you [SSH] to __host.remote__. By the same token, doing ssh -L 5000:localhost:80 user@host.remote you can tunnel a connection from port 5000 on your own host to port 80 on __host.remote__, which for the purposes of the webserver on the other end will appear to come from that __localhost__. If you don't need the shell, and just want the tunnel, you can add options __-f__ (go to background before command execution) and __-N__ (don't execute remote command). ssh -f -N -L 5000:localhost:80 user@host.remote [SSH] will then effectively run as a daemon. If you add __-g__, your local end of the [SSH] tunnel will accept connections from anyone, not just __localhost__. Say there are two machines called __host1.lan__ and __host2.lan__ on a [LAN]. By doing host1$ ssh -f -g -N -L 5000:localhost:80 user@host.remote host2$ lynx host1:5000 you have opened a connection from __host2.lan__ to the webserver on __host.remote__ without, in fact, connecting from __host2.lan__ to __host.remote__. Imagine the fun you can have with multiple [SSH] forwards! If you've set up your __.ssh/config__ as in the tip above, you can spare yourself typing the same parameters to set up tunnels in the same manner. __-L 5000:localhost:110__ translates to __!LocalForward 5000 localhost:110__. If you'd like to have __-g__ taken care of as well, add __!GatewayPorts__. __-f__ and __-N__ don't have corresponding options, but those wouldn't be very useful anyway. !!!X Connection Forwarding If you use the __-X__ option to ssh, you will enable X-connection forwarding. This is essentially a reverse port forward with a few added effects: for instance it will set your __DISPLAY__ variable on the remote end to something like __localhost:15__. Most of the time you won't need to mess with xhost(1) or xauth(1) either. Be aware that you will need the X libraries and utilites even if you're forwarding clients from a headless server. To fix yourself up on Debian machines, just apt-get install xbase-clients For those of us not running debian, you need to install whatever packages you have that give you the xhost(1) binary. In FreeBSD, it is named ''xorg-clients''. If you've set up your __.ssh/config__ as discussed above, you can spare yourself typing __-X__ every time using the directive ForwardX11. The [SSH] daemon on the remote machine must be configured to allow X11 forwarding -- the [Debian] [Woody] default configuration for example disables it. If it is disabled, you have to edit __/etc/ssh/sshd_config__ and then restart sshd(8). If you are running OpenSSH 3.8 or newer, some X applications may give you one of these errors: * !BadWindow (invalid Window parameter) * !BadAccess (attempt to access private resource denied) * X Error of failed request: !BadAtom (invalid Atom parameter) * Major opcode of failed request: 20 (X_!GetProperty) You will also find by invoking xdpyinfo(1) from the remote machine that they can only use a fraction of the extensions your X server offers. This is because the new default is to use untrusted X11 cookies for forwarding connections. You need to invoke ssh(1) with the __-Y__ option for [X11] forwarding, or add __ForwardX11Trusted yes__ to your configuration. Since one of the affected extensions is XRENDER, which greatly reduces the bandwidth required to draw AntiAliasedFonts and accelerates their rendering, it is unclear why anyone would ever use untrusted cookies. !!! STDIN Forwarding [SSH] forwards its standard input to be the standard input of a command executed on the remote machine. You can use this to do some pretty cool things like stream tar(1) archives across a network to eliminate any overhead with copying many small files: tar c sourcedir | ssh user@host tar xf - There are many other neat tricks that can be perfomed using this technique as well. The feature was inherited from rsh(1). If you are having problems with corruption when piping data via [SSH], you may find a solution on the [SSHErrors] page. In a rudimentary test involving about 200MB of variously sized files, the tar stream finished in about 4:00 minutes, where __scp -R__ took about 5:40 minutes. (That is even though it doesn't seem to establish a new connection for each file as ftp(1) does, nor have much overhead at all. So tar(1) could just be better at doing this than scp(1).) !!! Executing the same command on multiple machines Check out the distributed shell dsh(1). It lets you [SSH] to all your drones and execute the same series of commands, watching the output as you go. !!! [SSH]ing to not directly reachable hosts Suppose you have a shell account on __safe__, a machine on a [NAT]ted [LAN] without a public [IP] address assigned to it. Let's also suppose you can [SSH] to the publicly visible gateway router of that [LAN], __door__, and that on this machine a copy of nc(1) (aka netcat) is installed. With the aid of a config file alias for the [NAT]ted host and a config directive called __!ProxyCommand__, you can easily set yourself up such that [SSH]ing to __safe__ is no different from [SSH]ing to any publicly visible box: # this section isn't necessary of course Host door Protocol 2 User me !HostName homelan.at.dsl.my.isp.com # but this one is Host safe Protocol 2 User me !HostName 192.168.0.42 __!ProxyCommand ssh door nc -q 0 safe 22__ If you have the sshd(8) running on a different port than 22 (the standard [SSH] port) on __safe__, you need to change the argument to nc(1) accordingly, of course. Note the "-q 0" argument to netcat - without this, you will likely end up with stale netcat processes on the intermediary machine. Now, you can just $ ssh safe and [SSH] will transparently invoke another copy of itself that connects to __door__ and uses the netcat installed there to establish a connection from __door__ to __safe__. netcat's STDIN/STDOUT is tunnelled back to your via your slave [SSH] connection to __door__, across which the primary [SSH] process can then communicate with the sshd(8) on __safe__. Note that since the master [SSH] process is only communicating with the proxy process, it has no way of knowing the [IP] address of the remote host it is talking to. Since its address is needed to verify its host key's authenticity, it is advisable to use a __!HostName__ directive for the proxied host to specify its address. Since the address is not otherwise used, you ''can'' leave it out or even enter something fake - you'll just get a complaint from [SSH]. Finally, remember that __ssh foo nc bar 1234__ is just one example of what the proxy command could be. The only requirement is that it forward the traffic, whether that be a TCP connection or even anything else, to and from [SSH] over STDIN/STDOUT. You might even use something like !ProxyCommand pppd nodetach call __foo__ and have the remote getty(8) launch __[sshd|sshd(8)] -i__ on the incoming line, thus logging into a machine that's not even connected to the InterNet. The possibilities are endless. In the standard case of using a slave [SSH] connection to some gateway, nothing stops you from using a __!ProxyCommand__ in the alias configured for the gateway - so you can build an entire cascade of [SSH] tunneled connection from one gateway to the next. Of course eventually the onion of tunnels wrapped around the connection will push the latency up and the throughput down to unworkable levels. !!! Improving loss of connection detection / coping with flaky net links Configure your [SSH] client to keep making sure it can still talk to the remote host if it hasn't received any data in a while. This is done by setting __!ServerAliveInterval__ in your __.ssh/config__ to how many seconds of silence the client should wait. The __!ServerAliveCountMax__ directive defines how many attempts to get a reaction from the remote host may go unanswered before the [SSH] clients decides the connection has been lost. If you specify 5 seconds and 3 tries, a dead connection will be detected in 15 seconds. The default values are 0 seconds, which means never, and 3 tries. Pick these according to bandwidth, ping time to the server, and packet loss on your link. !!! Speeding up transfer rates [SSH] can use [gzip] compression on any connection, and will use a modest level by default. Compression is a great idea if you are forwarding X sessions on a dial-up or slow network. It can be turned on using the __-C__ switch, or using __Compression yes__ in your __.ssh/config__. Changing your encryption cipher from the common default of DES or 3DES can speed things up as well. Blowfish and AES are faster, and new versions of [OpenSSH] default to Blowfish. The CommandLine switch to change the cipher is __-c blowfish__. For __.ssh/config__ it depends on whether you are connecting with SSH1 or SSH2. Cipher blowfish # SSH1 Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # SSH2 !!! SSH for apt-get(8) If you try and run apt-get without a terminal or the right paths, it won't be able to find dpkg or display debconf information. This is the way I've found (useful for remote upgrading of machines - note, only do this off security or your own repository...) ssh root@[[hostname] -t "su - -c 'apt-get update && apt-get upgrade'" ---- Part of CategorySecurity and CategoryNetworking
11 pages link to
SSHNotes
:
TunnelNotes
PortForwarding
XNotes
CopyingData
X11
SSHKeys
UserSubmittedNotes
SCP
SSH
XFree86Notes
AristotlePagaltzis