====== Secure Shell, ssh ======

The Secure Shell is basically an encrypted telnet, but it can do a lot more than telnet ever could such as tunnelling encrypted connections both in forward and reverse directions. Both clients and servers are available SSH on many operating systems. 

===== sshd_config =====


sshd_config lives in /etc/ssh/ and controls the operation of the ssh server. Most of it is obvious by reading the sshd & sshd_config man pages, so I will not go over it here.
Listen Addresses

==== Interfaces ====


I was caught out trying to set up a linux router with multiple interfaces. I was unable to ssh to it from any os or client, but pings and ntp worked fine. It seems that for a host with multiple interfaces, you have to specify the addresses you want sshd to listen to explicitly. However subsequently I have not had this problem on other systems, but it can be used to advantage if you have a multihomed system and you only want to bind sshd to one address.


  Port 22
  ListenAddress 192.168.1.1
  ListenAddress 192.168.2.1
  #ListenAddress ::  <- listen on all ipv6 interfaces
  .
  .

==== Default Protocol ====

Another thing to check is to change the protocol from the default of either 2 or 1 to just 2. Protocol 1 is cryptographically flawed and should NEVER be used, protocol 2 is a more secure option.

  #Protocol 2,1
  Protocol 2


==== System Banner ====

Also on the security front, further down sshd_config, consider adding a banner warning stating that the system is private and not for public access. In the unlikely event you are hacked and catch the culprit you will have a stronger legal case if you have told any intruders that they should not be there. 

  .
  # banner path
  Banner /etc/issue

''/etc/issue'' is displayed on a console before login, sometimes a ''/etc/issue.net'' is present in case you want to have a different warning for local console users compared to network login users. Bear in mind that ssh -q will not show a banner so don't rely on just this alone as a security warning. 

''/etc/motd'' (Message Of The Day) is displayed after a successful login, so any system specific info should go there and not in ''/etc/issue''. 

After having done this change, you will need to stop (not just restart sshd) with
''/etc/rc.d/rc.sshd stop'' and ''/etc/rc.d/rc.sshd start''
  
And the result? Success!!

  zeus:~ andrewst$ ssh 192.168.1.1 -l andrew
  andrew@192.168.1.1's password: 
  Last login: Tue Apr 20 00:56:35 2004 from 192.168.1.21
  Linux 2.4.25.
  Welcome to Slackware!
  andrew@corerouter:~$ 


==== Enable TCP keep alives ====

Add the following to /etc/ssh/sshd_config to prevent inactivity causing a firewall terminating a session:-

  TCPKeepAlive yes
  KeepAlive yes
  ClientAliveInterval 60




===== SSH tunnels =====

  ssh -L localhost:5222:myxmpp.mydomain.co.uk:5222 -p 443 user@proxy.server.co.uk
  
  ssh -L localhost:222:ssh.mydomain.co.uk:22 -L localhost:10022:midpoint.myserver.com:22 -p 443 user@proxy.server.co.uk
  

==== Socks Server ====

Set up a ssh tunnel to my.server.com:443 and create a listening socket on localhost port 1080

  ssh -D 1080 -p 443 user@my.server.com
  
Other options:- ''-f'' forks to the background, to kill this will need to use ''ps'' and ''kill'', ''-N'' does not start a shell (No Command), ''-C'' compresses data in the tunnel.

===== ssh key authentication with LDAP =====


[[https://serverfault.com/questions/653792/ssh-key-authentication-using-ldap]]


===== IP address range control =====
 

[[https://serverfault.com/questions/406839/only-allow-password-authentication-to-ssh-server-from-internal-network]]
===== Hijacking an ssh session =====

Suppose you are logged in to ''local'' with an ssh session to ''remote'' and that root is also logged in to ''remote''. 

root can  see from ''netstat -tn'' what the DISPLAY is that ''local'' is using on ''remote'', probably 6000 or higher and you subtract 6000 to get the X display number.

root:-
<code>
root@remote:/root # export DISPLAY=localhost:10.0
root@remote:/root # export XAUTHORITY=/home/[victim]/.Xauthority

root@remote:/root # xeyes &   <- runs xeyes displayed on victims ''local'' machine

root@remote:/root # xwd -display localhost:10 -out victimdisplay -root -silent
</code>

root changes display back to root's localhost
<code>
root@remote:/root # xwud - in victimdisplay -scale
</code>



===== Tail end quote =====

And why to use ssh keys if possible and appropriate:-

//Remember passwords are like underwear... don't share with friends & definitely don't leave them lying around!//