windows下ssh证书的Permissions are too open问题

这种 permission问题,linux下面结局就比较简单,直接chmod和chown就差不多了。

window下的提示就比较摸不着头脑,不知道到底去哪个界面设置。

今天在vsc 中通过ssh -i 证书 ip访问服务器,出现了提示:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "xxx": bad permissions

初步搜了下,有相关的内容,但是还是无法照着操作成功。

选择证书,记住是证书,这里是证书的权限问题,很多帖子乱抄一起,说什么确认ssh config。

右键证书,属性-安全:

  1. 只保留当前访问的用户,总之范围越小越安全。
    file
  2. 第一步设置后,还是提示不行,发现第2步才是关键
    file

设置后,就可以在在vsc中实现远程代码编辑和同步命令操作了,爽!

shebang in unix

ref: https://en.wikipedia.org/wiki/Shebang_(Unix)

"hash-bang" redirects here. For #! in URLs, see hash-bang fragment.

#!
shebang

In computing, a shebang is the character sequence consisting of the characters number sign and exclamation mark (#!) at the beginning of a script. It is also called sha-bang,[1][2] hashbang,[3][4] pound-bang,[5][6] or hash-pling.[7]

When a text file with a shebang is used as if it is an executable in a Unix-like operating system, the program loader mechanism parses the rest of the file's initial line as an interpreter directive. The loader executes the specified interpreter program, passing to it as an argument using the path that was initially used when attempting to run the script, so that the program may use the file as input data.[8] For example, if a script is named with the path path/to/script, and it starts with the following line, #!/bin/sh, then the program loader is instructed to run the program /bin/sh, passing path/to/script as the first argument. In Linux, this behavior is the result of both kernel and user-space code.[9]

The shebang line is usually ignored by the interpreter, because the "#" character is a comment marker in many scripting languages; some language interpreters that do not use the hash mark to begin comments still may ignore the shebang line in recognition of its purpose.[10]

Contents

Syntax[edit]

The form of a shebang interpreter directive is as follows:[8]

#!interpreter [optional-arg]

in which interpreter is generally an absolute path to an executable program. The optional argument is a string representing a single argument. White space after #! is optional.

In Linux, the file specified by interpreter can be executed if it has the execute right and contains code which the kernel can execute directly, if it has a wrapper defined for it via sysctl (such as for executing Microsoft .exe binaries using wine), or if it contains a shebang. On Linux and Minix, an interpreter can also be a script. A chain of shebangs and wrappers yields a directly executable file that gets the encountered scripts as parameters in reverse order. For example, if file /bin/A is an executable file in ELF format, file /bin/B contains the shebang #!/bin/A optparam, and file /bin/C contains the shebang #!/bin/B, then executing file /bin/C resolves to /bin/B /bin/C, which finally resolves to /bin/A optparam /bin/B /bin/C.

In Solaris- and Darwin-derived operating systems (such as macOS), the file specified by interpreter must be an executable binary and cannot itself be a script.[11]

Examples[edit]

Some typical shebang lines:

  • #!/bin/sh – Execute the file using the Bourne shell, or a compatible shell, assumed to be in the /bin directory
  • #!/bin/bash – Execute the file using the Bash shell
  • #!/usr/bin/pwsh – Execute the file using PowerShell
  • #!/usr/bin/env python3 – Execute with a Python interpreter, using the env program search path to find it
  • #!/bin/false – Do nothing, but return a non-zero exit status, indicating failure. Used to prevent stand-alone execution of a script file intended for execution in a specific context, such as by the . command from sh/bash, source from csh/tcsh, or as a .profile, .cshrc, or .login file.

Shebang lines may include specific options that are passed to the interpreter. However, implementations vary in the parsing behavior of options; for portability, only one option should be specified without any embedded whitespace. Further portability guidelines are found below.

Purpose[edit]

Interpreter directives allow scripts and data files to be used as commands, hiding the details of their implementation from users and other programs, by removing the need to prefix scripts with their interpreter on the command line.

Bourne shell script that is identified by the path some/path/to/foo, has the initial line,

#!/bin/sh -x

and is executed with parameters bar and baz as

some/path/to/foo bar baz

provides a similar result as having actually executed the following command line instead:

/bin/sh -x some/path/to/foo bar baz

If /bin/sh specifies the Bourne shell, then the end result is that all of the shell commands in the file some/path/to/foo are executed with the positional variables $1 and $2 having the values bar and baz, respectively. Also, because the initial number sign is the character used to introduce comments in the Bourne shell language (and in the languages understood by many other interpreters), the whole shebang line is ignored by the interpreter.

However, it is up to the interpreter to ignore the shebang line; thus, a script consisting of the following two lines simply echos both lines to standard output when run:

#!/bin/cat
Hello world!

Strengths[edit]

When compared to the use of global association lists between file extensions and the interpreting applications, the interpreter directive method allows users to use interpreters not known at a global system level, and without administrator rights. It also allows specific selection of interpreter, without overloading the filename extension namespace (where one file extension refers to more than one file type), and allows the implementation language of a script to be changed without changing its invocation syntax by other programs. Invokers of the script need not know what the implementation language is as the script itself is responsible for specifying the interpreter to use.

Portability[edit]

Program location[edit]

Shebangs must specify absolute paths (or paths relative to current working directory) to system executables; this can cause problems on systems that have a non-standard file system layout. Even when systems have fairly standard paths, it is quite possible for variants of the same operating system to have different locations for the desired interpreter. Python, for example, might be in /usr/bin/python3/usr/local/bin/python3, or even something like /home/username/bin/python3 if installed by an ordinary user.

A similar problem exists for the POSIX shell, since POSIX only required its name to be sh, but did not mandate a path. A common value is /bin/sh, but some systems such as Solaris have the POSIX-compatible shell at /usr/xpg4/bin/sh.[12] In many Linux systems, /bin/sh is a hard or symbolic link to /bin/bash, the Bourne Again shell (BASH). Using bash-specific syntax while maintaining a shebang pointing to sh is also not portable.[13]

Because of this it is sometimes required to edit the shebang line after copying a script from one computer to another because the path that was coded into the script may not apply on a new machine, depending on the consistency in past convention of placement of the interpreter. For this reason and because POSIX does not standardize path names, POSIX does not standardize the feature.[14] The GNU Autoconf tool can test for system support with the macro AC_SYS_INTERPRETER.[15]

Often, the program /usr/bin/env can be used to circumvent this limitation by introducing a level of indirection#! is followed by /usr/bin/env, followed by the desired command without full path, as in this example:

#!/usr/bin/env sh

This mostly works because the path /usr/bin/env is commonly used for the env utility, and it invokes the first sh found in the user's $PATH, typically /bin/sh.

This still has some portability issues with OpenServer 5.0.6 and Unicos 9.0.2 which have only /bin/env and no /usr/bin/env.

Character interpretation[edit]

Another portability problem is the interpretation of the command arguments. Some systems, including Linux, do not split up the arguments;[16] for example, when running the script with the first line like,

#!/usr/bin/env python3 -c

all text after the first space is treated as a single argument, that is, python3 -c will be passed as one argument to /usr/bin/env, rather than two arguments. Cygwin also behaves this way.

Complex interpreter invocations are possible through the use of an additional wrapper. FreeBSD 6.0 (2005) introduced a -S option to its env as it changed the shebang-reading behavior to non-splitting. This option tells env to split the string itself.[17] The GNU env utility since coreutils 8.30 (2018) also includes this feature.[18] Although using this option mitigates the portability issue on the kernel end with splitting, it adds the requirement that env supports this particular extension.

Another problem is scripts containing a carriage return character immediately after the shebang line, perhaps as a result of being edited on a system that uses DOS line breaks, such as Microsoft Windows. Some systems interpret the carriage return character as part of the interpreter command, resulting in an error message.[19]

Magic number[edit]

The shebang is actually a human-readable instance of a magic number in the executable file, the magic byte string being 0x23 0x21, the two-character encoding in ASCII of #!. This magic number is detected by the "exec" family of functions, which determine whether a file is a script or an executable binary. The presence of the shebang will result in the execution of the specified executable, usually an interpreter for the script's language. It has been claimed[20] that some old versions of Unix expect the normal shebang to be followed by a space and a slash (#! /), but this appears to be untrue;[21] rather, blanks after the shebang have traditionally been allowed, and sometimes documented with a space (see the 1980 email in history section below).

The shebang characters are represented by the same two bytes in extended ASCII encodings, including UTF-8, which is commonly used for scripts and other text files on current Unix-like systems. However, UTF-8 files may begin with the optional byte order mark (BOM); if the "exec" function specifically detects the bytes 0x23 and 0x21, then the presence of the BOM (0xEF 0xBB 0xBF) before the shebang will prevent the script interpreter from being executed. Some authorities recommend against using the byte order mark in POSIX (Unix-like) scripts,[22] for this reason and for wider interoperability and philosophical concerns. Additionally, a byte order mark is not necessary in UTF-8, as that encoding does not have endianness issues; it serves only to identify the encoding as UTF-8.

Etymology[edit]

An executable file starting with an interpreter directive is simply called a script, often prefaced with the name or general classification of the intended interpreter. The name shebang for the distinctive two characters may have come from an inexact contraction of SHArp bang or haSH bang, referring to the two typical Unix names for them. Another theory on the sh in shebang is that it is from the default shell sh, usually invoked with shebang.[23] This usage was current by December 1989,[24] and probably earlier.

History[edit]

The shebang was introduced by Dennis Ritchie between Edition 7 and 8 at Bell Laboratories. It was also added to the BSD releases from Berkeley's Computer Science Research (present at 2.8BSD[25] and activated by default by 4.2BSD). As AT&T Bell Laboratories Edition 8 Unix, and later editions, were not released to the public, the first widely known appearance of this feature was on BSD.

The lack of an interpreter directive, but support for shell scripts, is apparent in the documentation from Version 7 Unix in 1979,[26] which describes instead a facility of the Bourne shell where files with execute permission would be handled specially by the shell, which would (sometimes depending on initial characters in the script, such as ":" or "#") spawn a subshell which would interpret and run the commands contained in the file. In this model, scripts would only behave as other commands if called from within a Bourne shell. An attempt to directly execute such a file via the operating system's own exec() system trap would fail, preventing scripts from behaving uniformly as normal system commands.

In later versions of Unix-like systems, this inconsistency was removed. Dennis Ritchie introduced kernel support for interpreter directives in January 1980, for Version 8 Unix, with the following description:[25]

From uucp Thu Jan 10 01:37:58 1980
>From dmr Thu Jan 10 04:25:49 1980 remote from research

The system has been changed so that if a file being executed
begins with the magic characters #! , the rest of the line is understood
to be the name of an interpreter for the executed file.
Previously (and in fact still) the shell did much of this job;
it automatically executed itself on a text file with executable mode
when the text file's name was typed as a command.
Putting the facility into the system gives the following
benefits.

1) It makes shell scripts more like real executable files,
because they can be the subject of 'exec.'

2) If you do a 'ps' while such a command is running, its real
name appears instead of 'sh'.
Likewise, accounting is done on the basis of the real name.

3) Shell scripts can be set-user-ID.[a]

4) It is simpler to have alternate shells available;
e.g. if you like the Berkeley csh there is no question about
which shell is to interpret a file.

5) It will allow other interpreters to fit in more smoothly.

To take advantage of this wonderful opportunity,
put

  #! /bin/sh
 
at the left margin of the first line of your shell scripts.
Blanks after ! are OK.  Use a complete pathname (no search is done).
At the moment the whole line is restricted to 16 characters but
this limit will be raised.

The feature's creator didn't give it a name, however:[28]

From: "Ritchie, Dennis M (Dennis)** CTR **" <dmr@[redacted]>
To: <[redacted]@talisman.org>
Date: Thu, 19 Nov 2009 18:37:37 -0600
Subject: RE: What do -you- call your #!<something> line?

 I can't recall that we ever gave it a proper name.
It was pretty late that it went in--I think that I
got the idea from someone at one of the UCB conferences
on Berkeley Unix; I may have been one of the first to
actually install it, but it was an idea that I got
from elsewhere.

As for the name: probably something descriptive like
"hash-bang" though this has a specifically British flavor, but
in any event I don't recall particularly using a pet name
for the construction.

Kernel support for interpreter directives spread to other versions of Unix, and one modern implementation can be seen in the Linux kernel source in fs/binfmt_script.c.[29]

This mechanism allows scripts to be used in virtually any context normal compiled programs can be, including as full system programs, and even as interpreters of other scripts. As a caveat, though, some early versions of kernel support limited the length of the interpreter directive to roughly 32 characters (just 16 in its first implementation), would fail to split the interpreter name from any parameters in the directive, or had other quirks. Additionally, some modern systems allow the entire mechanism to be constrained or disabled for security purposes (for example, set-user-id support has been disabled for scripts on many systems).

Note that, even in systems with full kernel support for the #! magic number, some scripts lacking interpreter directives (although usually still requiring execute permission) are still runnable by virtue of the legacy script handling of the Bourne shell, still present in many of its modern descendants. Scripts are then interpreted by the user's default shell.

See also[edit]

Notes[edit]

  1. ^ The setuid feature is disabled in most modern operating systems following the realization that a race condition can be exploited to change the script while it's being processed.[27]

References[edit]

  1. ^ "Advanced Bash Scripting Guide: Chapter 2. Starting Off With a Sha-Bang"Archived from the original on 10 December 2019. Retrieved 10 December 2019.
  2. ^ Cooper, Mendel (5 November 2010). Advanced Bash Scripting Guide 5.3 Volume 1. lulu.com. p. 5. ISBN 978-1-4357-5218-4.
  3. ^ MacDonald, Matthew (2011). HTML5: The Missing Manual. Sebastopol, California: O'Reilly Media. p. 373. ISBN 978-1-4493-0239-9.
  4. ^ Lutz, Mark (September 2009). Learning Python (4th ed.). O'Reilly Media. p. 48. ISBN 978-0-596-15806-4.
  5. ^ Guelich, Gundavaram and Birznieks, Scott, Shishir and Gunther (29 July 2000). CGI Programming with PERL (2nd ed.). O'Reilly Media. p. 358ISBN 978-1-56592-419-2.
  6. ^ Lie Hetland, Magnus (4 October 2005). Beginning Python: From Novice to Professional. Apress. p. 21. ISBN 978-1-59059-519-0.
  7. ^ Schitka, John (24 December 2002). Linux+ Guide to Linux Certification. Course Technology. p. 353. ISBN 978-0-619-13004-6.
  8. Jump up to:a b "execve(2) - Linux man page". Retrieved 21 October 2010.
  9. ^ Corbet, Jonathan. "The case of the supersized shebang"LWN.net.
  10. ^ "SRFI 22".
  11. ^ "Python - Python3 shebang line not working as expected".
  12. ^ "The Open Group Base Specifications Issue 7". 2008. Retrieved 5 April 2010.
  13. ^ "pixelbeat.org: Common shell script mistakes"It's much better to test scripts directly in a POSIX compliant shell if possible. The `bash --posix` option doesn't suffice as it still accepts some 'bashisms'
  14. ^ "Chapter 2. Shell Command Language"The Open Group Base Specifications (IEEE Std 1003.1-2017) (Issue 7 ed.), IEEE, 2018 [2008], If the first line of a file of shell commands starts with the characters "#!", the results are unspecified.
  15. ^ Autoconf, Free Software Foundation, Macro: AC_SYS_INTERPRETER: Check whether the system supports starting scripts with a line of the form ‘#!/bin/sh’ to select the interpreter to use for the script.
  16. ^ "/usr/bin/env behaviour". Mail-index.netbsd.org. 9 November 2008. Retrieved 18 November 2010.
  17. ^ env(1) – FreeBSD General Commands Manual
  18. ^ "env invocation"GNU Coreutils. Retrieved 11 February 2020.
  19. ^ "Carriage Return causes bash to fail". 8 November 2013.
  20. ^ "GNU Autoconf Manual v2.57, Chapter 10: Portable Shell Programming". Archived from the original on 18 January 2008. Retrieved 14 May 2020.
  21. ^ "The #! magic, details about the shebang/hash-bang mechanism on various Unix flavours". Retrieved 14 May 2020.
  22. ^ "FAQ - UTF-8, UTF-16, UTF-32 & BOM: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?". Retrieved 4 January 2009.
  23. ^ "Jargon File entry for shebang"Catb.org. Retrieved 16 June 2010.
  24. ^ Wall, Larry"Perl didn't grok setuid scripts that had a space on the first line between the shebang and the interpreter name"USENET.
  25. Jump up to:a b "CSRG Archive CD-ROMs".
  26. ^ UNIX TIME-SHARING SYSTEM: UNIX PROGRAMMER'S MANUAL (PDF), vol. 2A (Seventh ed.), January 1979
  27. ^ Gilles. "linux - Why is SUID disabled for shell scripts but not for binaries?"Information Security Stack Exchange.
  28. ^ Richie, Dennis. "Dennis Ritchie and Hash-Bang". Talisman.org. Retrieved 3 December 2020.
  29. ^ Rubini, Alessandro (31 December 1997). "Playing with Binary Formats"Linux Journal. Retrieved 1 January 2015.

External links[edit]

svn迁移到git,并保持提交记录

svn迁移git是一个很常见的需求。

大部分人希望保留详细的提交记录,因为提交记录是代码版本管理的核心价值。

步骤

  1. 导出用户(非必要)
    svn log 远程SVN仓库地址 -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2"="$2" <"$2"@xxx.com>"}' | sort -u > ./users.txt
    执行完后手动修改对应的新用户映射关系,如果没有对应的都可以设置成同一个
  2. git svn clone 远程SVN仓库地址 --no-metadata --authors-file=users.txt GitProject, gitproject 是一个空的目录,表示git项目名称。
  3. 添加必要的.gitignore文件
  4. cd GitProject
  5. git remote -v,如果不为空,则删除原有origin:git remote rm origin
  6. 增加远程仓库的地址:git remote add origin git@x.x.x.x/project-name.git
  7. push到远程仓库,必要的话,强制push
    git push -u -f origin master

常见问题FAQ

  • 在clone中断时,我们尝试再次执行clone命令,提示了如下的内容:Using existing [svn-remote "svn"] svn-remote.svn.fetch already set to track :refs/remotes/git-svn
    解决:进入git目录,执行 git svn fetch,继续代码的clone行为。

  • 如果提示不支持 git svn,请安装 git-svn

  • 在执行的过程中提示APR does not understand this error code: ra_serf: An error occurred during decompression at /usr/share/perl5/Git/SVN/Ra.pm
    这个问题比较棘手,前后尝试了将近2天,刚开始以为仓库代码太大,几十G,大文件不稳定导致,所以尝试了好多次,后面google了下,感觉跟版本有关,又受限于服务器配置不能改,有点无奈。后面在windows中尝试,系统莫名重启,继续在ubuntu20中,才成功。
    出问题的环境版本
    ubuntu:14.04.3
    git: git version 1.9.1
    OK的环境
    ubuntu:ubuntu1~20.04
    Git:git version 2.25.1

android Kconfig搜索路径

安卓中,在kernel下运行make menuconfig时,能看到一些开关,但是很多比如在vendor下的驱动的Kconfig中的就看不到。

见网络摘引:
“menuconfig默认会到当前工作路径下去寻找Kconfig文件作为入口配置文件并解析,因此必须在顶层Kconfig文件所在路径下运行该命令。否则将无法找到kconfig文件或造成配置项加载不完全的问题。”

参考这句话,也就是默认是搜索kernel下的递归目录中的相关Kconfig文件的,所以vendor中的自然不加载。

解除gitlab仓库的保护

问题

在git push时,错误提示如下:

remote: GitLab: You are not allowed to force push code to a protected branch on this project.To git@xxx:xxx.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: 无法推送一些引用到 'git@xxx:xxx.git'

关键内容就是protected branch,所以我们需要确认是怎么protected。

解决

repo->settings->repository->protected branches:
file