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 :: <- listen on all ipv6 interfaces . .
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.
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:-
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!