This command will bypass checking the host key of the target server against the local known_hosts file. When you SSH to a server whose host key does not match the one stored in your local machine's known_hosts file, you'll get a error like " WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" that indicates a key mismatch. If you know the key has legitimately changed (like the server was reinstalled), a permanent solution is to remove the stored key for that server in known_hosts. However, there are some occasions where you may not want to make the permanent change. For example, you've done some port-forwarding trickery with ssh -R or ssh -L, and are doing ssh user@localhost to connect over the port-forwarding to some other machine (not actually your localhost). Since this is usually temporary, you probably don't want to change the known_hosts file. This command is useful for those situations. Credit: Command found at http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html. Further discussion of how it works is there also. Note this is a bit different than command #5307 - with that one you will still be prompted to store the unrecognized key, whereas this one won't prompt you for the key at all.

Useful if you have to tunnel ssh through a local port and it complains of the host key being different. Much easier than manually editing the file.

Thankfully, the ssh command allows you to specify multiple tunnels through the same server in one command. Remeber if you want a priviliged port on your machine, you must use root or sudo account. Show Sample Output

you may create an alias also, which I did ;-) alias sshu="ssh -o UserKnownHostsFile=/dev/null "

backup big mysql db to remote machine over ssh. "--skip-opt" option is needed when you can?t allocate full database in ram.

host B (you) redirects a modem port (62220) to his local ssh. host A is a remote machine (the ones that issues the ssh cmd). once connected port 5497 is in listening mode on host B. host B just do a ssh 127.0.0.1 -p 5497 -l user and reaches the remote host'ssh. This can be used also for vnc and so on.

Booting the VM headless via VBoxHeadless requires knowledge of the VM's network in order to connect. Using VBoxManage in this way and you can SSH to the VM without first looking up the current IP, which changes depending on how you have your VM configured. Show Sample Output

rsync from source to dest all between >30

Connect to a machine running ssh using mac address by using the "arp" command Show Sample Output

This command will dump a database on a remote stream to stdout, compress it, stream it to your local machine, decompress it and put it into a file called database.sql.You could even pipe it into mysql on your local machine to restore it immediately. I had to use this recently because the server I needed a backup from didn't have enough disk space.

Allows you to establish a tunnel (encapsulate packets) to your (Server B) remote server IP from your local host (Server A). On Server B you can then connect to port 2001 which will forward all packets (encapsulated) to port 22 on Server A. -- www.fir3net.com --

Here how to recover the remote backup over ssh Show Sample Output

First of all you need to run this command. X :12.0 vt12 2>&1 >/dev/null & This command will open a X session on 12th console. And it will show you blank screen. Now press Alt + Ctrl + F7. You will get your original screen. Now run given command "xterm -display :12.0 -e ssh -X user@remotesystem &". After this press Alt + Ctrl + F12. You will get a screen which will ask you for password for remote linux system. And after it you are done. You can open any window based application of remote system on your desktop. Press Alt + Ctrl + F7 for getting original screen.

until (ssh root@10.1.1.39 2> /dev/null); do date; sleep 15; done In this case will execute "date" then "sleep 15" until we are able to ssh into server, such as after a reboot Could also be like: until ( ping 10.1.1.39 1> /dev/null); do echo "server 10.1.1.39 is down"; sleep 15; done Show Sample Output

Notes: * Adjust the find command to your own filters. * The -P flag forces to keep absolute paths in the tarball, so that you can be sure that the exact same file hierarchy will be created on the second machine.

If you know the benefits of screen, then this might come in handy for you. Instead of ssh'ing into a machine and then running a screen command, this can all be done on one line instead. Just have the person on the machine your ssh'ing into run something like screen -S debug Then you would run ssh -t user@host screen -x debug and be attached to the same screen session.

I wanted to keep a backup of my company database server on my local homeserver. After I found maatkit to sync databases, everything except security seemed fine. SSH takes care of that part.

Instead of looking for the right ip address, just pick whatever address you like and set a static ip mapping.

Launch a gui app remotely. In this example smplayer is installed on the remote machine, and movie.avi is in the remote user's home dir. Note that stdout/stderr is still local, so you'll have feedback locally, add '&>/dev/null' to suppress. This is surprisingly not well known (compared to running an X app locally via ssh -X). (NB. if your distro requires ~/.Xauthority file present, then try -fX if you have problems) Resubmitted (and trimmed, thanks sitaram) due to ridiculous voting on previous submission. Fingers crossed, it gets a better rating this time.

It grabs all the database names granted for the $MYSQLUSER and gzip them to a remote host via SSH.

This will allow you to convert an audio file to wav format, and send it via ssh to a player on the other computer, which will open and play it there. Of course, substitute your information for the sound file and remote address You do not have to use paplay on the remote end, as it is a PulseAudio thing. If the remote end uses ALSA, you should use aplay instead. If it uses OSS, you should berate them about having a lousy sound system. Also, you're not limited to transmitting encoded as wav either, it's just that AFAIK, most systems don't come with mp3 codecs, but will play wav files fine. If you know SoX is installed on the remote end and has mp3 codecs, you can use the following instead: cat Klaxon.mp3 |ssh thelab@company.com play -t mp3 - this will transmit as mp3. Again, use your specific information. if you're not playing mp3s, use another type with the -t option

Run local scripts on remote server. "-T Disable pseudo-tty allocation"

The command uses ssh(1) to get to a remote host, uses tar(1) to archive a remote directory, prints the result to STDOUT, which is piped to gzip(1) to compress to a local file. In other words, we are archiving and compressing a remote directory to our local box.