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/id_rsa.pub or ssh-keygen -t dsa
ssh-copy-id RHOST or the manual method cat $HOME/.ssh/id_rsa.pub | 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
OPTIONS KEY_TYPE KEY COMMENT ... OPTIONS KEY_TYPE KEY COMMENT
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/remote-cmd.sh" ssh-rsa.....== user@pewpew
Here’s the contents of remote-cmd.sh:
#!/bin/bash # /usr/local/bin/remote-cmd.sh case $SSH_ORIGINAL_COMMAND in 'scp'*) $SSH_ORIGINAL_COMMAND ;; 'rsync'*) $SSH_ORIGINAL_COMMAND ;; *) echo "Access Denied" ;; esac
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 ```
================== Creates a secure connection between computers through which services can be relayed.
- 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 8080:www.ubuntuforums.org:80 localhost
Now point your browser to http://localhost:8080 and you will goto ubuntuforums.org
ssh -L 8080:www.ubuntuforums.org:80 -L 12345:www.ubuntu.com:80 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!
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.
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