Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I just upgraded a (Linode VM) Ubuntu 9.04 to 9.10 using do-release-upgrade (as root). Now, ssh is not working.

At first, I was just getting "Connection timed out". So, I went to the Linode website and used their "lish ajax console". Not sure how this is different than ssh as it uses the same root password (which still works). There, I found that the file system was mounted as read-only. I fixed this by doing mount -t ext2 -o rw,remount /dev/hda6 /, but still no ssh connection. I then (still using the "lish ajax console" on the Linode website) used the command dhclient eth0, and now I am getting "Connection refused" instead of "Connection timed out", which feels a bit like progress but not much.

So, I can tell that the upgrade from 9.04 to 9.10 has not gone especially well. I can still see all my files using Linode's "lish ajax console", but I don't know how to get ssh to work, and unsurprisingly the websites on this server are not accessible anymore either.

Since the "lish ajax console" uses the same root password, I'm guessing that is still working, and all of the files I've looked for so far are there so not all is lost. But, I must need to do something else to get ssh working again. Any ideas?

p.s. Ok, thanks for hints, here's the results so far:

/etc/init.d/ssh status
could not access PID file for sshd
/etc/init.d/ssh start
Starting OpenBSD Secure Shell server sshd
/etc/init.d/ssh status
sshd is running

That sounded good, but then when I tried to puTTy in I got:

Server refused to allocate pty stdin: is not a tty

I poked around the internet for a bit and found out to try this:

/sbin/MAKEDEV pty
/sbin/MAKEDEV tty

But, no improvement.

ifconfig eth0

This gave confirmation that the IP address ("inet addr:") was what I expected.

iptables -I INPUT -p tcp --dport -j ACCEPT
bash: iptables: command not found

I found it kind of surprising that it had not heard of iptables, but what do I know. All I could find in the auth.log was this, not from now but from several hours ago.

root@localhost:/var/log# tail -f /var/log/auth.log                                                  
Apr 16 15:05:50 li9-111 sshd[10704]: pam_unix(sshd:auth): authentication failure; logname= uid=0 eui
d=0 tty=ssh ruser= rhost=60.10.58.156  user=root                                                    
Apr 16 15:05:52 li9-111 sshd[10704]: Failed password for root from 60.10.58.156 port 32776 ssh2     
Apr 16 15:05:58 li9-111 sshd[10706]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156 user=root                                                    
Apr 16 15:06:00 li9-111 sshd[10706]: Failed password for root from 60.10.58.156 port 33096 ssh2     
Apr 16 15:06:03 li9-111 sshd[10708]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156  user=root                                                    
Apr 16 15:06:05 li9-111 sshd[10708]: Failed password for root from 60.10.58.156 port 33588 ssh2     
Apr 16 15:06:11 li9-111 sshd[10710]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156  user=root                                                    
Apr 16 15:06:14 li9-111 sshd[10710]: Failed password for root from 60.10.58.156 port 33927 ssh2     
Apr 16 15:06:16 li9-111 sshd[10712]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156  user=root                                                    
Apr 16 15:06:18 li9-111 sshd[10712]: Failed password for root from 60.10.58.156 port 34404 ssh2 

In the syslog all I could find was this:

root@localhost:/var/log# tail -f /var/log/syslog

Apr 16 15:05:19 li9-111 mysqld: Active alarms: 0                                                  
Apr 16 15:05:19 li9-111 mysqld: Max used alarms: 1                                                  
Apr 16 15:05:19 li9-111 mysqld: Next alarm time: 0                                                  
Apr 16 15:05:19 li9-111 mysqld:                                                                     
Apr 16 15:05:19 li9-111 mysqld: Begin safemalloc memory dump:                                       
Apr 16 15:05:19 li9-111 mysqld:                                                                     
Apr 16 15:05:19 li9-111 mysqld: End safemalloc memory dump.                                         
Apr 16 15:05:48 li9-111 dhclient: DHCPREQUEST of 67.18.176.111 on eth0 to 72.14.180.19 port 67      
Apr 16 15:05:48 li9-111 dhclient: DHCPACK of 67.18.176.111 from 72.14.180.19                        
Apr 16 15:05:48 li9-111 dhclient: bound to 67.18.176.111 -- renewal in 35362 seconds.  

Lastly,

root@localhost:/var/log# netstat -ntlp                                                              
Active Internet connections (only servers)                                                          
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      891/sshd            
tcp6       0      0 :::22                   :::*                    LISTEN      891/sshd    

Thanks much for all the help so far, any further advice is greatly appreciated. Last Note: just in case something above wouldn't take affect until reboot, I tried that and the result was a step backwards (no response to attempt to ssh). So, I went back to the top and tried:

root@localhost:~# /etc/init.d/ssh status                                                            
 * could not access PID file for sshd                                                               
root@localhost:~# /etc/init.d/ssh start                                                             
 * Starting OpenBSD Secure Shell server sshd                             [ OK ]                     
root@localhost:~# /etc/init.d/ssh status                                                            
 * could not access PID file for sshd            

Which seems like maybe a step backwards. Anyway, any help or advice is appreciated.

share|improve this question
    
What @Pratik said, but please post the output of netstat -ntlp too. Also, you being able to log in via Linode's console doesn't actually mean ssh is up - I don't use Linode, but I'm guessing they're giving you console access, which is different from ssh. It's more like a serial cable connected directly to the server. –  Eduardo Ivanec Apr 16 '11 at 22:45

2 Answers 2

First make sure ssh is running, you can do this via

/etc/init.d/ssh status

If it is not running, start it by using the same command but replacing the status with start.

If that doesn't work check your interface configuration to make sure you are connecting to the right IP.

ifconfig eth0

Since you used dhcp to get an IP this might have changed.

There is a chance your firewall might be blocking it, you can open port 22 (it should be opened by default) by:

iptables -I INPUT -p tcp --dport 22 -j ACCEPT

Finally post the contents of /var/log/auth.log and /var/log/syslog while you are trying to connect.

share|improve this answer
up vote 1 down vote accepted

Well, it appears that the problem was a Linode-specific one. There is, in the configuration file for the VM, and the "kernel" setting for that was set at "Latest 2.6 Legacy (2.6.18.8-linode22". I had to change that to "Latest 2.6 Paravirt(2.6.38-linode31)", and then ssh (and websites served from this server) all came back. Whew!

I guess that the kernel that the linode was configured for was only for use in versions of Ubuntu older than 9.10. Frankly I thought that the os upgrade process would take care of that, but then I don't really understand everything about how the VM configuration file and the VM os interact, so it's not surprising that I was able to get into trouble, I guess.

I think maybe the takeaway lesson is that if you let your server os get that far out of date, there are odd things required for the upgrade path that won't always be in the most current documentation, because my god who is still on a version that old. Nonetheless I will have to take a deep breath and think a bit before trying to upgrade to the next newer os.

I guess for my next server fault question I will need to ask about server os upgrade strategies...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.