* OpenSSH 6.8p1-1 and keychain: can't determine fingerprint @ 2015-03-27 5:04 White, W John (GE Transportation) 0 siblings, 0 replies; 3+ messages in thread From: White, W John (GE Transportation) @ 2015-03-27 5:04 UTC (permalink / raw) To: cygwin After updating to OpenSSH 6.8p1-1, I experienced an issue where, at every login, keychain (in my .bash_profile) wrote a warning: My .bash_profile lines: # Start keychain, passing as args all private keys to be cached keychain ${HOME}/.ssh/id_dsa #, other_key1, other_key2, ... # That creates a file which must be sourced to set env vars source ${HOME}/.keychain/${HOSTNAME}-sh The warning: Can't determine fingerprint from the following line, falling back to filename A post ( http://newscentral.exsees.com/item/d00c4734c9eed7abe32de6a741f5a3fe-8dd4abc7f69143e4ea63672f83a77a14 ) to an Arch Linux forum expressed a similar report, along with a solution, adding a case for SHA256 or MD5: https://github.com/funtoo/keychain/blob/master/keychain.sh#L692 . For clarity, that's: *\ SHA256:[0-9a-zA-Z\+\/=]*|*\ MD5:[0-9a-zA-Z\+\/=]*) # The new OpenSSH 6.8+ format, # 1024 SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE /home/barney/.ssh/id_dsa (DSA) echo "$ef_line" | cut -f2 -d' ' ;; I applied the changes to my /usr/bin/keychain, and the errors stopped. I think this change belongs in Cygwin, too, since OpenSSH 6.8p1-1 . -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
* More about permissions @ 2015-03-31 4:11 Eliot Moss 2015-03-31 10:18 ` Corinna Vinschen 0 siblings, 1 reply; 3+ messages in thread From: Eliot Moss @ 2015-03-31 4:11 UTC (permalink / raw) To: cygwin Dear Cygwin community -- Along with some others, I've been struggling a little to accommodate the changes to permissions handling that came lately. I think I about have it figured out to work mostly Unix-like within my cygwin tree, but have one remaining thing I am wondering about, even though I have been through the ntsec document more than once. (I think everyone will admit that this is complicated :-) ...) - I have created a new group, that I call Cygwin, to be the typical group of cygwin-related files, so that I can control group permissions appropriately. I am a member of that group. - I have found that if a directory is chmod to 2755 (2000 == set gid) and the directory's group is Cygwin, then cygwin-created files in the directory get group Cygwin. (This was not necessarily happening before.) To get this to happen, I had to list the sid of the Cygwin group as my group in my line of the /etc/passwd file. Otherwise the group would be me, which does not seem to allow the same differentiation of user versus group permissions. - I could not find an explanation of the 'mask' list by getfacl. Near as I can tell it is not really settable, although setfacl does not complain, and it is the OR of the permissions of the various groups. Now, to what I would like to do. Ideally I want SYSTEM to have rwx access to everything. Seems a generally good idea on Windows, and at least r permission on files and rx on directories is needed for my backup program to access things. But if I get group:SYSTEM:rwx and default:group:SYSTEM:rwx, then ls always lists rwx for the group part of any such file, and chmod, if applied, affects SYSTEM's access bits. What I'd like is for SYSTEM's role here to be hidden. If there are any files where I want to restrict SYSTEM, I can use Windows tools or setfacl to manipulate them. Is this simply not possible with the new scheme? Regards -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More about permissions 2015-03-31 4:11 More about permissions Eliot Moss @ 2015-03-31 10:18 ` Corinna Vinschen 2015-03-31 12:22 ` Eliot Moss 0 siblings, 1 reply; 3+ messages in thread From: Corinna Vinschen @ 2015-03-31 10:18 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 3492 bytes --] On Mar 30 23:26, Eliot Moss wrote: > Dear Cygwin community -- > > Along with some others, I've been struggling a little to accommodate > the changes to permissions handling that came lately. I think I about > have it figured out to work mostly Unix-like within my cygwin tree, > but have one remaining thing I am wondering about, even though I have > been through the ntsec document more than once. (I think everyone > will admit that this is complicated :-) ...) > > - I have created a new group, that I call Cygwin, to be the typical > group of cygwin-related files, so that I can control group permissions > appropriately. I am a member of that group. > > - I have found that if a directory is chmod to 2755 (2000 == set gid) > and the directory's group is Cygwin, then cygwin-created files in > the directory get group Cygwin. (This was not necessarily happening > before.) To get this to happen, I had to list the sid of the Cygwin > group as my group in my line of the /etc/passwd file. Otherwise the > group would be me, which does not seem to allow the same differentiation > of user versus group permissions. The group s-bit is not yet taken into account. If you have "Cygwin" as your primary group in /etc/passwd or the account DB of choice (SAM/AD), using 0755 as permissions should do the same thing. Taking the group s-bit into account is part of my work-in-progress for Cygwin 1.7.36. > - I could not find an explanation of the 'mask' list by getfacl. Near > as I can tell it is not really settable, although setfacl does not > complain, and it is the OR of the permissions of the various groups. I explained that in the release annnouncement, I think. The mask value is required per POSIX, but it's faked on Cygwin yet, the reason being that Windows doesn't know such a mask value. I have an idea how to make this work, but I need time for that. The last two or three weeks I had more than enough other stuff so I couldn't concentrate on this, and it looks like this week is the same. > Now, to what I would like to do. Ideally I want SYSTEM to have rwx > access to everything. Seems a generally good idea on Windows, and at > least r permission on files and rx on directories is needed for my > backup program to access things. > > But if I get group:SYSTEM:rwx and default:group:SYSTEM:rwx, then ls > always lists rwx for the group part of any such file, and chmod, if > applied, affects SYSTEM's access bits. What I'd like is for SYSTEM's > role here to be hidden. If there are any files where I want to restrict > SYSTEM, I can use Windows tools or setfacl to manipulate them. > > Is this simply not possible with the new scheme? No. We discussed this at one point a few weeks ago, but it still seems wrong to me to hide the permissions of any account. Where does it end? Is it only SYSTEM, or Administrators as well? And then Domain Admins? Backup Operators? This contradicts the entire POSIX permission model. I'm *very* reluctant to ignore accounts in permission handling. Why does SYSTEM need full access to the files? If it's a backup tool, it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway. Every tool with Administrators in the token has the right to enable these access rights anyway. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More about permissions 2015-03-31 10:18 ` Corinna Vinschen @ 2015-03-31 12:22 ` Eliot Moss [not found] ` <1837571490.20150331235503@yandex.ru> 0 siblings, 1 reply; 3+ messages in thread From: Eliot Moss @ 2015-03-31 12:22 UTC (permalink / raw) To: cygwin On 3/31/2015 6:15 AM, Corinna Vinschen wrote: > On Mar 30 23:26, Eliot Moss wrote: > The group s-bit is not yet taken into account. If you have "Cygwin" as > your primary group in /etc/passwd or the account DB of choice (SAM/AD), > using 0755 as permissions should do the same thing. Ok -- since I was using this mostly to try to get the primary group inserted (instead of my user ("Eliot") as a group), this is fine for most of my purposes. I can see that eventually it would be nice to get the POSIX behavior. > Taking the group s-bit into account is part of my work-in-progress for > Cygwin 1.7.36. Step by step! >> - I could not find an explanation of the 'mask' list by getfacl. Near >> as I can tell it is not really settable, although setfacl does not >> complain, and it is the OR of the permissions of the various groups. > > I explained that in the release annnouncement, I think. The mask > value is required per POSIX, but it's faked on Cygwin yet, the reason > being that Windows doesn't know such a mask value. I have an idea how > to make this work, but I need time for that. The last two or three > weeks I had more than enough other stuff so I couldn't concentrate > on this, and it looks like this week is the same. My disconnect was that I forgot this was a POSIX thing, perhaps because none of the cygwin man pages really mentioned it. On a POSIX system, 'man acl' explains it (I found the description of the computations of access rights particularly clarifying). Maybe the POSIX documentation can be included somewhere, or a reference to it so that someone else is not confused on this point? I would agree that such documentation refinement is not a high priority. >> Now, to what I would like to do. Ideally I want SYSTEM to have rwx >> access to everything. Seems a generally good idea on Windows, and at >> least r permission on files and rx on directories is needed for my >> backup program to access things. >> >> Is this simply not possible with the new scheme? > > No. We discussed this at one point a few weeks ago, but it still seems > wrong to me to hide the permissions of any account. Where does it end? > Is it only SYSTEM, or Administrators as well? And then Domain Admins? > Backup Operators? This contradicts the entire POSIX permission model. > I'm *very* reluctant to ignore accounts in permission handling. I can see that it might be a slippery slope. > Why does SYSTEM need full access to the files? If it's a backup tool, > it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway. Every tool with > Administrators in the token has the right to enable these access rights > anyway. I am not sure this particular program (CrashPlan) works that way. I suppose that I am seeing SYSTEM as the moral equivalent of root in POSIX. In POSIX, root can access anything, and I don't believes ACLs can lock it out. I agree that Windows does not really have the concept of a single 'root'. Administrators is close, but the various aspects of root are split up in different ways. We're not going to get a perfect mapping. Maybe what I am looking for is something like this: - Certain Windows accounts/groups would be treated as 'root' for cygwin's purposes, perhaps controlled by a list in a file read when cygwin starts up. - The permissions associated with root sids would be ignored by ls, chmod, and such, though (we could decide) perhaps visible and settable via getfacl and setfacl. (Making them visible would not be very POSIX like, but it might be convenient.) Getting fancier, we could have a flag control whether these permissions are visible through the get/setfacl interface. - The umask and mask would not turn off permissions associated with these sids. - If the current user/group privileges allow access because they are a root sid and the Windows ACL grants the permission, then the permission would be granted (i.e., the user is effectively root in that case). In all this I am just thinking out loud. There is no 'perfect' way to map between the POSIX concepts and the Windows ones. I am just not sure we've taken the POSIX concept of 'root' and mapped it at all, though ... The ntsec page does a great job of describing the complexities of mapping identities and file permissions, and of switching identities. It does not really address the notion of which identities are like root. I agree that doing this thoroughly may impact set(e)uid. Some programs would probably like it if running under any 'root' sid (according to my concept above) gave an effective uid of 0. I am not sure that could work (the real sid might need to be saved / available as well -- sigh). Anyway, thanks for listening ... Regards, and thank you for your continuing work on this! Eliot -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <1837571490.20150331235503@yandex.ru>]
* Re: More about permissions [not found] ` <1837571490.20150331235503@yandex.ru> @ 2015-04-01 0:41 ` Eliot Moss 2015-04-01 1:05 ` Andrey Repin 0 siblings, 1 reply; 3+ messages in thread From: Eliot Moss @ 2015-04-01 0:41 UTC (permalink / raw) To: cygwin On 3/31/2015 4:55 PM, Andrey Repin wrote: >> I am not sure this particular program (CrashPlan) works that way. > > That's not program property, but the user you run the program from. Perhaps, but it runs as a background service. I never explicitly said what user it runs as, etc. Looking in Services, I see is logs on as "Local System account". Using Process Explorer, it appears to run without SEBackup/Restore privileges. Since the program has to request them itself as it runs, I don't see any good way to fix this. > I think i've explained it earlir, but here's it again: > In POSIX model, root have implicit permissions. > In Windows model, there NO implicit permissions at all. Everything should be > explicitly assigned. I.e. SeBackupRestore privilege. > If you deny SYSTEM access to a file, OS will not be able to do anything about > it. Been there, blocked changes to cmd.exe when I was experimenting with 4NT. > (And cmd.exe was in fact renamed 4nt.exe.) None of the Windows autotools were > able to get around it. Yes, I get that. Hence my desire to grant SYSTEM:rwx on everything. What we seem to have ended up with here, though, is that the root privileges are explicit and are exposed in the ordinary permissions visible with, say, ls -l. This is not natural from a POSIX point of view (I claim); otherwise, we'd more or less show access of rwxrwxrwx on everything in POSIX. Now where this really makes a difference is when I am transferring files between my Windows system and other systems that are Unix-based, using git, rsync, and such tools. Either I remove SYSTEM access or the permissions get messed up. >> Maybe what I am looking for is something like this: > >> - Certain Windows accounts/groups would be treated as 'root' for cygwin's >> purposes, perhaps controlled by a list in a file read when cygwin starts up. > The list would be very short. "NT AUTHORITY\SYSTEM". Ok -- I would be happy with that, rather than having g+rwx happening to every file because I am granting SYSTEM access. Do you begin to see the bind I feel myself in? Regards -- Eliot -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More about permissions 2015-04-01 0:41 ` Eliot Moss @ 2015-04-01 1:05 ` Andrey Repin 2015-04-01 7:38 ` Corinna Vinschen 0 siblings, 1 reply; 3+ messages in thread From: Andrey Repin @ 2015-04-01 1:05 UTC (permalink / raw) To: Eliot Moss, cygwin Greetings, Eliot Moss! >>> I am not sure this particular program (CrashPlan) works that way. >> >> That's not program property, but the user you run the program from. > Perhaps, but it runs as a background service. I never explicitly said what > user it runs as, etc. > Looking in Services, I see is logs on as "Local System account". Using > Process Explorer, it appears to run without SEBackup/Restore privileges. > Since the program has to request them itself as it runs, I don't see any > good way to fix this. Well, then, as Corinna said, the task isn't up to the job, if it doesn't enable necessary privileges. Either way, this is an offtopic. >> I think i've explained it earlir, but here's it again: >> In POSIX model, root have implicit permissions. >> In Windows model, there NO implicit permissions at all. Everything should be >> explicitly assigned. I.e. SeBackupRestore privilege. >> If you deny SYSTEM access to a file, OS will not be able to do anything about >> it. Been there, blocked changes to cmd.exe when I was experimenting with 4NT. >> (And cmd.exe was in fact renamed 4nt.exe.) None of the Windows autotools were >> able to get around it. > Yes, I get that. Hence my desire to grant SYSTEM:rwx on everything. That's one way to solve your issue, but not a correct way. > What we seem to have ended up with here, though, is that the > root privileges are explicit and are exposed in the ordinary permissions visible > with, say, ls -l. This is not natural from a POSIX point of view (I claim); > otherwise, we'd more or less show access of rwxrwxrwx on everything in POSIX. > Now where this really makes a difference is when I am transferring files between my Windows > system and other systems that are Unix-based, using git, rsync, and such tools. > Either I remove SYSTEM access or the permissions get messed up. That's one of the reasons why I think SYSTEM account privileges needs to be hidden from POSIX access mask. It needs to be shown in getfacl to reduce confusion, though, but otherwise there's no case, where hiding it could cause any more harm, than showing it. >>> Maybe what I am looking for is something like this: >> >>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's >>> purposes, perhaps controlled by a list in a file read when cygwin starts up. >> The list would be very short. "NT AUTHORITY\SYSTEM". > Ok -- I would be happy with that, rather than having g+rwx happening to every > file because I am granting SYSTEM access. > Do you begin to see the bind I feel myself in? Do tell me? I'm perpetually caught in it. -- With best regards, Andrey Repin Wednesday, April 1, 2015 03:47:24 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More about permissions 2015-04-01 1:05 ` Andrey Repin @ 2015-04-01 7:38 ` Corinna Vinschen 2015-04-01 12:50 ` Andrey Repin 0 siblings, 1 reply; 3+ messages in thread From: Corinna Vinschen @ 2015-04-01 7:38 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1406 bytes --] On Apr 1 03:52, Andrey Repin wrote: > > Now where this really makes a difference is when I am transferring files between my Windows > > system and other systems that are Unix-based, using git, rsync, and such tools. > > Either I remove SYSTEM access or the permissions get messed up. > > That's one of the reasons why I think SYSTEM account privileges needs to be > hidden from POSIX access mask. It needs to be shown in getfacl to reduce > confusion, though, but otherwise there's no case, where hiding it could cause > any more harm, than showing it. > > >>> Maybe what I am looking for is something like this: > >> > >>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's > >>> purposes, perhaps controlled by a list in a file read when cygwin starts up. > > >> The list would be very short. "NT AUTHORITY\SYSTEM". > > > Ok -- I would be happy with that, rather than having g+rwx happening to every > > file because I am granting SYSTEM access. > > > Do you begin to see the bind I feel myself in? > > Do tell me? I'm perpetually caught in it. Sigh. This is really annoying from a developer's POV. Yes, yes, I still have "ignore SYSTEM in group handling?" on my TODO list... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More about permissions 2015-04-01 7:38 ` Corinna Vinschen @ 2015-04-01 12:50 ` Andrey Repin 2015-04-01 13:27 ` OpenSSH 6.8p1-1 and keychain: can't determine fingerprint wilson 0 siblings, 1 reply; 3+ messages in thread From: Andrey Repin @ 2015-04-01 12:50 UTC (permalink / raw) To: Corinna Vinschen, cygwin Greetings, Corinna Vinschen! > On Apr 1 03:52, Andrey Repin wrote: >> > Now where this really makes a difference is when I am transferring files between my Windows >> > system and other systems that are Unix-based, using git, rsync, and such tools. >> > Either I remove SYSTEM access or the permissions get messed up. >> >> That's one of the reasons why I think SYSTEM account privileges needs to be >> hidden from POSIX access mask. It needs to be shown in getfacl to reduce >> confusion, though, but otherwise there's no case, where hiding it could cause >> any more harm, than showing it. >> >> >>> Maybe what I am looking for is something like this: >> >> >> >>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's >> >>> purposes, perhaps controlled by a list in a file read when cygwin starts up. >> >> >> The list would be very short. "NT AUTHORITY\SYSTEM". >> >> > Ok -- I would be happy with that, rather than having g+rwx happening to every >> > file because I am granting SYSTEM access. >> >> > Do you begin to see the bind I feel myself in? >> >> Do tell me? I'm perpetually caught in it. > Sigh. This is really annoying from a developer's POV. > Yes, yes, I still have "ignore SYSTEM in group handling?" on my TODO > list... That's why I'm not replying to you! <3 I know it is somewhere there. I was explaining it to Eliot. Sorry for disturbance! -- With best regards, Andrey Repin Wednesday, April 1, 2015 15:35:10 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: OpenSSH 6.8p1-1 and keychain: can't determine fingerprint 2015-04-01 12:50 ` Andrey Repin @ 2015-04-01 13:27 ` wilson 2015-04-01 13:33 ` Kal Sze 0 siblings, 1 reply; 3+ messages in thread From: wilson @ 2015-04-01 13:27 UTC (permalink / raw) To: cygwin I saw the following on https://www.cygwin.com/ml/cygwin/2015-03/msg00477.html and I've been having the same issue with keychain. The fix to the /usr/bin/keychain shell script worked as shown, but I've added information about where the fix belongs (in the script) later in this message. I suggest correcting the indentations for the proposed fix as needed. > After updating to OpenSSH 6.8p1-1, I experienced an issue where, at > every login, keychain (in my .bash_profile) wrote a warning: > > <snip> > The warning: > Can't determine fingerprint from the following line, falling back to > filename > > A post > (http://newscentral.exsees.com/item/d00c4734c9eed7abe32de6a741f5a3fe-8dd4abc7f69143e4ea63672f83a77a14 > [1]) to an Arch Linux forum expressed a similar report, along with a > solution, adding a case for SHA256 or MD5: > https://github.com/funtoo/keychain/blob/master/keychain.sh#L692 [2]. > > For clarity, that's: > * SHA256:[0-9a-zA-Z+/=]*|* MD5:[0-9a-zA-Z+/=]*) > # The new OpenSSH 6.8+ format, > # 1024 SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE > /home/barney/.ssh/id_dsa (DSA) > echo "$ef_line" | cut -f2 -d' ' > ;; > > I applied the changes to my /usr/bin/keychain, and the errors stopped. > I think this change belongs in Cygwin, too, since OpenSSH 6.8p1-1. I applied this fix to the case statement (penultimate entry) in the extract_fingerprints() function (around line 800) and it does seem to work for me as well. I would recommend this be added as a permanent fix in Cygwin's package. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: OpenSSH 6.8p1-1 and keychain: can't determine fingerprint 2015-04-01 13:27 ` OpenSSH 6.8p1-1 and keychain: can't determine fingerprint wilson @ 2015-04-01 13:33 ` Kal Sze 0 siblings, 0 replies; 3+ messages in thread From: Kal Sze @ 2015-04-01 13:33 UTC (permalink / raw) To: cygwin On 1 April 2015 at 21:03, wilson <wilson@ds.net> wrote: > > I saw the following on https://www.cygwin.com/ml/cygwin/2015-03/msg00477.html and I've been having the same issue with keychain. The fix to the /usr/bin/keychain shell script worked as shown, but I've added information about where the fix belongs (in the script) later in this message. I suggest correcting the indentations for the proposed fix as needed. > >> After updating to OpenSSH 6.8p1-1, I experienced an issue where, at every login, keychain (in my .bash_profile) wrote a warning: >> >> <snip> >> The warning: >> Can't determine fingerprint from the following line, falling back to filename >> >> A post (http://newscentral.exsees.com/item/d00c4734c9eed7abe32de6a741f5a3fe-8dd4abc7f69143e4ea63672f83a77a14 [1]) to an Arch Linux forum expressed a similar report, along with a solution, adding a case for SHA256 or MD5: https://github.com/funtoo/keychain/blob/master/keychain.sh#L692 [2]. >> >> For clarity, that's: >> * SHA256:[0-9a-zA-Z+/=]*|* MD5:[0-9a-zA-Z+/=]*) >> # The new OpenSSH 6.8+ format, >> # 1024 SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE /home/barney/.ssh/id_dsa (DSA) >> echo "$ef_line" | cut -f2 -d' ' >> ;; >> >> I applied the changes to my /usr/bin/keychain, and the errors stopped. I think this change belongs in Cygwin, too, since OpenSSH 6.8p1-1. > > > I applied this fix to the case statement (penultimate entry) in the extract_fingerprints() function (around line 800) and it does seem to work for me as well. I would recommend this be added as a permanent fix in Cygwin's package. > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > If you don't have to support multiple users (like me), just downloading the 2.8.0 keychain script to your local path and sourcing that that in .profile/.bash_profile is probably cleaner. I seem to notice that keychain 2.8.0 is slower to load than 2.7.1 though. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-04-01 13:33 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-27 5:04 OpenSSH 6.8p1-1 and keychain: can't determine fingerprint White, W John (GE Transportation) 2015-03-31 4:11 More about permissions Eliot Moss 2015-03-31 10:18 ` Corinna Vinschen 2015-03-31 12:22 ` Eliot Moss [not found] ` <1837571490.20150331235503@yandex.ru> 2015-04-01 0:41 ` Eliot Moss 2015-04-01 1:05 ` Andrey Repin 2015-04-01 7:38 ` Corinna Vinschen 2015-04-01 12:50 ` Andrey Repin 2015-04-01 13:27 ` OpenSSH 6.8p1-1 and keychain: can't determine fingerprint wilson 2015-04-01 13:33 ` Kal Sze
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).