SSH basics


Debug with verbose output

$HOME/.ssh/config first and foremost - debug with -vvvv

  • actually do it before you need to so you can see how it works

From Wikipedia (paraphrased):

Secure Shell, or SSH, is a cryptographic (encrypted) network protocol for initiating text-based shell sessions[clarification needed] on remote machines in a secure way.

In 1995, Tatu Ylönen, a researcher at Helsinki University of Technology, Finland, designed the first version of the protocol (now called SSH-1) prompted by a password-sniffing attack at his university network.

OpenSSH and OSSH : In 1999, developers wanting a free software version to be available went back to the older 1.2.12 release of the original SSH program … Shortly thereafter, OpenBSD developers forked Grönvall’s code and did extensive work on it, creating OpenSSH, which shipped with the 2.6 release of OpenBSD.

SSH gave an option for the insecure nature of telnet, rsh, ftp, http. They are all inherently insecure.


  • ssh - secure login and controlled secure execution (feature: with X forwarding possibility)
  • scp - secure copy
  • sftp - secure ftp substitute - needs configure permission
  • sshfs - FUSE - filesystem user space - needs to be installed
  • rsync uses ssh
  • port forwarding - secure tunnelling

First thing everyone wants is passwordless login

convenience vs security

This next command will ask for a passphrase

  • if you want simple - leave the passphrase blank
  • secure but inconvenient - then give a passphrase
ssh-keygen #defaults to creating .ssh/id_rsa  
  creates 2 files .ssh/id_rsa and .ssh/
ssh-keygen -t dsa
ssh-copy-id RHOST
or the manual method
cat $HOME/.ssh/ | ssh $RUNAME@$RHOST 'cat >>.ssh/authorized_keys2'
# permission on the .ssh directory and the files within are IMPORTANT
ssh $RUNAME@$RHOST 'chmod 0600 .ssh/authorized_keys*'
### The passphrase challenge
ssh-agent bash
ssh-add id_rsa
# you need to enter the passphrase once (as long as this ssh-agent session is alive)

Know this: a users does not have a $HOME/.ssh directory by default It is only created when it is needed - eg when you ssh to another server

  • because it creates an .ssh/known_hosts file

The power in authorized_keys


An example of a restricted authorized_key file:

command="/bin/ls -ltr",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa KEY...ENDKEY user@FromHost

restricting shell access

scponly - once installed set up a new scponlyuser

usermod -s /usr/bin/scponly USERNAME

rssh - older and at one time had too many exploits

Example of authorized_key entry:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

Create a link in ~backup_user/ that links to the directory where the content should be accessible.

ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Now, from client side, the following command should work :

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

Another way: Here’s the authorized_keys file:

# authorized_keys
command="/usr/local/bin/" ssh-rsa.....== user@pewpew

Here’s the contents of

# /usr/local/bin/
    echo "Access Denied"


Subsystem sftp internal-sftp Match group sftponly ForceCommand internal-sftp

add the chrootDirectory %h and AllowTcpForwarding no after the match section to force the sftponly users to chroot to their home. please note that the match should (must!) be the last section on the ssh config and options after that are options just for the matched users – higuita May 28 ‘13 ForceCommand internal-sftp -u 0077 -d /uploaddir can farther harden it, by forcing a umask on an upload directory. In conjunction with ‘ChrootDirectory` it creates a very controlled, isolated upload environment. Bonus note: the default dir and the umask must be set in the ForceCommand, not in the Subsystem directive, if you want them to work. – Marcin Jun 6 ‘14


sudo apt-get install sshfs
# make sure permissions allow what you attempt
mkdir $HOME/mnt/ssh sshfs hostname:/data/share $HOME/mnt/ssh df -h
# to unmount
fusermount -u $HOME/mnt/ssh df -h ```

Port Forwarding

================== Creates a secure connection between computers through which services can be relayed.

Two types

  • Local port forwarding - most common - can be used to bypass a firewall
  • Remote port forwarding - less common - can allow you to connect from outside to a computer behind a firewall
  • Dynamic port forwarding - rarely used - can btpass a firewall - takes a lot of work to set up. Easier to use local port forwarding.

First - your server has to allow port forwarding.

  grep Forwarding /etc/sshd_config

Second - you need to determine the appropriate source and destination ports and destination IP

Local port forwarding

Example - local port forwarding:

  ssh -L localhost

Now point your browser to http://localhost:8080 and you will goto

  ssh -L -L localhost 

Now you have 2 port forward connection - one listening on 8080 the other on 12345.

Remote port forwarding

Example: you want to let a friend use your PC - assume you have vnc running on your pc.

ssh -R 5900:localhost:5900 friendname@friendPC

BTW: 5900 is typically used by VNC for the first/default instance set up.

Your friend can no access your vnc desktop by connection a vnc client to 5900 on HIS pc!

X forwarding

Your ssh server will forward X apps natively if it is allowed in the sshd_config.

A client can log into your PC with ssh -X yourpc and then run any X program (eg xclock) and it will be forwarded to your X display on your pc. ie:

ssh -X otherhost
firefox &
# or
ssh -f -T -X otherhost firefox

BTW - you will need xauth installed

You can speed things up just a bit with compression

ssh -fTC remoteuser@otherhost firefox

Wednesday, 15. April 2015 02:13PM

Geoff McNamara

"Do not meddle in the affairs of wizards, for they are subtle and quick to anger.” J.R.R Tolkien

Elizabeth City, NC