-
Notifications
You must be signed in to change notification settings - Fork 764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
get_passwd: LookupAccountName() failed: 1332. #1476
Comments
To add, this same setup and ACLs (different SIDs, obviously, but "same" accounts) works on my other laptop that also does not belong to a domain, though it's not AAD-joined either (personal machine with only an associated MSA). |
Can you try the latest version and provide the debug DEBUG3 logs for those? |
I'm seeing something similar with the latest version.
|
I'm not sure if it's related, but in another product we ran into a problem with AAD-joined accounts where |
This problem still occurs and, since we're all working remotely apart from Redmond campus of Microsoft, I had to AAD-join and cannot SSH into my machines after setting up a new machine. |
@heaths - There is a proposed feature request to ssh using AAD credentials. Windows AAD team is supposed to make this change in next semister. However, I have a workaround.
Please note only password based authentication will work. |
Will those plans include supporting PubkeyAuthentication? I use a Yubikey normally, which is much more secure. |
@heaths - Yeah, the feature request is to generate the token for AAD user using a WIN32 API. |
That work around worked flawlessly :) |
But the feature request will still require AAD authentication? Won't that still be a problem between domain-joined machines like my workstation back in the office and my AAD-joined laptop? Especially if the key changes since it's generated, or is that a one-time (or seldom, at most) generation? |
@heaths - I didn't get your questions. Password based authentication with AAD credential works now. SSHD service runs as local system so it should be able to generate token for any user without their credentials. In case of public key authentication, after SSHD verifies the keys it will retrieve the token for the user and spawn the subsequent child processes in user context. |
I don't want to use PasswordAuthentication. I have a Yubikey I use for MFA using PubkeyAuthentication, which is far more secure. What I wasn't clear on your reply (hence my question, which I'll try to clarify) is how what you described solves the problem. Is the feature ask to generate a key pair on the fly based on AAD credentials, then send the public key to SSHD for authentication? Is a key pair generated once if it doesn't exist, or does this happen every time, or seldomly? How would we save the pub key to ~/.ssh/authorized_keys if it's generated? If a future feature would resolve this somehow, great! But this seems like a bug-level fix now if it's the same problem I experienced on my previous team I helped fix: that LookupAccountName expects a domain, with AAD-joined accounts don't have, it seems, in a form that |
@heaths - We are not dong any changes to key based authentication i.e., the keys are not generated on fly. User is responsible for generation of keys and storing them at respective places with right ACLs. |
@bagajjal 's workaround isn't working for me... I did This makes me think it is is something to do with the account the service is started as. |
I'm running Windows 10 2004 (10.0.19041) and tried the workaround as well:
Without any luck: ssh.exe AzureAD\jan.egil.ring@contoso.com@10.0.1.203 -vvv -i C:\Users\adminjer.ssh\id_rsa debug3: authmethod_is_enabled publickey Server side log (C:\ProgramData\ssh\logs\sshd.log): 24884 2020-08-16 21:55:45.099 Accepted publickey for AzureAD\jan.egil.ring@contoso.com from 10.0.1.22 port 59126 ssh2: RSA SHA256:2v6iH3yZUP3QnovEZ1vyL9SFJLf8ulReuia0uyKTSi4 Any ETA for when Azure AD support for OpenSSH in Windows will become available? Is it likely to be released in the next Windows Feature release later this year? Or could it also come in a Cumulative Update? |
@bagajjal sorry for the late reply, but having re-read the last few comments back and forth, you seemed to indicate that key-based authentication should work. That's exactly what doesn't. In the initial comment when opening this bug, I mentioned that I set As mentioned, I suspect this is because AAD doesn't actually have a domain, and Have you tried the repro?
This fails with the error in the subject. |
I got It only fail when I run sshd as a service, login is ok when I run sshd.exe manually. |
Also facing this issue, very frustrating :( |
Revised: My original comment was targeted for a different audience and does not apply to this specific issue, but keeping the information for reference. If you are facing public key authentication in general and are unsure if this issue is related, here's a link to gist that will confirm public key authentication is set up correctly. |
Having the exact same issue as described by @GongT . Very frustrating. All permissions correctly set on all files. Following sshd file:
And this is the generated debug log when attempting to connect via public key authentication (That means you, @asheroto):
|
Also, as for @asheroto , your solution really isn't a solution if it requires disabling password authentication. Public key authentication should be able to work alongside password authentication, not at its expense. Afraid that solution is wholly inadequate. |
My comment was targeted for ensuring that public key authentication works. Password authentication, at least with the settings I described, works fine alongside public key authentication so long as you enable it in your config. Are you saying you're still facing an issue authenticating even if enabled? With public+password enabled I still receive the error described by the original poster, even though both forms of authentication are working. |
@asheroto I also followed your instructions, and it doesn't work. Feel free to see the debug log posted above. There are also reports throughout this issue that public key authentication does not work if you encounter this particular issue:
So, if you were able to authenticate with public key authentication, you do not have the same issue that everyone else has. |
No worries, I revised my comment with a link for reference, but explained that it was mistargeted as it doesn't specifically apply to this issue. Thanks for letting me know |
All solutions here only work with manual sshd launch, never with the
system's, from boot.
…On Sat, Mar 27, 2021, 17:03 Asher Oto ***@***.***> wrote:
@demdante <https://github.com/demdante>
No worries, I revised my comment with a link for reference, but explained
that it was mistargeted as it doesn't specifically apply to this issue.
Thanks for letting me know
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1476 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAQQ2J7OTLU7QYXH33JW3DTFZW6XANCNFSM4I55OZGA>
.
|
They're also not solutions, but work arounds that don't solve the underlying problem: keeping password authentication disabled while relying on hardware security keys (MFA: something you have, plus something you know - e.g. the PIN on the key). The original bug with LookupAccountName() can be solved. We had to work around this same issue in the Visual Studio installer when setting up scheduled tasks for updates for machines that were joined to an AAD. |
@heaths - Please refer to my comment #1543 (comment). |
Related to |
Closing this issue. Created a new issue for AAD support, #1787 |
For future reference, the error "LookupAccountName() failed: 1332" can happen because of multiple reasons. Please don't comment on this issue. Request you to open a new issue. |
@bagajjal The password based authentication works for me. Thanks for the workaround! |
"OpenSSH for Windows" version
((Get-Item (Get-Command sshd).Source).VersionInfo.FileVersion)
7.7.2.2
Server OperatingSystem
((Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows nt\CurrentVersion\" -Name ProductName).ProductName)
Windows 10 Enterprise
Client OperatingSystem
Windows 10 build 1903
What is failing
I cannot ssh into my machine. I've set this up before, but this time my laptop is not domain-joined, but instead AAD-joined (Intune managed), which seems to be part of the problem from what information I could find about
LookupAccountName
and error 1332.My sshd_config is nearly default. I set
PasswordAuthentication
tono
, but apart from that (and temporarily loggingDEBUG3
server output), nothing else is different.From the debug log, I see:
My $ProgramData\ssh\administrators_authorized_keys contains my public key, as does my ~.ssh\authorized_keys. icacls shows appropriate ownership and DACLs.
Basically, everything is set up as I've done before except that I'm not domain joined (normally do, but was having some unrelated problems setting up a new machine).
Expected output
I can log in via ssh.
Actual output
I'm denied access.
The text was updated successfully, but these errors were encountered: