Ssh – Why do some ssh sessions offer autocomplete and some not

As to whether your session will be disconnected - it depends.

You say you are connected via the IP of the default route; I take it you mean that you are connect to the IP address of the physical interface which shares a link with the next hop of your default route? e.g. if you have the following configuration:

interface FastEthernet0/1
 ip address 10.10.10.1 255.255.255.0
!
interface FastEthernet0/2
 ip address 20.20.20.1 255.255.255.0
!

ip route 0.0.0.0 0.0.0.0 10.10.10.10

Then you are connected to the route using destination IP address 10.10.10.1?

When you say you are changing the default route, are you changing the next hop of your default route? e.g.:

ip route 0.0.0.0 0.0.0.0 20.20.20.20
no ip route 0.0.0.0 0.0.0.0 10.10.10.10

(Note, add the new default before removing the old!)

Or, are you changing the interface IP address?

interface FastEthernet0/1
 ip address 10.10.10.50 255.255.255.0
!

In the first case, assuming your workstation is still reachable via 20.20.20.20, your SSH session may hang for a moment or two, but will probably not be disconnected. As you are still connecting to the same IP address, TCP will not disconnect; your packets will simply be routing asymmetrically (going into the router via Fa0/1, and out via Fa0/2).

In the second case, your SSH session will definitely disconnect, as the IP address that is the endpoint of your SSH session will no longer be configured on the router.

If you are disconnected: * You should be able to connect to the IP address of the new interface, as long as bidirectional routing is in place between your workstation and the new IP address. * All changes that you have entered will still be in the running configuration; you will need to save them by typing 'copy running-config startup-config'. * The number of connections will be limited by the number of vty lines you have configured. The default (I believe) is 16; some organisations reduce this for performance/security reasons. Do a 'show run | begin line vty' to see how many lines you have configured.

Without knowing more about your network, it's difficult to suggest improvements; one thing I would say is that if you are running any kind of IGP, then it's probably worth managing your devices using Loopback interfaces. This mitigates against being disconnected while making a change which causes a routing reconvergence.

EDIT: managing via loopback interfaces essentially means ensuring that all of your management traffic (telnet/SSH, syslog, SNMP, TACACS etc) uses the loopback address of your router. This is advantageous for a couple of reasons:

1. When you have a failure which causes reconvergence in your network, existing management sessions aren't interrupted.
2. All management traffic is addressed to a loopback interface, which means that any ACLs/firewall policies restricting management access can be simplified.
3. Re-addressing your network becomes easier, as adding/removing links doesn't change the IP address you use to manage your devices; as long as there is a correctly configured IGP running, you should be able to reach your devices and manage them.

The reason ssh X forwarding wasn't working was because I have a /etc/ssh/sshrc config file.

The end of the sshd(8) man page states:

If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth

So I add the following commands to /etc/ssh/sshrc (also from the sshd man page) on the server side:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

And it works!