commandlinefu.com is the place to record those command-line gems that you return to again and again.
Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.
You can sign-in using OpenID credentials, or register a traditional username and password.
First-time OpenID users will be automatically assigned a username which can be changed after signing in.
Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.
Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):
Subscribe to the feed for:
Wow, didn't really expect you to read this far down. The latest iteration of the site is in open beta. It's a gentle open beta-- not in prime-time just yet. It's being hosted over at UpGuard (link) and you are more than welcome to give it a shot. Couple things:
Requires software found at: http://lpccomp.bc.ca/remserial/
Remote [A] (with physical serial port connected to device)
./remserial -d -p 23000 -s "115200 raw" /dev/ttyS0 &
Local [B] (running the program that needs to connect to serial device)
Create a SSH tunnel to the remote server:
ssh -N -L 23000:localhost:23000 user@hostwithphysicalserialport
Use the locally tunnelled port to connect the local virtual serial port to the remote real physical port:
./remserial -d -r localhost -p 23000 -l /dev/remser1 /dev/ptmx &
Example: Running minicom on machine B using serial /dev/remser1 will actually connect you to whatever device is plugged into machine A's serial port /dev/ttyS0.
Super fast way to ftp/telnet/netcat/ssh/ping your loopback address for testing. The default route 0.0.0.0 is simply reduced to 0.
Cleaned up and silent with &>/dev/null at the end.
Execute commands serially on a list of hosts. Each ssh connection is made in the background so that if, after five seconds, it hasn't closed, it will be killed and the script will go on to the next system.
Maybe there's an easier way to set a timeout in the ssh options...
Run this within a steady screen session.
You can get the approximate time when the remote server went down or other abnormal behavior.
This will check if a user is logged in using ssh and will log out the user automatically after the specified time in seconds without data retrieval on the server side.
Will work with bash and zsh so put it into your sourced shell file on the server side.
Be aware that users can change this themselves as it's just a envoronment variable.
This command adds your pem key to SSH so that you no longer have to manually specify it when connecting to EC2 instances.
# you can do this:
# instead of this:
ssh -i ~/.ssh/KEY_PAIR_NAME.pem ec2-instance.amazonaws.com
ssh compresion -C option ...
on slow connection VNC performs better but in local LAN native secure X protocol is an option
if you use tmux and wish to automatically reattach you previously detached sessions when logging in.
Example: remote install an application(wine).
sshpass -p 'mypssword' ssh -t email@example.com "echo 'mypassword' | sudo -S apt-get install wine"
Tested on Ubuntu.
Use as: $ s host1
Will ssh to remote host upon first invocation. Then use C-a d to detatch. Running "s host1" again will resume the shell session on the remote host. Only useful in LAN environment. You'd want to start the screen on the remote host over a WAN.
Adapted from Hack 34 in Linux Server Hacks 2nd Addition.
Really useful when out of space in your current machine.
You can ran this also with cat for example:
tar zcvf - /folder/ | ssh firstname.lastname@example.org "cat > /dest/folder/file.tar.gz"
Or even run other command's:
tcpdump | ssh email@example.com "cat > /tmp/tcpdump.log"
While logged into ssh, type ~s to see stats of ssh
Suspend ssh session
Sometimes it is necessary to view debug messages to troubleshoot any
SSH connection issues. pass -v (lowercase v) option to the ssh as shown
below to view the ssh debug messages.
. a Ruby SSH helper script
. reads a JSON config file to read host, FQDN, user, port, tunnel options
. changes OSX Terminal profiles based on host 'type'
put 'ash' ruby script in your PATH
modify and copy ashrc-dist to ~/.ashrc
configure OSX Terminal profiles, such as "webserver", "development", etc
run "ash myhostname" and away you go!
v.2 will re-attach to a 'screen' named in your ~/.ashrc
Play with the framerate option '-r' to scale back bandwidth usage.
The '-s' option is the captured screan area, not the rescaled size. If you want to rescale add a second '-s' option after '-i :0'. Rescaling smaller will also decrease bandwidth.
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.
Mac install ssh-copy-id
From there on out, you would upload keys to a server like this:
(make sure to double quote the full path to your key)
ssh-copy-id -i "/PATH/TO/YOUR/PRIVATE/KEY" username@server
or, if your SSH server uses a different port (often, they will require that the port be '2222' or some other nonsense:
(note the double quotes on *both* the "/path/to/key" and "user@server -pXXXX"):
ssh-copy-id -i "/PATH/TO/YOUR/PRIVATE/KEY" "username@server -pXXXX"
...where XXXX is the ssh port on that server
this command from the source server and this follow in the destination server:
ssh user@localhost -p 8888
commandline for mac os x
Works for multiple hosts (such as www.google.com) and/or wrong hosts.