I need to remove the passphrase from an SSL private key file. I'm using
openssl rsa -in in.key.pem -out out.key.pem
to do that. The issue I'm facing is that the passphrase for that keyfile (the passphrase is being generated on a different machine somewhere) looks something like this:
~Casdfghetc
As you've probably figured out, the "~C" part of that passphrase spawns a new command line and leaves me unable to correctly enter the passphrase. Quoting, double-quoting and so forth don't work.
I'm using putty to connect to this shell, hopping through a golden host (powerbroker). This is a productive, secure environment, so I cannot log into the machine any other way. Any tips on how I can get this to work?
Way 1. As http://www.jedi.be/blog/2010/08/27/ssh-tricks-the-usual-and-beyond/ points out:
Escape sequences are only recognized after a newline
So, when asked for a passphrase, you can do the following:
Type some letter before typing your passphrase, e.g. a.
Press Backspace key to undo/remove it.
Type your passphrase as usual.
Way 2. On my system, pressing "~?" shows the following help:
Supported escape sequences:
~. - terminate connection (and any multiplexed sessions)
~B - send a BREAK to the remote system
~C - open a command line
~R - request rekey
~V/v - decrease/increase verbosity (LogLevel)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
So, to insert tilde (~) right after newline, I need just to press it twice (~~). Probably, the same is true for you system: just type ~~Casdfghetc instead of ~Casdfghetc.
Related
Usually CTRL-C or CTRL-D quits a program. However, once in a while instead of quitting the program, pressing CTRL-C just escapes the characters and outputs it to the terminal screen. I've seen this happen multiple times before for different programs: Django, ssh, etc. I've noticed this happens when I've left the terminal for a long period of time.
Is there a way to revert the CTRL-C behavior back to what I would expect?
And what is the reasoning behind the escaped characters?
Here is an example output of what I mean by escaped CTRL-C and other characters:
^C^C^D^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^D^D^D^D^D^D^D^D^D^D^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^D^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^D^D^D^D^D^D^D^D^D^D^D^D^D^D^[^[^D^D^D^D^Z^Z^Z^Z^Z^Z
This is because the connection to server may have been broken, so your terminal is just echoing what you do instead of being able to show you what the command or the server was responding. The way to get out of ssh in such is to use termination sequence ~ + . + Enter. Enter may not be always required
Below are the list of SSH escape sequences
~. - terminate connection (and any multiplexed sessions)
~B - send a BREAK to the remote system
~C - open a command line
~R - Request rekey (SSH protocol 2 only)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
PS: Taken from https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka-kill-dead-ssh-sessions/
In SourceTree I'm using OpenSSH as authentication and created + added my SSH keys (on Windows) like this:
ssh-keygen -t rsa -C "my#email.com"
(and entered filename, password etc)
Added the key to the SSH agent:
eval "$(ssh-agent)"
ssh-add id_rsa
Added the SSH key to GitLab using
cat id_rsa.pub to print my public key
Added the public key to SourceTree by "Tools > Add SSH key" followed by the password ("Tools > options > SSH client configuration" I've selected OpenSSH).
After these steps I'm able to push and pull code.
However, each time I restart SourceTree a terminal pops-up and I have to re-enter my password again*. How can I make SourceTree / the SSH agent remember this password?
ps. my keys are saved in a directory like /d/MyName/Gitlab/ instead of ~/.ssh/ but that shouldn't be a problem, right?
EDIT:
*The message shown in the terminal:
SourceTree is loading your SSH key into the agent for authentication Please enter your passphrase if prompted to do so Enter passphrase for D:\MyName\GitLab\.ssh\id_rsa:
EDIT2:
This solution didn't solve my problem either:
You can use the Windows OpenSSH ssh-agent to manage your keys.
The problem is that Sourcetree on windows wants to start its own instance of the ssh-agent instead of using the already running service. Even if you can get that to work it will still prompt for your key passphrase on startup because Sourcetree's ssh-agent process doesn't save your keys to the the Windows keychain.
There are heaps of instructions on how to use Pageant as your ssh agent, but that is not why you're here. You're here because you want to use the OpenSSH agent, with OpenSSH formatted keys, with passphrases but without being prompted for said passphrase all over the place.
The trick is to proxy all requests to Pageant through to your OpenSSH agent.
Install OpenSSH.
Start the ssh-agent service and set to automatic.
Add your private keys to the agent with
ssh-add <key_file>
Add your public keys to the hosts you want to authenticate with.
Test that you can authenticate via ssh:
ssh -T git#github.com
Your private keys will now be loaded when you log in to your Windows account and you won't have to provide passphrases ever again.
To allow programs and libraries such as Sourcetree, WinSCP and Fabric that normally use Pageant to instead have keys provided by the ssh-agent there is an awesome program https://github.com/ndbeals/winssh-pageant
Follow instructions to install winssh-pageant, schedule it as a task to start on windows startup.
Now all calls to Pageant's NamedPipe will be proxied to the OpenSSH agent.
The last step to get SourceTree working with OpenSSH is a bit counter-intuitive.
Go to Tools | Options | General and set the SSH Client to PuTTY/Plink and uncheck the "Automatically start SSH agent when Sourcetree opens".
I solved this issue following these steps:
Find the path to Pageant (in my case was in C:\Users\{my-user}\AppData\Local\SourceTree\app-3.3.8\tools\putty\pageant.exe)
Do Window key + R or type run in Windows bar
In the text box put shell:startup
Make a shortcut of your pageant and paste it in the window that just opened
Right click on the shortcut and click on Properties
In Shortcut tab, in target put your-sourcetree-pageant-path\pageant.exe id_rsa.ppk
In Start in put C:\Users\{my-user}\.ssh and click ok
Note that your id_rsa.ppk must be inside C:\Users\{my-user}\.ssh directory
If for some reason your id_rsa.ppk is protected by a passphrase and you are sure you won't have security issues. Just remove the passphrase.
To remove the id_rsa.ppk's passphrase, follow these steps
Open PuttyGen
Go to Conversions => Import key
Remove the passphrase
Save the private key & public key
Replace the protected id_rsa.ppk with the unprotected id_rsa.ppk
Hope that helped!
You manually start your agent and set environment variables in order for commands to find it.
Whenever you start your a command (like SourceTree) without those environment variables set, that command is not able to access the agent and therefore asks for your password.
Making your agent start on system startup should solve things.
If ssh cannot reach the agent it will also look into ~/.ssh/ therefor if you place you keys there it should work, too. (Have a look at man ssh.)
After did below test, the password never asked for me.
To test whether your SSH key was added correctly, run the following command in your terminal (replacing gitlab.com with your GitLab's instance domain):
ssh -T git#gitlab.com
The first time you connect to GitLab via SSH, you should verify the authenticity of the GitLab host that you're connecting to. For example, when connecting to GitLab.com, answer yes to add GitLab.com to the list of trusted hosts:
The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitlab.com' (ECDSA) to the list of known hosts.
NOTE: Note: For GitLab.com, consult the SSH host keys fingerprints, section to make sure you're connecting to the correct server. For example, you can see the ECDSA key fingerprint shown above in the linked section.
Once added to the list of known hosts, you should validate the authenticity of GitLab's host again. Run the above command once more, and you should only receive a Welcome to GitLab, #username! message.
If the welcome message doesn't appear, you can troubleshoot the problem by running ssh in verbose mode with the following command:
ssh -Tvvv git#gitlab.com
Sometimes an SSH session to a remote server will freeze indefinitely due to bad internet connectivity. Is it possible to close the session without closing the terminal?
Press the following three keys:
Enter
~ (tilde)
. (period)
This is the "disconnect" function as described in the ESCAPE CHARACTERS section of the ssh man page.
In this post, geekosaur suggests we use the escape sequences as follows: "To kill the current session hit subsequently Enter ↵, ~, ..
More of these escape sequences can be listed with Enter ↵, ~, ?:
Supported escape sequences:
~. - terminate session
~B - send a BREAK to the remote system
~R - Request rekey (SSH protocol 2 only)
~# - list forwarded connections
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
You can close the list of Escape sequences by hitting Enter ↵.
Notice that because hitting ~~ causes ssh to send the ~ instead of intercepting it, you can address N nested ssh connections by hitting ~ N times. (This only applies to ~s that directly follow an Enter ↵.) That is to say that Enter ↵~~~~~. terminates an ssh session 5 layers deep and keeps the other 4 intact."
I created an ssh key without a password that I use to ssh and mosh into several webservers. It's been working fine for about 3 months now. Today when trying to access one of our servers, it prompted me for a password.
I ran "ssh -vvv name-of-server" to confirm that the only thing keeping me from connecting to the server is the password requirement.
Changing the password requires the old password, which I don't have/ shouldn't exist. Does anyone have any idea what might be happening, or how I can get rid of the password requirement?
Thank you to Garreth for pointing me in the right direction.
Unfortunately, this problem doesn't have a happy ending. I checked out the private key file and noticed that it began with these two lines:
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,BCC23A5E16582F3D
Evidently this means that the key has been encrypted, and encrypted keys need a password to be used. I found this command for decrypting:
$ openssl rsa -in id_rsa -out id_rsa
But you need the password to decrypt. I tried copying and pasting the contents of the old RSA key to a new file, but I was prompted to enter a password to decrypt file as well. I'm deleting my old keypair and starting over. :(
The key has become corrupted in some way. Check it to make sure that no extra characters or lines got added to it (eg via been pasted in an email that wasn't plain text).
Check each individual line of the key in a plain text editor. There should be no blank characters at the end of any line, and no new lines beyond the key demarcation line.
When connecting to remote hosts via ssh, I frequently want to bring a file on that system to the local system for viewing or processing. Is there a way to copy the file over without (a) opening a new terminal/pausing the ssh session (b) authenticating again to either the local or remote hosts which works (c) even when one or both of the hosts is behind a NAT router?
The goal is to take advantage of as much of the current state as possible: that there is a connection between the two machines, that I'm authenticated on both, that I'm in the working directory of the file---so I don't have to open another terminal and copy and paste the remote host and path in, which is what I do now. The best solution also wouldn't require any setup before the session began, but if the setup was a one-time or able to be automated, than that's perfectly acceptable.
zssh (a ZMODEM wrapper over openssh) does exactly what you want.
Install zssh and use it instead of openssh (which I assume that you normally use)
You'll have to have the lrzsz package installed on both systems.
Then, to transfer a file zyxel.png from remote to local host:
antti#local:~$ zssh remote
Press ^# (C-Space) to enter file transfer mode, then ? for help
...
antti#remote:~$ sz zyxel.png
**B00000000000000
^#
zssh > rz
Receiving: zyxel.png
Bytes received: 104036/ 104036 BPS:16059729
Transfer complete
antti#remote:~$
Uploading goes similarly, except that you just switch rz(1) and sz(1).
Putty users can try Le Putty, which has similar functionality.
On a linux box I use the ssh-agent and sshfs. You need to setup the sshd to accept connections with key pairs. Then you use ssh-add to add you key to the ssh-agent so you don't have type your password everytime. Be sure to use -t seconds, so the key doesn't stay loaded forever.
ssh-add -t 3600 /home/user/.ssh/ssh_dsa
After that,
sshfs hostname:/ /PathToMountTo/
will mount the server file system on your machine so you have access to it.
Personally, I wrote a small bash script that add my key and mount the servers I use the most, so when I start to work I just have to launch the script and type my passphrase.
Using some little known and rarely used features of the openssh
implementation you can accomplish precisely what you want!
takes advantage of the current state
can use the working directory where you are
does not require any tunneling setup before the session begins
does not require opening a separate terminal or connection
can be used as a one-time deal in an interactive session or can be used as part of an automated session
You should only type what is at each of the local>, remote>, and
ssh> prompts in the examples below.
local> ssh username#remote
remote> ~C
ssh> -L6666:localhost:6666
remote> nc -l 6666 < /etc/passwd
remote> ~^Z
[suspend ssh]
[1]+ Stopped ssh username#remote
local> (sleep 1; nc localhost 6666 > /tmp/file) & fg
[2] 17357
ssh username#remote
remote> exit
[2]- Done ( sleep 1; nc localhost 6666 > /tmp/file )
local> cat /tmp/file
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
...
Or, more often you want to go the other direction, for example if you
want to do something like transfer your ~/.ssh/id_rsa.pub file from
your local machine to the ~/.ssh/authorized_keys file of the remote
machine.
local> ssh username#remote
remote> ~C
ssh> -R5555:localhost:5555
remote> ~^Z
[suspend ssh]
[1]+ Stopped ssh username#remote
local> nc -l 5555 < ~/.ssh/id_rsa.pub &
[2] 26607
local> fg
ssh username#remote
remote> nc localhost 5555 >> ~/.ssh/authorized_keys
remote> cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2ZQQQQBIwAAAQEAsgaVp8mnWVvpGKhfgwHTuOObyfYSe8iFvksH6BGWfMgy8poM2+5sTL6FHI7k0MXmfd7p4rzOL2R4q9yjG+Hl2PShjkjAVb32Ss5ZZ3BxHpk30+0HackAHVqPEJERvZvqC3W2s4aKU7ae4WaG1OqZHI1dGiJPJ1IgFF5bWbQl8CP9kZNAHg0NJZUCnJ73udZRYEWm5MEdTIz0+Q5tClzxvXtV4lZBo36Jo4vijKVEJ06MZu+e2WnCOqsfdayY7laiT0t/UsulLNJ1wT+Euejl+3Vft7N1/nWptJn3c4y83c4oHIrsLDTIiVvPjAj5JTkyH1EA2pIOxsKOjmg2Maz7Pw== username#local
A little bit of explanation is in order.
The first step is to open a LocalForward; if you don't already have
one established then you can use the ~C escape character to open an
ssh command line which will give you the following commands:
remote> ~C
ssh> help
Commands:
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-D[bind_address:]port Request dynamic forward
-KR[bind_address:]port Cancel remote forward
In this example I establish a LocalForward on port 6666 of localhost
for both the client and the server; the port number can be any
arbitrary open port.
The nc command is from the netcat package; it is described as the
"TCP/IP swiss army knife"; it is a simple, yet very flexible and
useful program. Make it a standard part of your unix toolbelt.
At this point nc is listening on port 6666 and waiting for another
program to connect to that port so it can send the contents of
/etc/passwd.
Next we make use of another escape character ~^Z which is tilde
followed by control-Z. This temporarily suspends the ssh process and
drops us back into our shell.
One back on the local system you can use nc to connect to the
forwarded port 6666. Note the lack of a -l in this case because that
option tells nc to listen on a port as if it were a server which is
not what we want; instead we want to just use nc as a client to
connect to the already listening nc on the remote side.
The rest of the magic around the nc command is required because if
you recall above I said that the ssh process was temporarily
suspended, so the & will put the whole (sleep + nc) expression
into the background and the sleep gives you enough time for ssh to
return to the foreground with fg.
In the second example the idea is basically the same except we set up
a tunnel going the other direction using -R instead of -L so that
we establish a RemoteForward. And then on the local side is where
you want to use the -l argument to nc.
The escape character by default is ~ but you can change that with:
-e escape_char
Sets the escape character for sessions with a pty (default: ‘~’). The escape character is only recognized at the beginning of a line. The escape character followed by a dot
(‘.’) closes the connection; followed by control-Z suspends the connection; and followed by itself sends the escape character once. Setting the character to “none” disables any
escapes and makes the session fully transparent.
A full explanation of the commands available with the escape characters is available in the ssh manpage
ESCAPE CHARACTERS
When a pseudo-terminal has been requested, ssh supports a number of functions through the use of an escape character.
A single tilde character can be sent as ~~ or by following the tilde by a character other than those described below. The escape character must always follow a newline to be interpreted
as special. The escape character can be changed in configuration files using the EscapeChar configuration directive or on the command line by the -e option.
The supported escapes (assuming the default ‘~’) are:
~. Disconnect.
~^Z Background ssh.
~# List forwarded connections.
~& Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.
~? Display a list of escape characters.
~B Send a BREAK to the remote system (only useful for SSH protocol version 2 and if the peer supports it).
~C Open command line. Currently this allows the addition of port forwardings using the -L, -R and -D options (see above). It also allows the cancellation of existing remote port-
forwardings using -KR[bind_address:]port. !command allows the user to execute a local command if the PermitLocalCommand option is enabled in ssh_config(5). Basic help is avail‐
able, using the -h option.
~R Request rekeying of the connection (only useful for SSH protocol version 2 and if the peer supports it).
Using ControlMaster (the -M switch) is the best solution, way simpler and easier than the rest of the answers here. It allows you to share a single connection among multiple sessions. Sounds like it does what the poster wants. You still have to type the scp or sftp command line though. Try it. I use it for all of my sshing.
In order to do this I have my home router set up to forward port 22 back to my home machine (which is firewalled to only accept ssh connections from my work machine) and I also have an account set up with DynDNS to provide Dynamic DNS that will resolve to my home IP automatically.
Then when I ssh into my work computer, the first thing I do is run a script that starts an ssh-agent (if your server doesn't do that automatically). The script I run is:
#!/bin/bash
ssh-agent sh -c 'ssh-add < /dev/null && bash'
It asks for my ssh key passphrase so that I don't have to type it in every time. You don't need that step if you use an ssh key without a passphrase.
For the rest of the session, sending files back to your home machine is as simple as
scp file_to_send.txt your.domain.name:~/
Here is a hack called ssh-xfer which addresses the exact problem, but requires patching OpenSSH, which is a nonstarter as far as I'm concerned.
Here is my preferred solution to this problem. Set up a reverse ssh tunnel upon creating the ssh session. This is made easy by two bash function: grabfrom() needs to be defined on the local host, while grab() should be defined on the remote host. You can add any other ssh variables you use (e.g. -X or -Y) as you see fit.
function grabfrom() { ssh -R 2202:127.0.0.1:22 ${#}; };
function grab() { scp -P 2202 $# localuser#127.0.0.1:~; };
Usage:
localhost% grabfrom remoteuser#remotehost
password: <remote password goes here>
remotehost% grab somefile1 somefile2 *.txt
password: <local password goes here>
Positives:
It works without special software on either host beyond OpenSSH
It works when local host is behind a NAT router
It can be implemented as a pair of two one-line bash function
Negatives:
It uses a fixed port number so:
won't work with multiple connections to remote host
might conflict with a process using that port on the remote host
It requires localhost accept ssh connections
It requires a special command on initiation the session
It doesn't implicitly handle authentication to the localhost
It doesn't allow one to specify the destination directory on localhost
If you grab from multiple localhosts to the same remote host, ssh won't like the keys changing
Future work:
This is still pretty kludgy. Obviously, it would be possible to handle the authentication issue by setting up ssh keys appropriately and it's even easier to allow the specification of a remote directory by adding a parameter to grab()
More difficult is addressing the other negatives. It would be nice to pick a dynamic port but as far as I can tell there is no elegant way to pass that port to the shell on the remote host; As best as I can tell, OpenSSH doesn't allow you to set arbitrary environment variables on the remote host and bash can't take environment variables from a command line argument. Even if you could pick a dynamic port, there is no way to ensure it isn't used on the remote host without connecting first.
You can use SCP protocol for tranfering a file.you can refer this link
http://tekheez.biz/scp-protocol-in-unix/
The best way to use this you can expose your files over HTTP and download it from another server, you can achieve this using ZSSH Python library,
ZSSH - ZIP over SSH (Simple Python script to exchange files between servers).
Install it using PIP.
python3 -m pip install zssh
Run this command from your remote server.
python3 -m zssh -as --path /desktop/path_to_expose
It will give you an URL to execute from another server.
In the local system or another server where you need to download those files and extract.
python3 -m zssh -ad --path /desktop/path_to_download --zip http://example.com/temp_file.zip
For more about this library: https://pypi.org/project/zssh/
You should be able to set up public & private keys so that no auth is needed.
Which way you do it depends on security requirements, etc (be aware that there are linux/unix ssh worms which will look at keys to find other hosts they can attack).
I do this all the time from behind both linksys and dlink routers. I think you may need to change a couple of settings but it's not a big deal.
Use the -M switch.
"Places the ssh client into 'master' mode for connection shar-ing. Multiple -M options places ssh into ``master'' mode with confirmation required before slave connections are accepted. Refer to the description of ControlMaster in ssh_config(5) for details."
I don't quite see how that answers the OP's question - can you expand on this a bit, David?