this post was submitted on 14 Aug 2024
110 points (99.1% liked)

Linux

48149 readers
987 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

I have my own ssh server (on raspberry pi 5, Ubuntu Server 23) but when I try to connect from my PC using key authentication (having password disabled), I get a blank screen. A blinking cursor.

However, once I enter the command eval "$(ssh-agent -s)" and try ssh again, I successfully login after entering my passphrase. I don't want to issue this command every time. Is that possible?

This does not occur when I have password enabled on the ssh server. Also, ideally, I want to enter my passphrase EVERYTIME I connect to my server, so ideally I don't want it to be stored in cache or something. I want the passphrase to be a lil' password so that other people can't accidentally connect to my server when they use my PC.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 46 points 3 months ago (4 children)

The whole point of ssh-agent is to remember your passphrase. If you don't want to do that your problem might be that for some reason ssh client doesn't pick up your key. Try defining it for the host

Also, there's -v flag for ssh. Use it to debug what's going on when it doesn't try to use your key

[–] [email protected] 7 points 3 months ago* (last edited 3 months ago) (1 children)

okay I tried that, using -i to specify private key. I get the same thing: blank / blinking cursor. When I use verbose -v flag, I see that in both (using -i, the config file, and originally) cases (I see about 50 lines) it ends with these two lines:

debug1: Offering public key: /home/username/.ssh/id_rsa RSA SHA256:j3MUkYzhTrjC6PHkIbre3O(etc) agent
debug1: Server accepts key: /home/username/.ssh/id_rsa RSA SHA256:j3MUkYzhTrjC6PHkIbre3OT(etc) agent

where (etc) is some redacted text. It seems the server is ACCEPTING the key, which is nice. But then it's still a blinking cursor...

[–] [email protected] 2 points 3 months ago (1 children)

It seems the server is ACCEPTING the key

Check if it is true. In the server logs.

[–] [email protected] 4 points 3 months ago* (last edited 3 months ago) (1 children)

I'm not sure which logs I can and should check, but when I listen to this: sudo tail -f /var/log/auth.log

I only get this right after I ctrl+C on my blank / blinking cursor screen. (Did this 3 times in a row.)

2024-08-14T11:35:32.874228+02:00 pidoos sshd[3957]: Connection closed by authenticating user pi MY_PUBLIC_IP port 52242 [preauth]
2024-08-14T11:35:50.168160+02:00 pidoos sshd[3975]: Connection closed by authenticating user pi MY_PUBLIC_IP port 39266 [preauth]
2024-08-14T11:35:55.236347+02:00 pidoos sshd[3987]: Connection closed by authenticating user pi MY_PUBLIC_IP port 41318 [preauth]

Where MY_PUBLIC_IP is redacted. I'm not even sure why my public IP is showing. I connect locally. But ports are forwarded, yes.

Using sudo journalctl -u sshd -f does not seem to output anything...

[–] [email protected] 2 points 3 months ago

That's only part of the handshake. It'd require agent input around that point.

[–] [email protected] 6 points 3 months ago

The whole point of ssh-agent is to remember your passphrase.

replace passphrase with private key and you're very correct.

passphrases used to login to servers using PasswordAuthentication are not stored in the agent. i might be wrong with technical details on how the private key is actually stored in RAM by the agent, but in the context of ssh passphrases that could be directly used for login to servers, saying the agent stores passphrases is at least a bit misleading.

what you want is:

  • use Key authentication, not passwords
  • disable passwordauthentication on the server when you have setup and secured (some sort of backup) ssh access with keys instead of passwords.
  • if you always want to provide a short password for login, then don't use an agent, i.e. unset that environment variable and check ssh_config
  • give your private key a password that fits your needs (average time it shoulf take attackers to guess that password vs your time you need overall to exchange the pubkey on all your servers)
  • change the privatekey every time immediately after someone might have had access to the password protected privkey file
  • do not give others access to your account on your pc to not have to change your private key too often.

also an idea:

  • use a token that stores the private key AND is PIN protected as in it would lock itself upon a few tries with a wrong pin. this way the "password" needed to enter for logins can be minimal while at the same time protecting the private key from beeing copied. but even then one should not let others have access to the same machine (of course not as root) or account (as user, but better not at all) as an unlocked token could also possibly be used to place a second attacker provided key on the server you wanted to protect.

all depends on the level of security you want to achieve. additional TOTP could improve security too (but beware that some authenticator providers might have "sharing" features which could compromise the TOTP token even before its first use.

[–] [email protected] 5 points 3 months ago (1 children)

FWIW, I've found that the -v flag often doesn't say why it's not using your key, just that it isn't using your key and it has fallen back to password authentication.

It's usually not terribly helpful for figuring out why it's not using your key, just that it's not using your key, which you kind of already know if it's prompting you for a password. lol

[–] [email protected] 2 points 3 months ago

Because it's basically axiomatic: ssh uses all keys it knows about. The system can't tell you why it's not using something it doesn't know it should be able to use. You can give a -i for the certificate to check if it doesn't know it because the content is broken or the location.

That said: this doesn't make -v more useful for cases like this, just because there's a reason!

[–] [email protected] 3 points 3 months ago (1 children)

Not OP but everytime I used the verbose output of ssh it didn't help me one bit. Even adding outrageous verbosity I was still quite confused on what step failed and which didn't.

I'm probably just bad at understanding SSH but i don't know it seems like ssh workflow includes many trial and error until it finds a way to connect.

Imo the verbose output of SSH is often not very helpful if you don't know very well ssh in the first place. Obviously it is still worth a shot and a good advice but don't expect ssh to clearly state what is going on :)

[–] [email protected] 1 points 3 months ago (1 children)

Well, you have configuration and flag options to define what is it supposed to be trying to use. What order, I think too. But definitely understanding SSH a little bit will make the log more understandable. As with everything tbh :D

[–] [email protected] 3 points 3 months ago

This likely isn't helpful but it isn't meant to be a shitpost. However, I will point out this literature:

SSH, The Secure Shell: The Definitive Guide, 2nd Edition

https://github.com/manish-old/ebooks-2/blob/master/O'Reilly%20-%20SSH%20The%20Secure%20Shell%20The%20Definitive%20Guide-2.pdf

Other commenters clearly know more than me about tbs ssh, so I'll otherwise remain silent.