Open-SSH is a utility for performing encrypted communication between computers. SSH was started in the Unix world as a way to secure basic telnet communication sessions, but has since been heavily developed, forked into Open-SSH, migrated to Linux and Macs, pretty much becoming the standard for intercomputer communication. Recently Microsoft announced that Open-SSH will now be built into Windows-10 natively. People originally thought of ssh merely as a communication tool to open a secure terminal session, but it is capable of much more than that. Encrypted file transfers, redirecting ports, redirecting standard I/O streams, and tunneling of assorted communication streams including graphics are just a few of the really useful tricks that ssh can do.
The following is a quick preliminary ssh howto … more coming. It is written from the viewpoint of a remote Mac LapTop communicating with campus linux servers, but it is directly applicable to linux clients as well.
Currently most windows systems still require a 3rd part app to support ssh client sessions, but here in the UW ESS dept, we try to include those apps as part of our basic standard builds. The techniques below generally work on such windows systems, but some translation may be required the particular app.
the above command uses the defaults ssh standard port 22.
Due to reasons of constant "dictionary-attacks" on standard ssh servers that are open to the world, the UW-ESS dept as a matter of policy limits the default ssh port (TCP-port-22) to "In-Building hardwire" use only. We do allow a non-standard ssh port to be open to the world, and for historical reasons we normally use port 7777 as our alt-ssh port. Altho this port is still discoverable by nmap scans, this technique generally stops 99+% of the attacks. One merely has to specify the alternate port as part of the ssh command.
ssh -p 7777 email@example.com
the above uses ESS alt-ssh standard port 7777.
ssh -p 7777 firstname.lastname@example.org "( uptime )"
ssh -p 7777 email@example.com "( ls -al )" | less
ssh -p 7777 -X firstname.lastname@example.org
the above uses ESS alt-ssh standard port 7777 and sets-up X tunneling for visualizing graphics locally from a remotely excuting program, if you are also running the "Quartz X11" graphics server.
ssh -p 7777 -D 4712 email@example.com
the above creates a SOCKS5 web-proxy service such that a browser on the local laptop can be set to use the web-proxy service found at 127.0.0.1:4712 will send all web activity thru the web-proxy and appear to be originating from neon.ess.washington.edu.
RDP is the windows Remote Desktop Protocol/Program and is an extremely useful method to use your work windows desktop PC remotely from at home. Note that for RDP to work, the windows PC must be POWERED-ON and NOT SLEEPING OR HIBERNATING, and enabled for RDP with security. Windows PC's should always be on a campus private network, with a known name or address. The addresses can be static but most typically are dynamic (DHCP). Macs and linux can connect to a windows RDP session but one must have the appropriate optional RDP client program installed. This is an example of gatewaying/redirecting a simple network protocol.
ssh -p 7777 -L 23389:172.28.21.174:3389 firstname.lastname@example.org
Then set the mac-rdp program to use 127.0.0.1:23389
In one terminal window, do
ssh -p 7777 -L 23022:172.28.23.198:22 email@example.com
you can then do separate multiple ssh sessions direct to the private machine 172.28.23.198 by using multiple aditional terminal windows on your laptop to the address 127.0.0.1:23022 … ie …
ssh -p 23022 firstname.lastname@example.org
yes the final session is doubly encrypted … but with modern powerful hardware, who cares …
better yet, you can transfer files directly to/from the private machine by using scp, sftp, or rsync
scp -P 23022 /path1/filename email@example.com:path2/
rsync -av -e "ssh -p 23022" /path1/filename* firstname.lastname@example.org:path2/
Note that when you start using 127.0.0.1 to represent multiple machines, you will start getting an error saying the .ssh/known_hosts has changed and evil things are about to happen. This is normal and to be expected when you are invoking 127.0.0.1 for multiple machines
an easy quick cheater fix is to delete all occurrences of 127.0.0.1 in the the known_hosts file
sed -i '/127.0.0.1/d' ~/.ssh/known_hosts
and then reissue the ssh command.
One way to avoid the known_hosts issue (I think) is to use 127.0.0.1, 127.0.0.2, 127.0.0.3, … for the assorted hosts, making it a point to always use the same on for the targeted host. the 127 range is a /8 and I believe the whole /8 range is considered the localhost (?????!!!)
Passwordless ssh is a wonderful thing and essential to scripting. It allows you to establish a one-way trust between machines.
First … on BOTH machines (Controller & controlled) (laptop is the "controller")(linux server is the "controlled") … make sure that you have done a simple short arbitrary outgoing ssh session … this will establish a ~/.ssh/ directory with right ownerships and permissions.
Then on the laptop, invoke
ssh-keygen -t rsa
and then hit return three times. then invoke
ls -al ~/.ssh/
You should see
Then invoke (modify this command as needed for real linuxserver)
scp ~/.ssh/id_rsa.pub user@linuxserver:.ssh/arbitraryname_id_rsa.pub
ssh user@linuxserver "( cat .ssh/arbitraryname_id_rsa.pub >> .ssh/authorized_keys )"
That should finish setting up passwordless from laptop to server.
To test it, now invoke
ssh user@linuxserver uptime