-1

I'm trying to solve an online challenge. I've got a server address and a private RSA key, both of which I'm giving to Putty (I'm using Windows, the server is running OpenSSH on Ubuntu). I've managed to connect using a passphrase I've found and a user name which I've guessed. However, as soon as I'm giving Putty the username and the RSA passphrase, the server is responding with:

/bin/false: File not found

And closes the connection immediately.

Is it possible that the same private key can be used with a different username which will have a different home directory (hopefully)?

Is there a way to change the default home directory during the connection negotiation?

I also have read only access to an FTP server which is served from the same IP address, however I didn't find (or don't have permissions to) any SSH config files sitting there (the FTP server is where I found the private RSA key)

Anyway, any advice is of course appreciated. I've been banging my head against the wall for the past 2 days trying to solve this.

  • 2
    I'm pretty sure your question shouldn't be ask here, where would be the challenge. A hint though, it sounds like your user doesn't have a shell and the user shell is set in a specific file – Kiwy Apr 24 '18 at 7:57
  • 1
    Probably, you forgot the leading /. You want /bin/false (not bin/false without a leading slash). It is very likely to be available (in the coreutils package that your remote Ubuntu is very likely to have installed already). And some users on Ubuntu are system-users and have /bin/false as their login shell to forbid remote logins – Basile Starynkevitch Apr 24 '18 at 8:21
  • What's the exact error message you got? – muru Apr 24 '18 at 8:35
4

Yes, it is possible to use the same key with an arbitrary number of users.

No, there is no way to change the default home directory during the connection negotiation, as far as I know.

I would guess that the username you've guessed has its shell specified as bin/false. One way to disable a Unix user account for logins is to set its shell to /bin/false, so any login attempt will execute /bin/false instead of a shell. Since /bin/false is a very simple program that is not in any way interactive and will just return an error code, the session will immediately end.

Depending on how other services on the system are configured, the account might still be usable for other things that don't need a shell, like FTP or SFTP connections or IMAP/POP email access for example.

In your case, it looks like the initial slash may be missing. If so, the system effectively looks for <current directory>/bin/false and fails to find it, and so you'll see the error message resulting from that.

Hint 1:

You might want to try figuring out what that directory is, and see if it is accessible.

Hint 2:

Perhaps you could supply something executeable to that path?

  • Unless the SSH server had something like ForceCommand internal-sftp for OP's account (or perhaps sftp-server installed?), SFTP would still need a working shell. – muru Apr 24 '18 at 8:23
  • I'm so so sorry. There was a /bin/false in the server response, I just probably got rid of it by mistake when pasting. – Shmoopy Apr 24 '18 at 8:38
0

It looks like there is something like in /etc/passwd file:

user:x:1000:1000:,,,:/home/user:/bin/false

So, the login shell is /bin/false You have to bypass it.

See: https://serverfault.com/questions/162018/force-ssh-to-use-a-specific-shell

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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