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 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

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 :: . .

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

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:~$ 

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

TCPKeepAlive yes
KeepAlive yes
ClientAliveInterval 60

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

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.

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

Suppoer 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:-

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

root changes display back to root's localhost

root@remote:/root # xwud - in victimdisplay -scale

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!