9

I have a hashed password $6$salt$hash. I want to ssh to a linux server with this hash. How could I do that? Do I need to change cipher spec? Is that possible?

schroeder
  • 123,438
  • 55
  • 284
  • 319
user203988
  • 91
  • 1
  • 1
  • 3
  • 13
    Why do you want to do that? Are you trying to achieve passwordless login (for which you should be using keys?) – pjc50 May 03 '19 at 10:00
  • 3
    Is there any reason to not be using SSH keys instead? Public key - private key approach. Seems to accomplish the same goal (not having raw password on the wire). Not trying to be "that guy" that answers "How to do X" with "Don't do X, do Y", but it seems a strictly better approach. – Captain Man May 03 '19 at 17:44
  • 12
    If you're passing a "hash" then the hash is the password – Richard Tingle May 03 '19 at 20:11
  • There _are_ techniques to authenticate with a password without the server needing to know your password, but SSH unfortunately does not use them, to the best of my knowledge. – forest May 04 '19 at 00:42

3 Answers3

42

You will not be able to do that.
The password is verified by the SSH server (or better by PAM library or similar authentication backend on other platform) by taking the received password, hashing it and comparing it to the stored hashed one. There is no way to bypass this process and make the server use the hash directly for comparison.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
5

I'm going to go out on a limb and guess that this is part of a penetration testing training programme. In which case, you can't get into the system using that hash directly, but you can pass that hash to a cracking programme, such as HashCat, which will attempt to crack the password it represents (and is much faster than online brute force).

If it's for a penetration testing training programme, the password will likely be something easily cracked, such as the "enterprise standard" password of "Password123!".

James_pic
  • 2,520
  • 2
  • 17
  • 22
  • 1
    My guess isn't a total stab in the dark - I had a quick spy at some of the OP's other questions, and they seem to be working through some pen testing training materials. We do all have to start somewhere, so it's good to ask questions. But based on my experience of the industry, I wouldn't be at all surprised if the OP is out on a client site two weeks from now, as a "trained pen tester", so you may be right to weep. – James_pic May 05 '19 at 09:16
-4

I agree with Steffen that the server will store a hash of the 'password' and verify your password by hashing it and seeing if it matches the stored value. However, I don't see why you couldn't be storing a hash of the hash resultant of the password in the server and hash the password on your side before passing it to the server.

The server would hold only: Hash(Hash(Password))
and you would be required on your side to pass: Hash(Password)

I am sure, depending on how secure your side is, this is at least a little more time consuming from a cybersecurity measure for an attacker to crack the password if taken from server side or via transmission, but cumbersome.

J. Doe
  • 1
  • 2
    OP wants to gain access to the server using the hashed password, he can't change the password on the server to `Hash(password)`. This wouldn't work very well as a way of strengthening the password either, as OP would need to keep track of the salt, he'd be better off just using a better password. – AndrolGenhald May 03 '19 at 14:39
  • 1
    I agree that it wouldn't be the best solution, especially after hashing hashes has the potential to dilute the hash. I was just trying to think of a way to allow him to hash the password before transmission. – J. Doe May 03 '19 at 15:57
  • 1
    "Diluting the hash" isn't a concern, the concern is that the hash essentially _becomes_ the password, and it's much easier to just remember a better password in the first place. SSH already supports public key authentication anyway if you don't like sending your password to the server. – AndrolGenhald May 03 '19 at 16:41
  • @AndrolGenhald Well, "diluting the hash" _is_ still a concern. – wizzwizz4 May 03 '19 at 20:19
  • @wizzwizz4 Not if it's only a couple of hashes, or if it's a proper KDF that includes the salt in each iteration. – AndrolGenhald May 03 '19 at 20:25
  • @AndrolGenhald But that's not what's being shown in the answer. – wizzwizz4 May 03 '19 at 20:26
  • @wizzwizz4 The answer just says `Hash`. I assumed it was referring to a "generic hash function", in which case 2 iterations (1 client and 1 server) doesn't cause any concern about reduced entropy due to collisions or a short cycle. It could also be referring to sha512crypt mentioned in the question, in which case the salt is used in multiple iterations, even though it's [not necessary](https://crypto.stackexchange.com/a/12817). – AndrolGenhald May 03 '19 at 20:48