SSH
Review
 1-minute exercise:
 Find the open ports on you own VM
[Good] nmap 127.0.0.1
[Better] netstat -lpunt
SSH Intro
 At its highest level, ssh provides secure (encrypted)
communications between user accounts on two machines.
 There were several other non-secure communications
protocols popular before ssh:
 telnet (port 23)
 rsh (Remote SHell, port 22)
 rexec (Remote EXECution, port 512)
 Two problems with insecure shells:
 Sniffing data
 Sniffing login passwords
Telnet
 Developed in 1969 with RFC 15
 Before the popularity of ‘login accounts’ and ‘passwords’
 Useful for closed networks where everybody was trusted
 From kali or your personal VM:
 telnet 14.29.4.105
 username: msfadmin
 password: msfadmin
 This establishes a telnet session with the metasploitable VM.
 You can enter any command and it will run on the remote
machine. e.g.
 whoami
 ifconfig
 netstat –lpunt
Telnet Comms – 1 keypress per packet
Host B
Host A
User
types
‘C’
host ACKs
receipt
of echoed
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
Seq=43, ACK=80
Start tcpdump to watch your messages: sudo tcpdump –n –X
SSH Intro
 Cryptographic network protocol (Layer-7)
 Remote login
 ssh user@hostname
 Remote command execution
 ssh user@hostname cmd
 Secure data communications
 scp user@hostname
SSH Intro
 Requires SSH server (sshd) on remote machine
 Defaults to port 22
 Requires ssh client (ssh) on local machine
SSH Intro
 User logs in with use credentials of remote machine.
user:owner
password:123456
MachineA
user:smith
password:password
user: owner
password: trustno1
MachineB
 Assume each machine maintains its own /etc/passwd file
 The two ‘owner’ accounts are not related – just same name
 Any user on MachineB can ssh to ‘owner’ on Machine A.
SSH Examples
 Remote login
 ssh msfadmin@14.29.4.105
 ssh owner@10.10.1.10
 Remote command execution
 ssh msfadmin@14.29.4.105 ifconfig
 ssh owner@10.10.1.10 cat /etc/shadow
SSH Examples
 Secure data communications
 scp (“Secure CoPy”)
 scp user@hostname:/somefile.txt /local/dir/
 scp /local/file.txt user@hostname:/remote/dir/
 scp –r /local/dir/ ... # Copies dir recursively
 Try copying a file in both directions from your personal VM:
 scp owner@10.10.1.10:/etc/passwd www.passwd.txt
 cat www.passwd.txt
 echo “hello” > yourlastname.txt
 scp yourlastname.txt owner@10.10.1.10:/home/owner
 ssh owner@10.10.1.10 cat /home/owner/yourlastname.txt
SSH With Public/Private Keys
 You can set up ssh to use stored keys instead of a password
 Password == private because only one person knows it
 Private key == private because it is in a user’s home directory
and can only be accessed by that user (*This is a lot of trust)
user:owner
~/.ssh/authorized_keys
user: owner
~/.ssh/id_dsa
# Contains owner’s public key
#Contains owner’s private key
MachineA
MachineB
 ‘owner’ can ssh from B to A without a password:
 ssh MachineA
How to set up SSH with keys
1. Create personal user account on the webserver:
ssh owner@10.10.1.10
sudo useradd –m yourloginname
sudo passwd yourloginname
exit
2. Create keys on your personal VM
ssh-keygen –t dsa #Press <Return> at each prompt
cd ~/.ssh
ls –al
#Two new files: ida_dsa, ida_dsa.pub
How to set up SSH with keys
3. Copy public key to webserver:
ssh-add
# Loads your new key into the ssh agent
ssh-copy-id yourlastname@10.10.1.10
# Appends id_dsa.pub to 10.10.1.10:~/.ssh/authorized_keys
4. Login to the webserver
ssh 10.10.1.10 # No username or password required
cd .ssh
ls -al
cat authorized/keys