8

After a successful login to my VPS the command prompt doesn't get displayed. I've ran ssh with -vvv and sshd with debug output, absolutely nothing is amiss.

The VPS is Ubuntu 11.04, the client Ubuntu 11.10, sitting behind a router. The strange thing is my laptop (also Ubuntu 11.10) behind that same router connects and gets the command prompt no problem.

/var/log/auth output is here

ssh -vvv output is here

Since the laptop gets the command prompt without issues, I'm guessing the problem is with my desktop. Can I do like a flush of everything ssh related in case I screwed something up? I've tried deleting ~/.ssh/knownhosts but that didn't do it.

6
  • 1
    what type of VPS ? can you post the output of ssh -vvv the logs do not show much.
    – Panther
    Jan 8, 2012 at 2:00
  • added the -vvv output. VPS is OpenVZ. like I said, the other machine connects to it without a hitch.
    – sostacked
    Jan 8, 2012 at 2:15
  • Only other issue I can think of is with your user ssh config. Please could you provide the contents if $HOME/.ssh/config . Make sure there is no sensitive content in there.
    – CodeMedic
    Jan 8, 2012 at 2:27
  • haven't got one, there is no config file in my home/.ssh dir and neither is there on the other client, the one that works. the /etc/ssh/ssh_config files are stock and identical on both clients.
    – sostacked
    Jan 8, 2012 at 2:30
  • could it be that the VPS has some block access from host xy thingy? that would explain the sound of silence...? hosts.allow and .deny are ok, so maybe purge stored keys from previous connections or something? where would I look fot those?
    – sostacked
    Jan 8, 2012 at 3:06

8 Answers 8

3

Not sure if this is the same issue I saw, but on Ubuntu they require bash to be run in login mode to set the prompt, as such unless you have login=yes in the sshd_config you will not get a prompt.

3

For the sake of others that end up with similar problems, here is another solution:

Our embedded system was allowing ssh connections, but was not giving a shell prompt. By setting the logging output to DEBUG3 in sshd_config and checking the /var/log/messages, we were able to determine that the ssh server was going to pause for about 100 years!

Our embedded system never initialised its clock, so it thought it was 1917. Because the ssh client message was from the future, the server was waiting for its own time to catch up to it. We resolved the problem by setting the time (using date) and restarting the server (using /etc/init.d/sshd restart).

1
  • seconding this--check the date and time settings on your server!! I recently experienced a similar issue due to daylight savings time
    – adrian
    Nov 5, 2023 at 21:55
1

I have the same problem on an embedded device. The problem was that /dev/pts was not mounted.

sudo mount -t devpts none /dev/pts
0

Once you're logged in, do echo "$PS1" | od -bc. Your prompt, PS1 (assuming bash) is set by your startup scripts. Where do you set up your prompt? Perhaps you need to add your PS1 definition to ~/.ssh/environment or ~/.ssh/rc on the target. See man ssh and man sshd.

1
  • tried it, set up a simple prompt in ~/.ssh/environment. same result. from what I understand, if it's a server config issue, then none of the PC's would've been able to get the prompt, but they do. all except this one.
    – sostacked
    Jan 8, 2012 at 3:23
0

Solved it. ufw was acting out. Although sudo ufw status returns "disabled", running sudo ufw disable fixed it. I haz no explanation for it, after wasting way too much time with this I'm just happy it works.

0

If you running sshd as a systemd managed process, then after making any changes to /etc/ssh/sshd_config you must execute systemctl restart sshd for the changes to take effect.

0

I solved this by removing the option -T from the ssh command

1
  • 1
    Hey, João, welcome to the site! As this stands, it looks almost more like a comment than an answer. Please edit to expand. Don't just give a one-liner; explain why you right, ideally with citations. Answers without explanation are subject to removal.
    – anonymous2
    Mar 4, 2019 at 18:52
0

In my case, I had done the brilliance of changing configuration in /etc/ssh/sshd_config and setting PermitTTY no.

Editing that file to set PermitTTY yes and restarting sshd solved the problem.

Hope it helps someone, cheers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .