09-26-2016
Only the client side account should generate the keys and the server side account would accept the public key into the authorized_keys file if the service side account agrees to being connected to, so your server side account should never have the private key from the client side account.
The public key is very likely still on the client side account. If it is the client side that has been lost and there are no backups, you will need to create a new key and then get the public key onto the servers it needs to connect to.
If you need to open the connection the other way around, then your definition of what is client and what is server is switched and you should really generate a new key for that connection only. The reason for this is that if you have client on host-A trusted to talk to the server host-B and server host-C and you also send the private key to host-B so host-B can act as a client to what now becomes server host-A, it will also be trusted to connect to server host-C because it has the private key.
Does that make sense of have I confused things?
Robin
10 More Discussions You Might Find Interesting
1. UNIX for Advanced & Expert Users
Hi, My account is : abcd
I belong to a group: pqrs
Some thing straneg happened yesterday.
My .cshrc and .login got overwritten into pqrs's .cshrc and .login
I obviously did not explicitly overwrite pqrs's .cshrc.
Are there any reasons how this could have happened indirectly due to... (5 Replies)
Discussion started by: gjthomas
5 Replies
2. UNIX for Dummies Questions & Answers
Hello,
One of my frend had a problem.
He had Windows XP installed on his system. Then he installed Red Hat Linux 8.0 in one of the partitions. After some time his XP got corrupt and then he reinstalled Windows XP. This over wrote the Grub loader entry, and due to this the grub loader is not... (2 Replies)
Discussion started by: rahulrathod
2 Replies
3. AIX
We have a problem where we delete a user and their associated UID gets dumped back in the UID pool. The if we immediately create a another (new) user, AIX reuses the last UID, the one that was just released. This is causing a problem when reports are being generated because the new users name is... (2 Replies)
Discussion started by: xsys2000
2 Replies
4. AIX
Hi all,
I am still working on my mksysb restore.
My latest issue is during an alt_disk_install from tape I got the following error after all the data had been restored.
0505-143 alt_disk_install: Unable to match mksysb level 5.2.0 with any
available boot images. Please correct this... (0 Replies)
Discussion started by: pobman
0 Replies
5. Solaris
Hi,
The dump device on my system was set to /dev/dsk/c0t0d0s7. I have done a savecore -Lv on the system which worked fine. I'm wondering have I overwritten the rootdisk here by mistake? The system is still up but will need to be rebooted due to an error on it. Will it come back up?
... (8 Replies)
Discussion started by: gwhelan
8 Replies
6. Programming
Hi, i have some problems with the following code:
char *tab_path;
char *sep=" \t\n";
char line;
char *p;
FILE * file;
int i = 0;
if(fgets(line,MAXLINE,file)!=NULL){
if((p=strtok(line,sep))!=NULL)tab_path=p;
while((p=strtok(NULL,sep))!=NULL){
i++;
... (4 Replies)
Discussion started by: littleboyblu
4 Replies
7. Shell Programming and Scripting
Hello All,
I am writing a bash script on Solaris O/S. I looping through an array. For each iteration, i connect to the datatabase and use select statement. Output of which is redirected to .CSV file. here is the code for it.
output="loop.csv"
elements=${#currency_pair}
... (3 Replies)
Discussion started by: arundhati_s
3 Replies
8. Cybersecurity
Hey all, I have a request from a third party that will be setting my firm up for an account so we can sftp files to their server in a Production environment. I know where the public keys are located on our Red Hat Linux envronment. I was going to ftp the keys from the Linux environment over to my... (2 Replies)
Discussion started by: dfb500
2 Replies
9. HP-UX
I am trying to complete ssh2 connection between HP-UX and CoreFTP. The host key authentication fails with signature didn't match. See below output. I can connect to this CoreFTP from my Windows desktop, and connect to a multitude of other servers from the HP-UX system as well, but have... (2 Replies)
Discussion started by: Stars
2 Replies
10. Shell Programming and Scripting
Hi All,
I am new new to unix.com, I have a question related to shell scripting.
We have a Oracle database backup shell script, which can be used for taking full, incremental & archive log backup based on the parameters passed.
Within the script we export a variable as
export... (5 Replies)
Discussion started by: veeresh_15
5 Replies
LEARN ABOUT SUSE
ssh-keyconverter
SSH-KEYCONVER(1) BSD General Commands Manual SSH-KEYCONVER(1)
NAME
ssh-keyconvert -- convert ssh v1 keys and authorization files
SYNOPSIS
ssh-keyconvert [-k] [-o output_file] identity_file ...
ssh-keyconvert [-a] [-o output_file] authorization_file ...
DESCRIPTION
ssh-keyconvert converts RSA public and private keys used for public key based user authentication with protocol version 1 to the format used
with protocol version 2.
When using RSA user authentication with SSH protocol version 1, the client uses the private key from $HOME/.ssh/identity to provide its iden-
tity to the server. The server grants or denies access based on whether the public part of this key is listed in $HOME/.ssh/authorized_keys.
SSH protocol version 2 supports both DSA and RSA keys, but the way RSA keys are stored are differently. On the client, the default file name
is .ssh/id_rsa rather than .ssh/identity, and the file's format is different as well. On the server, the public porting of the key can still
be stored in .ssh/authorized_keys, but the key notation has changed as well. Therefore, when switching from protocol version 1 to version 2,
you either have to create a new identity key using ssh-keygen(1) and add that key to the server's authorized_keys file, or you need to con-
vert your keys using ssh-keyconvert.
By default, ssh-keyconvert will try to guess the type of file that is to be converted. If it fails to guess correctly, you can tell if what
type of conversion to perform by specifying the -k option to convert the private key, or the -a option to convert an authorisation file.
When converting your private keys stored in .ssh/identity, ssh-keyconvert will read the private key, prompting you for the pass phrase if the
key is protected by a pass phrase. If the -o option is given, it will write the private key to the specified file, using version 2 syntax. If
the key was protected by a pass phrase, it will use the same pass phrase to protect the new file. It will also write the public portion of
the key to a second file, using the specified file name with ``.pub'' appended. If the -o option was not given, private and public key will
be written to id_rsa and id_rsa.pub, respectively, relative to the directory of the input key file.
If the destination file already exists, ssh-keyconvert will prompt the user for confirmation before overwriting the file, unless the -f
option is given.
When converting your authorized_keys file, ssh-keyconvert will ignore any keys in SSH version 2 format. Any public keys in version 1 format
will be converted and appended to the output file using the new syntax. If the -o option is given, keys are appended to the specified file.
If it is not given, ssh-keyconvert will append all keys to the input file.
Note that ssh-keyconvert does not check for duplicate keys, so if you run it on .ssh/authorized_keys more several times, the converted keys
will show up several times.
OPTIONS
-k Convert private key file(s). The default is to guess the type of file that should be converted.
-a Convert authorized_keys file(s). The default is to guess the type of file that should be converted.
-o outfile
Specify the name of the output file. When converting an authorization file, all public keys will be appended to this file. For pri-
vate key conversion, the private and public components of the key will be stored in outfile and outfile.pub, respectively. Note that
since every key must be stored in a separate file, you cannot use this option when you specify several input files.
-f When converting a key file, and the output file already exists, ssh-keyconvert will ask the user whether to overwrite the file. Using
this option forces overwriting.
AUTHORS
OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos,
Theo de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH. ssh-keyconvert was contributed by Olaf Kirch.
SEE ALSO
ssh(1), ssh-add(1), ssh-agent(1), sshd(8)
J. Galbraith and R. Thayer, SECSH Public Key File Format, draft-ietf-secsh-publickeyfile-01.txt, March 2001, work in progress material.
BSD
February 2, 2002 BSD